4 ms·

My biggest workflow problem is remembering to commit. Then it occurs to me to commit, I do a "git status" and holy crud, what do all those changes do? So I'm

by thyrsus 13y ago

My biggest workflow problem is remembering to commit. Then it occurs to me to commit, I do a "git status" and holy crud, what do all those changes do? So I'm resolving now to commit... when? Any time a new test succeeds (without breaking old tests) -or- Any time I run a test -or- Something else I haven't thought of? It needs to be something more concrete than "when you've done something significant". The mental energy drain of deciding "significant" is a killer. Help?

malyk 13y ago
I think the growing consensus on using a dvcs is that you should work on easily separated chunks of functionality in their own branch. Commit whenever you feel like it throughout the lifecycle of working on that feature, then go back and squash all those random commits into a few easy to understand chunks, and then merge that back into master. For example, I'm working on a simple landing page and form. Some logical points for doing a commit may be something like: 1 basic responsive layout complete for mobile 2 progress on desktop responsive layout (going home) 3 completed desktop responsive layout 4 wired up forms 5 added validation to forms 6 cleaned up duplicate css 7 adjusted css for other, crappy, browsers 8 bug fixes 9 fixed a typo 10 bug fixes & final layout issues Now I'm done and I want to merge that to master. But what I want the commit history to look like is a group of logical steps, excluding things that will be meaningless/useless to other people when they look back at the project history. So I would squash 2 and 3, 4 and 5, and probably 6 thru 10 so that I ended up with 4 total commits 1, 2/3, 4/5, 6/7/8/9/10 that get put onto master. So, you definitely want to try to remember to commit over the course of a feature, but the actual times you commit are a little bit less important because you should clean up your history before you move it to master. In general I try to commit discrete pieces of functionality (like a working form, or a working layout, or a tested class/method).
yxhuvud 13y ago
As often as possible. Then rebase it to a consistent history with consecutive small changes later when it works. The reason many commits are good to have is that it tends to be easier to extract small independent changes that way.

by thyrsus 13y ago

malyk 13y ago

I think the growing consensus on using a dvcs is that you should work on easily separated chunks of functionality in their own branch. Commit whenever you feel like it throughout the lifecycle of working on that feature, then go back and squash all those random commits into a few easy to understand chunks, and then merge that back into master. For example, I'm working on a simple landing page and form. Some logical points for doing a commit may be something like: 1 basic responsive layout complete for mobile 2 progress on desktop responsive layout (going home) 3 completed desktop responsive layout 4 wired up forms 5 added validation to forms 6 cleaned up duplicate css 7 adjusted css for other, crappy, browsers 8 bug fixes 9 fixed a typo 10 bug fixes & final layout issues Now I'm done and I want to merge that to master. But what I want the commit history to look like is a group of logical steps, excluding things that will be meaningless/useless to other people when they look back at the project history. So I would squash 2 and 3, 4 and 5, and probably 6 thru 10 so that I ended up with 4 total commits 1, 2/3, 4/5, 6/7/8/9/10 that get put onto master. So, you definitely want to try to remember to commit over the course of a feature, but the actual times you commit are a little bit less important because you should clean up your history before you move it to master. In general I try to commit discrete pieces of functionality (like a working form, or a working layout, or a tested class/method).

yxhuvud 13y ago

As often as possible. Then rebase it to a consistent history with consecutive small changes later when it works. The reason many commits are good to have is that it tends to be easier to extract small independent changes that way.