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:
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
While
git add -pis 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-dayto 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 -pisn't just for hacking all day without committing any code. I use it for two reasons: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.git rebase -iwithfixup(orsquash).Note that I also have
git cialiased togit commit --verbose, which shows me the diffs in the editor window at commit time.I totally agree.
git add -pis 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 --fixuptogit 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.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(usingeditandgit reset HEAD~) andgit add -pto 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.