3 ms·

> Actually the easiest thing is simply not to care about how your log looks. You need to expand on this because i don't quite understand what you mean, are you

by leejo 10y ago

> Actually the easiest thing is simply not to care about how your log looks. You need to expand on this because i don't quite understand what you mean, are you talking about "fix typo" commits or are we getting to the level of just committing away until things work and then not cleaning up the work later on? The linked article doesn't cover rebasing or squashing commits, which can be pretty powerful when used correctly. Your commit log is the one thing that is immutably linked to your code changes. Your documentation isn't, the comments in your code aren't, you will forget why you made a change, anyone reviewing your logs needs to understand your intention, your bug tracker will probably change several times over the life of a project, and so on. So, make an effort to have a commit log that is clean and comprehensive and commits that don't break tests. I go into this in more detail in a talk i gave last week: https://www.youtube.com/watch?v=9OHAq8dCoS4 https://www.youtube.com/watch?v=9OHAq8dCoS4

sergiosgc 10y ago
Develop on feature branches, merge with master only when the feature is done. Always merge with --no-ff. Then, when reviewing history, on the master branch you can use either "git log" or "git log --first-parent master". The first log is the complete log, with exploratory development, mistakes, backtracks and such. The second is the clean log people keep rewriting history to obtain. You get your cake and you can eat it too.
- leejo 10y ago
  This is pretty much the reason i don't understand people who don't want merge commits (the use case for rebase in the video is modifying commits in a feature branch BTW, not merging to master). You can bend git logs to your will with the various options so there's no problem in being as verbose as possible in commit messages and the concept of a "linear history" is a moot point because, no matter how messy your history actual is, there's a command line option to clear it up. Be verbose in your commit messages and don't worry about merge commits, it will pay dividends later.

by leejo 10y ago

sergiosgc 10y ago

Develop on feature branches, merge with master only when the feature is done. Always merge with --no-ff. Then, when reviewing history, on the master branch you can use either "git log" or "git log --first-parent master". The first log is the complete log, with exploratory development, mistakes, backtracks and such. The second is the clean log people keep rewriting history to obtain. You get your cake and you can eat it too.

leejo 10y ago
This is pretty much the reason i don't understand people who don't want merge commits (the use case for rebase in the video is modifying commits in a feature branch BTW, not merging to master). You can bend git logs to your will with the various options so there's no problem in being as verbose as possible in commit messages and the concept of a "linear history" is a moot point because, no matter how messy your history actual is, there's a command line option to clear it up. Be verbose in your commit messages and don't worry about merge commits, it will pay dividends later.