8 ms·

My Git Habits

150 points by swah 15y ago

tomdeakin 15y ago
git-add -p is new to me, but looks like something I'd wish I'd known about for a long while. The number of times I end up copying changes (like a new function) into some temp file while I commit is more than I'd care to admit.
- pja 15y ago
  You can also git-add -i to go through the staging area & stage/unstage individual patches.
  - jedbrown 15y ago
    Or use git citool or an emacs mode like egg or magit (other editors have similar) that let you conveniently stage by hunk or line.
- baq 15y ago
  you can use git gui (included) for a mouse-friendly way of doing this.
  - Kiro 15y ago
    Since I first tried the Git GUI I can't see myself using Git Bash ever again (and this article reminds me of why).
- telemachos 15y ago
  Another good post that talks about git add -p is Ryan Tomayko's The Thing About Git[1]. [1]: http://tomayko.com/writings/the-thing-about-git http://tomayko.com/writings/the-thing-about-git
- raju 15y ago
  If you are on a mac, Gitx works nicely too. You can see each file, and state "hunks" as you go.
gerad 15y ago
git commit -v is nice too
Osiris 15y ago
I'm fairly new to git. I've only been using it for about two months. It seems like this is a lot of work with the end result only being that the commit log is cleaner and perhaps makes cherry-picking a feature/fix a bit easier. I can understand the need for this kind of cleanup when pushing a fix to an open-source repository that needs pull requests to be self-contained, but for an internal company repo, how important is it to keep the commit history this clean? If I have changes I'm not ready to commit and need to switch branches to work on another issue, I find that doing a STASH is an easier way to go. I can just stash my working copy changes, switch branches, then come back and apply the stash and keep going and then make one final commit with just the final changes I want to commit. Other DVCS actually believe that being able to modify commit history is a bad thing and lean toward immutable commit history (e.g., Veracity). Git makes it pretty easy to modify commit history which is ok for local branches but can be easily misunderstood to break your branch if you're trying to modify commits that have already been pushed to a remote repo. I like the idea of keeping the commit history clean but I'm not sure that it's worth the effort that it takes to manage the process. In the end, only your final good code is going to be merged into an integration or master branch anyway.
- pja 15y ago
  There's a few advantages to doing things this way. If you ever want to git-bisect your code-base to track down when you introduced a bug then you'll be very thankful that every commit is functional and passes your test-suite (apart from the tests relevant to new features on a topic branch of course). Having to hop forwards and backwards from each git-bisect point looking for a functional commit is a huge waste of time. Breaking your changes into clean commits with proper explanatory commit messages also makes it much easier for people working on the code in the future to work out the intent of various parts of the code. Think of a messy commit history as a form of technical debt: Sure it's quicker to just move forward with development, but if you have a history that breaks things down into clean commits with well written explanatory commit messages then you're making life much, much easier for whoever has to debug that code in the future. Odds are that that person is going to be you & by the time you come back to the code you've have forgotten all about it and be forced to spelunk through the commit history in order to work out what on earth you were doing. Think of it as a service to your future self :)
DavidWoof 15y ago
This seems like a pretty terrible workflow to me, do others here actually work like this? I only use git-add -p when I've screwed up and didn't commit when I should have, so I have to split the current commit into two. It seems to me that rebase -i and merge --squash are better suited to re-writing history in the way that's being done here. I'm especially distrustful of any workflow that includes the line "I eyeball the diff". But I'm no git guru. Is this a common way to work? Are there advantages over the alternatives?
- pja 15y ago
  It means you keep your original history around & build a new one which breaks the code changes into functional chunks. Rewriting your existing history with git rebase -i is fine until it goes horribly wrong & you have to go groveling through the reflog to work out which commits you need to rescue in order to retrieve your lost work.
  - DavidWoof 15y ago
    I don't see that. Keeping your original history around is a function of doing cleanup on a separate branch. It has nothing to do with how that cleanup is achieved. Rewriting your existing history with git reset can also go horribly wrong, which is why it's done on a separate branch here.
- philwelch 15y ago
  I have to shift my brain into totally different modes between programming and reviewing/testing/version-controlling, and git add -p is an important tool. Maybe you're disciplined enough to keep a queue of everything you'd like to do in your head at once, and only stick to one task at a time, and shift into review/test/commit mode between quantized chunks. Me, I just go in, hack for a bit, and when I run out of ideas, I shift modes, read the git diff, break out my work into chunks, and then add -p/stash/test/review/commit chunk by chunk. If you want all of my commits to be functionally and semantically separate and individually tested, I can give that to you. git-add -p is just an interface between that well-disciplined software-engineering expectation and what my brain actually does when it gets into flow.
mdehaan 15y ago
Maybe it's just me, but using short lived topic/feature branches and squash merges seems much easier than remembering all of these steps to "fix up" all these things. I think it becomes some what of a game to use all the more obscure corners of git when a good 20-30% of it goes a long way. Using less commands is more.
- mcknz 15y ago
  I agree, but that also requires a discipline/foresight not all of us have. :) I try to keep my feature branches as atomic as possible, but sometimes I get ahead of myself and work on multiple things that really shouldn't be in the same commit. I wouldn't use this model as my main workflow, but it's definitely useful in certain scenarios.
  - gcb 15y ago
    if your code is 'live' and you plan ahead a few features: feature branches. if you are running as fast as you can for the first releases, what i do is use feature prefixes on the commits. And of course, a commit can have several prefixes. of course, if i have to cherry pick something, i still have to look at each commit, but with prefixes it's easy. And i have the time i didn't spend thinking ahead for something i don't even know i will need.
krupan 15y ago
Wow. I've written about how powerful revision control tools become not just a place to stash diffs, but a full-on code editing tool (http://bryan-murdock.blogspot.com/2010/09/mercurial-is-teh-awesome.html http://bryan-murdock.blogspot.com/2010/09/mercurial-is-teh-a...), but this is very impressive. I think he mentions that he does test these new commits that he creates as he goes about re-arranging history, but I think that should be emphasized more. I'd rather have a messy looking commit that passes tests than some nice looking commit that doesn't. bisect is powerful command that shouldn't be broken.
brown9-2 15y ago
Often I'll be in the middle of something, with a dirty work tree, when it's time to leave for the day. Then I'll just commit everything with the subject WIP ("work-in-progress"). First thing the next morning I'll git-reset HEAD^ and continue where I left off. Curious, what is the advantage of doing this? Why commit something locally just to reset it out the next morning?
- telemachos 15y ago
  He explains here: > Such commits rarely survive beyond the following morning, but if I didn't make them, I wouldn't be able to continue work from home if the mood took me to do that.
  - Davertron 15y ago
    I think the underlying assumption here is that he commits and pushes these changes somewhere accessible from home and not taking it with him on his laptop or something. Otherwise there really isn't a good reason for committing it.
PaulAnunda 15y ago
all i use: git add . && git status git diff --cached | mate git commit -am "this is what i did" git push and when it hits the fan... git reset --hard
dddima 15y ago
Like 'git add -p' but much much better: http://porkrind.org/missives/commit-patch-managing-your-mess/ http://porkrind.org/missives/commit-patch-managing-your-mess...
helpbygrace 15y ago
By the way, that article page is too hard to read comfortably. Shortened the width of each paragraph and upsize the font will be really good for me to read it. tl;dr , I didn't read that page. :(
- yogsototh 15y ago
  You might like this tool (I read the article using this): http://readable.tastefulwords.com/?setup&change&text_font=Goergia%2C%20Palatino&text_font_monospace=Inconsolata&text_font_header=quote%28Times%20New%20Roman%29%2C%20Times%2C%20serif&text_size=20px&text_line_height=1.5&box_width=30em&color_text=%23657B83&color_background=%23FDF6E3&color_links=%23B58900&text_align=justified&base=web_readability&custom_css=pre%2C%20tt%2C%20code%20{%20%20%20%20background-color%3A%20%23EEE8D5%3B%20%20%20%20color%3A%20%23586E75%3B%20}%20pre%20{%20padding%3A%201em%3B%20overflow%3A%20auto%3B} http://readable.tastefulwords.com/?setup&change&text...
Vitaly 15y ago
I just use gitx when I'm on OS X or tig when I'm on a terminal for per chunk or per line (gitx only) staging. git -p is too user unfriendly.
- snprbob86 15y ago
  Once you get used to reading diffs in your terminal, git -p (and -i) turn out to be very useful friendly. It's really easy to just slam y or n a bunch of times, rather than click around a lot.
  - Vitaly 15y ago
    big just uses text diffs as well, only color coded which really adds to the readability of it. I don't need guis for most of the things. The benefit of GitX over tig or git -p is that it easily allows to stage a single line instead of the whole chunk
deleted 15y ago
[deleted]
6ren 15y ago
I think in part he's documenting modules. Because modules often crosscut the primary hierarchy of files/classes/methods, it's awkward to document in the source itself, and so usually isn't documented at all. Git allows documentation across files; and because commits are naturally associated with specific revisions, it can't get out of date. { Still, it does seem a lot of work, and it would be nice to document within the source itself; and in a way that helps and is needed by the code (so it can't get out of date). A bad example: specifically requiring/importing another class before being able to use it. This documents dependencies, and remains current or your code stops working (it would need to be an error to require a class without using it). It is a "bad example" because it doesn't help you, just raises a barrier then "helps" you cross it, like a stand-over man in an extortion racket. What's needed is some immediate benefit (e.g. reduce code) to associating files/classes/methods in a crosscutting "module". }
batista 15y ago
The proliferation of "git tips", and "my git habits", "git best practices" articles, make me think that Git is too complicated for its own good to need all those. (Maybe "need" is a bad choice of words: maybe it doesn't need those articles, but it's too complicated if it gets to have them. You don't get such avalanche of advice for a simple, no BS, tool). Now, the complicated part means it's flexible --in the rare cases you need it to be. But it could probably use a facade that makes the common use cases more intuitive (there are some half-baked attempts that I'm aware of). Personally, I use mercurial.
- msbarnett 15y ago
  It's not exactly hard to find people discussing different best practices and their own individual workflows in Mercurial, either[1]. The existence of these articles doesn't tell us anything negative about Mercurial, or Git, it merely tells us that these tools are powerful enough to be used for Real Work in Real Workflows, and that there are few things people love more than talking about their workflows. [1]: Random examples: http://stackoverflow.com/questions/448567/best-practices-in-mercurial-branch-vs-clone-and-partial-merges http://stackoverflow.com/questions/448567/best-practices-in-... http://mercurial.selenic.com/wiki/WorkingPractices http://mercurial.selenic.com/wiki/WorkingPractices http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/ http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercu... https://blogs.oracle.com/kto/entry/mercurial_best_practices https://blogs.oracle.com/kto/entry/mercurial_best_practices http://mercurial.808500.n3.nabble.com/Best-practices-for-merging-td2989382.html http://mercurial.808500.n3.nabble.com/Best-practices-for-mer... http://www.stevestreeting.com/2010/04/22/mercurial-queues-just-clicked/ http://www.stevestreeting.com/2010/04/22/mercurial-queues-ju...
- gbog 15y ago
  Had to switch from mercurial to git. Both are nice, neither is perfect. I long for the time when we won't have to do so much ancillary work to just sync up files. My bet: In 5 years, all these contrived workflows will be replaced by: sync file1 file2 "fix bug 5782"
  - tikhonj 15y ago
alpad 15y ago
My first thought: crazy. Especially the part with the printouts and highlighters. Could this actually be effective?
b2spirit 15y ago
Habits pronounced hubbits.
swah 15y ago
When you guys delete a feature/complex function that you wrote just to discover you don't need it, do you guys mark it somehow to know something that worked was removed in that commit?
Feoh 15y ago
I said this in a reply, but lest it get lost in the shuffle, here goes. I have a tremendous amount of respect for mjd. His seminal articles on Perl, particularly "Suffering with Buffering" and "Coping with Scoping" saved my bacon more than once. However, I'm a release engineer, and this is an awful, awful Git work flow. As others have noted, Git was designed so that you can make wacky wild experimental changes off to the side in branches, and only when you're happy, merge them back to your working branch and eventually into master. This approach needlessly complicates things and seems incredibly error prone, especially the bit about having to do house cleaning on the morass of broken commits.

150 points by swah 15y ago

git-add -p is new to me, but looks like something I'd wish I'd known about for a long while. The number of times I end up copying changes (like a new function) into some temp file while I commit is more than I'd care to admit.

pja 15y ago
You can also git-add -i to go through the staging area & stage/unstage individual patches.
- jedbrown 15y ago
  Or use git citool or an emacs mode like egg or magit (other editors have similar) that let you conveniently stage by hunk or line.
baq 15y ago
you can use git gui (included) for a mouse-friendly way of doing this.
- Kiro 15y ago
  Since I first tried the Git GUI I can't see myself using Git Bash ever again (and this article reminds me of why).
telemachos 15y ago
Another good post that talks about git add -p is Ryan Tomayko's The Thing About Git[1]. [1]: http://tomayko.com/writings/the-thing-about-git http://tomayko.com/writings/the-thing-about-git
raju 15y ago
If you are on a mac, Gitx works nicely too. You can see each file, and state "hunks" as you go.

gerad 15y ago

git commit -v is nice too

Osiris 15y ago

I'm fairly new to git. I've only been using it for about two months. It seems like this is a lot of work with the end result only being that the commit log is cleaner and perhaps makes cherry-picking a feature/fix a bit easier. I can understand the need for this kind of cleanup when pushing a fix to an open-source repository that needs pull requests to be self-contained, but for an internal company repo, how important is it to keep the commit history this clean? If I have changes I'm not ready to commit and need to switch branches to work on another issue, I find that doing a STASH is an easier way to go. I can just stash my working copy changes, switch branches, then come back and apply the stash and keep going and then make one final commit with just the final changes I want to commit. Other DVCS actually believe that being able to modify commit history is a bad thing and lean toward immutable commit history (e.g., Veracity). Git makes it pretty easy to modify commit history which is ok for local branches but can be easily misunderstood to break your branch if you're trying to modify commits that have already been pushed to a remote repo. I like the idea of keeping the commit history clean but I'm not sure that it's worth the effort that it takes to manage the process. In the end, only your final good code is going to be merged into an integration or master branch anyway.

pja 15y ago
There's a few advantages to doing things this way. If you ever want to git-bisect your code-base to track down when you introduced a bug then you'll be very thankful that every commit is functional and passes your test-suite (apart from the tests relevant to new features on a topic branch of course). Having to hop forwards and backwards from each git-bisect point looking for a functional commit is a huge waste of time. Breaking your changes into clean commits with proper explanatory commit messages also makes it much easier for people working on the code in the future to work out the intent of various parts of the code. Think of a messy commit history as a form of technical debt: Sure it's quicker to just move forward with development, but if you have a history that breaks things down into clean commits with well written explanatory commit messages then you're making life much, much easier for whoever has to debug that code in the future. Odds are that that person is going to be you & by the time you come back to the code you've have forgotten all about it and be forced to spelunk through the commit history in order to work out what on earth you were doing. Think of it as a service to your future self :)

DavidWoof 15y ago

This seems like a pretty terrible workflow to me, do others here actually work like this? I only use git-add -p when I've screwed up and didn't commit when I should have, so I have to split the current commit into two. It seems to me that rebase -i and merge --squash are better suited to re-writing history in the way that's being done here. I'm especially distrustful of any workflow that includes the line "I eyeball the diff". But I'm no git guru. Is this a common way to work? Are there advantages over the alternatives?

pja 15y ago
It means you keep your original history around & build a new one which breaks the code changes into functional chunks. Rewriting your existing history with git rebase -i is fine until it goes horribly wrong & you have to go groveling through the reflog to work out which commits you need to rescue in order to retrieve your lost work.
- DavidWoof 15y ago
  I don't see that. Keeping your original history around is a function of doing cleanup on a separate branch. It has nothing to do with how that cleanup is achieved. Rewriting your existing history with git reset can also go horribly wrong, which is why it's done on a separate branch here.
philwelch 15y ago
I have to shift my brain into totally different modes between programming and reviewing/testing/version-controlling, and git add -p is an important tool. Maybe you're disciplined enough to keep a queue of everything you'd like to do in your head at once, and only stick to one task at a time, and shift into review/test/commit mode between quantized chunks. Me, I just go in, hack for a bit, and when I run out of ideas, I shift modes, read the git diff, break out my work into chunks, and then add -p/stash/test/review/commit chunk by chunk. If you want all of my commits to be functionally and semantically separate and individually tested, I can give that to you. git-add -p is just an interface between that well-disciplined software-engineering expectation and what my brain actually does when it gets into flow.

mdehaan 15y ago

Maybe it's just me, but using short lived topic/feature branches and squash merges seems much easier than remembering all of these steps to "fix up" all these things. I think it becomes some what of a game to use all the more obscure corners of git when a good 20-30% of it goes a long way. Using less commands is more.

mcknz 15y ago
I agree, but that also requires a discipline/foresight not all of us have. :) I try to keep my feature branches as atomic as possible, but sometimes I get ahead of myself and work on multiple things that really shouldn't be in the same commit. I wouldn't use this model as my main workflow, but it's definitely useful in certain scenarios.
- gcb 15y ago
  if your code is 'live' and you plan ahead a few features: feature branches. if you are running as fast as you can for the first releases, what i do is use feature prefixes on the commits. And of course, a commit can have several prefixes. of course, if i have to cherry pick something, i still have to look at each commit, but with prefixes it's easy. And i have the time i didn't spend thinking ahead for something i don't even know i will need.

krupan 15y ago

Wow. I've written about how powerful revision control tools become not just a place to stash diffs, but a full-on code editing tool (http://bryan-murdock.blogspot.com/2010/09/mercurial-is-teh-awesome.html http://bryan-murdock.blogspot.com/2010/09/mercurial-is-teh-a...), but this is very impressive. I think he mentions that he does test these new commits that he creates as he goes about re-arranging history, but I think that should be emphasized more. I'd rather have a messy looking commit that passes tests than some nice looking commit that doesn't. bisect is powerful command that shouldn't be broken.

brown9-2 15y ago

Often I'll be in the middle of something, with a dirty work tree, when it's time to leave for the day. Then I'll just commit everything with the subject WIP ("work-in-progress"). First thing the next morning I'll git-reset HEAD^ and continue where I left off. Curious, what is the advantage of doing this? Why commit something locally just to reset it out the next morning?

telemachos 15y ago
He explains here: > Such commits rarely survive beyond the following morning, but if I didn't make them, I wouldn't be able to continue work from home if the mood took me to do that.
- Davertron 15y ago
  I think the underlying assumption here is that he commits and pushes these changes somewhere accessible from home and not taking it with him on his laptop or something. Otherwise there really isn't a good reason for committing it.

PaulAnunda 15y ago

all i use: git add . && git status git diff --cached | mate git commit -am "this is what i did" git push and when it hits the fan... git reset --hard

dddima 15y ago

Like 'git add -p' but much much better: http://porkrind.org/missives/commit-patch-managing-your-mess/ http://porkrind.org/missives/commit-patch-managing-your-mess...

helpbygrace 15y ago

By the way, that article page is too hard to read comfortably. Shortened the width of each paragraph and upsize the font will be really good for me to read it. tl;dr , I didn't read that page. :(

yogsototh 15y ago
You might like this tool (I read the article using this): http://readable.tastefulwords.com/?setup&change&text_font=Goergia%2C%20Palatino&text_font_monospace=Inconsolata&text_font_header=quote%28Times%20New%20Roman%29%2C%20Times%2C%20serif&text_size=20px&text_line_height=1.5&box_width=30em&color_text=%23657B83&color_background=%23FDF6E3&color_links=%23B58900&text_align=justified&base=web_readability&custom_css=pre%2C%20tt%2C%20code%20{%20%20%20%20background-color%3A%20%23EEE8D5%3B%20%20%20%20color%3A%20%23586E75%3B%20}%20pre%20{%20padding%3A%201em%3B%20overflow%3A%20auto%3B} http://readable.tastefulwords.com/?setup&change&text...

Vitaly 15y ago

I just use gitx when I'm on OS X or tig when I'm on a terminal for per chunk or per line (gitx only) staging. git -p is too user unfriendly.

snprbob86 15y ago
Once you get used to reading diffs in your terminal, git -p (and -i) turn out to be very useful friendly. It's really easy to just slam y or n a bunch of times, rather than click around a lot.
- Vitaly 15y ago
  big just uses text diffs as well, only color coded which really adds to the readability of it. I don't need guis for most of the things. The benefit of GitX over tig or git -p is that it easily allows to stage a single line instead of the whole chunk

deleted 15y ago

[deleted]

6ren 15y ago

I think in part he's documenting modules. Because modules often crosscut the primary hierarchy of files/classes/methods, it's awkward to document in the source itself, and so usually isn't documented at all. Git allows documentation across files; and because commits are naturally associated with specific revisions, it can't get out of date. { Still, it does seem a lot of work, and it would be nice to document within the source itself; and in a way that helps and is needed by the code (so it can't get out of date). A bad example: specifically requiring/importing another class before being able to use it. This documents dependencies, and remains current or your code stops working (it would need to be an error to require a class without using it). It is a "bad example" because it doesn't help you, just raises a barrier then "helps" you cross it, like a stand-over man in an extortion racket. What's needed is some immediate benefit (e.g. reduce code) to associating files/classes/methods in a crosscutting "module". }

batista 15y ago

The proliferation of "git tips", and "my git habits", "git best practices" articles, make me think that Git is too complicated for its own good to need all those. (Maybe "need" is a bad choice of words: maybe it doesn't need those articles, but it's too complicated if it gets to have them. You don't get such avalanche of advice for a simple, no BS, tool). Now, the complicated part means it's flexible --in the rare cases you need it to be. But it could probably use a facade that makes the common use cases more intuitive (there are some half-baked attempts that I'm aware of). Personally, I use mercurial.

msbarnett 15y ago
It's not exactly hard to find people discussing different best practices and their own individual workflows in Mercurial, either[1]. The existence of these articles doesn't tell us anything negative about Mercurial, or Git, it merely tells us that these tools are powerful enough to be used for Real Work in Real Workflows, and that there are few things people love more than talking about their workflows. [1]: Random examples: http://stackoverflow.com/questions/448567/best-practices-in-mercurial-branch-vs-clone-and-partial-merges http://stackoverflow.com/questions/448567/best-practices-in-... http://mercurial.selenic.com/wiki/WorkingPractices http://mercurial.selenic.com/wiki/WorkingPractices http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/ http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercu... https://blogs.oracle.com/kto/entry/mercurial_best_practices https://blogs.oracle.com/kto/entry/mercurial_best_practices http://mercurial.808500.n3.nabble.com/Best-practices-for-merging-td2989382.html http://mercurial.808500.n3.nabble.com/Best-practices-for-mer... http://www.stevestreeting.com/2010/04/22/mercurial-queues-just-clicked/ http://www.stevestreeting.com/2010/04/22/mercurial-queues-ju...
gbog 15y ago
Had to switch from mercurial to git. Both are nice, neither is perfect. I long for the time when we won't have to do so much ancillary work to just sync up files. My bet: In 5 years, all these contrived workflows will be replaced by: sync file1 file2 "fix bug 5782"
- tikhonj 15y ago

alpad 15y ago

My first thought: crazy. Especially the part with the printouts and highlighters. Could this actually be effective?

b2spirit 15y ago

Habits pronounced hubbits.

swah 15y ago

When you guys delete a feature/complex function that you wrote just to discover you don't need it, do you guys mark it somehow to know something that worked was removed in that commit?

Feoh 15y ago

I said this in a reply, but lest it get lost in the shuffle, here goes. I have a tremendous amount of respect for mjd. His seminal articles on Perl, particularly "Suffering with Buffering" and "Coping with Scoping" saved my bacon more than once. However, I'm a release engineer, and this is an awful, awful Git work flow. As others have noted, Git was designed so that you can make wacky wild experimental changes off to the side in branches, and only when you're happy, merge them back to your working branch and eventually into master. This approach needlessly complicates things and seems incredibly error prone, especially the bit about having to do house cleaning on the morass of broken commits.