Cover Image: Black and Silver Laptop Computer on Round Brown Wooden Table by Christina Morillo
These days, most developers are using some form of v...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for raising this topic. People typically underestimate git's flexibility.
Let me add few notes.
git add -p+git commitmay be replaced with singlegit commit -p. Actually-pis applicable to most file-level commands likeadd,commit,checkoutandstash save.As for
git rebase master: if we are talking about "re-apply my comment on most recent code" then it would probably more handygit pull --rebase origin master: it's like 2-in-1:git fetch+git rebase.And it were not noted here but I believe it's also handy:
git logwith keys-Sand-Gmay really help to find out "when it has been introduced?" or "where it has been removed?".annotateworks on per-line basis that is not granular enough.Another thing is
git bisect: once you have some shell command that fails or succeeds and you'd like to find out commit that "broke things" it's fast way to go.For long, I was merge-averse on feature branches, and used rebase too. But it gets messy once others start interacting with your branches, since after the rebase you need a forced push. That ruins others' state.
So recently I stick with merge commits as you advise.
If you only rebase, no modification to the commits, everyone can rebase to stay up-to-date. Merge conflicts still happen, but git will understand you already have other commits.
But yes, a shared feature branch should be treated as a shared branch.
I love
git commit --amendThanks