User talk:Dan-nl/Git and Gerrit/The Workflow

More workflow, more opinion needed
It's great that you're doing this, but it's too bare-bones and not opinionated enough to keep people out of trouble.

I wrote Git & gerrit day-to-day to remind myself of how to work with these tools. I think it's good but I'm not an expert.

The problem is we lack consensus on how best to work, so people like me just develop their own workflow. Then Git/Tutorial and Git/Workflow start diverging, and neither matches the git instructions used elsewhere like wikitech/How to deploy. We need a lot more policy by consistency so instead of n00bs learning a conflicting mish-mash from experts, they learn one approach that works (and experts remain free to do whatever). -- S Page (WMF) (talk) 03:05, 1 January 2013 (UTC)

Missing ideas
These are all in Git & gerrit day-to-day, some need fleshing out. -- S Page (WMF) (talk) 03:05, 1 January 2013 (UTC)

The ^%$$@! split between "gerrit" and "origin" means if you follow two sets of instructions you can wind up with two remotes that point to the same ^%$#! repository. Result: misery. saper wrote up how to fix this in Git/Workflow.
 * name the remote "gerrit":


 * never, ever work on master
 * Always create a new branch for everything you work on.    (Krinkle says have it track the remote master, thus the -t.)


 * always pull --ff-only master
 * The above means you can always grab master without messing up your code. Ensure this with git checkout master; git pull --ff-only.


 * Make detailed commits on local branch, then squash into another branch that you submit for review
 * It's a pain in the ass that gerrit makes you collapse crap into a single gerrit review, so do that separately. Otherwise your git commit --amend can screw up your local change, and you lose work .  (I'm still figuring out how to do this.)