Thanks Dawid. I'll try for sport to not amend commits for a while, see how that works out for me :). I'll admit that I already ran into needing to revert a local change cause it didn't work, but I didn't have the "history" to revert to ...
I don't mind typing 'git push origin HEAD:master'. I prefer commands that are explicit. Anyway, I usually do Ctrl+R (in bash) and type the command, which is quickly found in the history. Since it's always the same, I don't really type it all the time. Shai On Mon, Jan 25, 2016 at 11:07 PM Dawid Weiss <[email protected]> wrote: > > 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] > >
