Re: [git-users] Clarification Regarding Git Commit Granularity
On Thu, 6 Jun 2013 22:49:24 -0700 PJ Weisberg pjweisb...@gmail.com wrote: So, one thing I'm still a bit fuzzy on is the recommend granularity of commits, and I'm wondering if anyone can help me out. [...] If I understand correctly, you're making two logical changes, each of which touches several files. Then of course you'll want to make two commits. Put them in one commit and you're unnecessarily tying together unrelated things. Break them up into ten or twenty commits and you have a bunch of half-done changes that don't actually work and need to be combined with other commits before they actually make sense. By putting each change into a single commit you have a piece of working software after every revision, which makes it easier to bisect when diagnosing a bug, for example. But note that it's a normal Git practice to crunch a series of small commits which introduce partial changes (and comprise non-working states of a program) on a private feature branch, and then squash-merge [*] them into a single pretty commit on an integration branch which is to be published (i.e. pushed somewhere). You don't *have to* take this route but some people prefer to do things this way. One upside of this approach is relative ease of rolling back to any committed state while you're exploring possible ways to implement a feature by trial and error. [*] Read up on the --squash option of the `git merge` command. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Clarification Regarding Git Commit Granularity
So, one thing I'm still a bit fuzzy on is the recommend granularity of commits, and I'm wondering if anyone can help me out. For example, let's say we're adding a new feature to a software application that's going to require two small updates to the code on 10 pages, what would the recommended commit process be? - Perform both updates on all 10 pages and commit everything all at once (1 commits) - Perform 'small update #1' on all 10 pages and then commit, then do the same for 'small update #2' (2 commits) - Make both of the small updates to each page and then commit by page (10 commits) - Update and commit every single change, in every file (20 commits) etc. And yes, I know that the first two are bad practice, they're mostly here for comparison. The last one is by far the most thorough, but is it overkill? It seems to me that if you commit every single change separately eventually you're going to be spending more time committing and explaining the commits than actual programming. Or is this just what you have to deal with if you want to do things properly? And if that *is* the way to go, how do you tie the 20 updates together so that the log shows a logical start and end point for the feature addition as a whole? I'm in the process of completely revamping my development process, and I would really like to get better at committing, so if anyone has any info that would help it would be greatly appreciated. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Clarification Regarding Git Commit Granularity
One thing I'm still a bit fuzzy on is the recommended granularity of commits, and I'm wondering if anyone can help me out. For example, let's say we're adding a new feature to a software application that's going to require two small updates to the code on 10 pages, what would the recommended commit process be? - Perform both updates on all 10 pages and commit everything all at once (1 commits) - Perform 'small update #1' on all 10 pages and then commit, then do the same for 'small update #2' (2 commits) - Make both of the small updates to each page and then commit by page (10 commits) - Update and commit every single change, in every file (20 commits) etc. And yes, I know that the first two are bad practice, they're mostly here for comparison. The last one is by far the most thorough, but is it overkill? It seems to me that if you commit every single change separately eventually you're going to be spending more time committing and explaining the commits than actual programming. Or is this just what you have to deal with if you want to do things properly? And if that is the way to go, how do you tie the 20 updates together so that the log shows a logical start and end point for the feature addition as a whole? I'm in the process of completely revamping my development process, and I would really like to get better at committing, so if anyone has any info that would help it would be greatly appreciated. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Clarification Regarding Git Commit Granularity
On Jun 6, 2013 9:59 PM, Greg Chetcuti g...@chetcuti.com wrote: So, one thing I'm still a bit fuzzy on is the recommend granularity of commits, and I'm wondering if anyone can help me out. For example, let's say we're adding a new feature to a software application that's going to require two small updates to the code on 10 pages, what would the recommended commit process be? - Perform both updates on all 10 pages and commit everything all at once (1 commits) - Perform 'small update #1' on all 10 pages and then commit, then do the same for 'small update #2' (2 commits) - Make both of the small updates to each page and then commit by page (10 commits) - Update and commit every single change, in every file (20 commits) etc. If I understand correctly, you're making two logical changes, each of which touches several files. Then of course you'll want to make two commits. Put them in one commit and you're unnecessarily tying together unrelated things. Break them up into ten or twenty commits and you have a bunch of half-done changes that don't actually work and need to be combined with other commits before they actually make sense. By putting each change into a single commit you have a piece of working software after every revision, which makes it easier to bisect when diagnosing a bug, for example. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
