> git checkout -b feature-branch > git commit -a -m "message" > (Get reviews) > git commit --amend (addressing review comments)
How do you get reviews? Did you push feature-branch to origin or did you just create a patch from it? If you did push then it doesn't make sense to amend. If you didn't push then I still don't see any point in amending -- you'd just apply any reviews you see fit and squash for the merge with the mainline. Why bother amending commits that never make it to the mainline? I see only downsides -- you lose the history of what you fixed in response to those reviews, for example. > I do not intend to stack additional commits on top of the initial commit, > and then in the end squash them or whatever. I treat it all as one piece of > work and commit, and I don't think our history should reflect every comment > someone makes on an issue. Why not? I admit I don't understand. A merge squash at the end of your work is essentially combining all the intermediate commits into a single patch -- what's the difference to having one commit amended multiple times? > In analogy, today in JIRA we always update a full > .patch file, and eventually commit it, irrespective of the number of > iterations that issue has gone through. Issues very often have a history of patches, not just the most recent one. > Again, I think we're sync, but wanted to clarify what I meant. I don't think we are, but at the same time I don't think it matters. It's what I said -- how you work on your own branches is your thing. > git checkout master && git pull --rebase (this is nearly identical to the You don't have to rebase anything. This pull will always succeed and will fast-forward to the current origin/master, unless you work directly on your local master branch (which you don't, concluding from your log of commands). > git push origin HEAD:master (this is the equivalent of svn commit) git push will push all remote tracking branches (or current branch), so you could simply do git push. Shorter. > (a) Is this (one of) the correct way to do it? Yes. > (b) Is there a less verbose way to do it, aside from rebasing feature on > origin/branch_5x? You're committing multiple commits on top of master (by rebasing). Like I mentioned before, this is just one way to do it (in my opinion it's inferior to no-fast-forward merge in that it obcures which commits formed a single "feature"). A less verbose way to do it would be to merge --squash your feature into master and then cherry pick a single commit from master to branch_5x. D. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
