re: 3 Git Commands I Use Every Day VIEW POST


While git add -p is nice, I believe the use case of "hacking all day on some changes" without committing any code should be avoided when possible.

Commit early and commit often. This gives me a safety net for when I screw something up. At the end of the day, I can git rebase -i start-of-day to clean up the mess. It is a bit less beginner-friendly, but I like it. Then again, I also like splitting commits during a rebase, as it allows me to "test" them individually during the rebase.


git-add -p isn't just for hacking all day without committing any code. I use it for two reasons:

  1. An easy way to review my changes before I add them. I prefer it to git diff. It also allows me to exclude things that I don't want to check in, such as random extra bits of logging that I no longer need.
  2. So that I can split my work into multiple commits. Maybe these two changes don't actually go together, even though they're in the same file? Maybe I can merge this change with an earlier one? In which case, it should go into a separate commit, so that I can git rebase -i with fixup (or squash).

Note that I also have git ci aliased to git commit --verbose, which shows me the diffs in the editor window at commit time.


I totally agree. git add -p is a wonderful command. But having spent too much time convincing co-workers and friends to commit early, I had to make that comment.

I didn't know about git commit --verbose. That's neat!

As far as rebasing workflows go, I like aliasing git commit --fixup to git fix, so that I can "fix" any relevant commits. The log ends up looking really weird before the rebase, but since I know where each commit should go, it is not an issue.

But having spent too much time convincing co-workers and friends to commit early, I had to make that comment.

Sure. I get that. I commit all the time, to the point that my commit comments are generally just things like safsahghhfdddd, and might only be a line or two.

Once I'm starting to be happy with my branch, I go back with git rebase -i (using edit and git reset HEAD~) and git add -p to split the changes into sensible pieces.

Then I reorder the commits and squash/fixup as relevant so that my PR forms a coherent "story".

I frequently find myself pulling smaller refactorings to the start of the branch, so that they can be cherry-picked into master separately from the other changes. This allows other team members to start using those changes immediately, and reduces the number of conflicts.

code of conduct - report abuse