> I'll admit Dawid that I obviously still have a lot to learn about working > with Git, but what I wrote above reflects my workflow on another project, > where we also use Gerrit for doing the code reviews.
I'm not a git expert too, but I've grown to like it for its, surprisingly, simplicity. If you grasp the idea of a commit being a "patch with a parent" then everything becomes really logical. Looking up options and switches to commands in git can be frustrating, but this is "implementation layer" not "understanding of what's happening" layer. > I was referring to our current review style -- I'll upload a patch to JIRA > and get reviews. Yes, for my own history I could commit as many as I want > locally, then squash what I want, drop the ones that I don't etc. At the > moment I'm used to amending the commit, but I know of a coworker of mine who > works like you propose -- many commits and squashing in the end. Your workflow is up to you, Shai. I think amending the same commit over and over is in contrast to what you use a version tracking system for -- you do *want* those changes layered one on top of another. If not for anything else, then for just the possibility that you may want to browse through them and see what you've changed when (I do this a lot). > I thought that if I'm in branch 'feature', I cannot do 'git push' since > there's no remote tracking branch called 'feature'. This is where git does not excel. A "git push" for one person may be different than for another person -- this depends... on the configuration. The push by default tries to send all the "matching" branches -- the ones you have locally that are tracking something on the remote end with the same name. They have been fiddling with the defaults though, so I'm not sure if this is still the case. Grep for "push.default" here: https://git-scm.com/docs/git-config > So just so I'm clear, the sequence of commands you're proposing is: > > git checkout master > git merge --squash feature # review patch here > git push (update origin/master) > > git checkout branch_5x > git cherry-pick master (or the commit hash) > git push (update origin/branch_5x) Yes, that's one of my favorites. It consolidates all the "working" state of a feature into one final diff (patch) which you can review (see above) before pushing. I have pushes set to "matching" so for me it's one final push after I'm done with all the branches. > Can you make it even shorter? :) Yes, you can use what Yonik suggested -- just work on the master branch directly and rebase before you commit. For tiny things this works just fine. Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
