My Git Habits
blog.plover.com
My Git Habits
1–10 of 64 posts
Re: My Git Habits
#2git-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.
Re: My Git Habits
#3git commit -v is nice too
Re: My Git Habits
#4I'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.
Re: My Git Habits
#5git-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.
You can also git-add -i to go through the staging area & stage/unstage individual patches.
Re: My Git Habits
#6git-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.
You can also git-add -i to go through the staging area & stage/unstage individual patches.
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.
Re: My Git Habits
#7git-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.
you can use git gui (included) for a mouse-friendly way of doing this.
Re: My Git Habits
#8This 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?
Re: My Git Habits
#9I'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 importan…
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 :)
Re: My Git Habits
#10Maybe 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.