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.
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
togit 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
(usingedit
andgit reset HEAD~
) andgit 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.