Re: Git workflow

Peter Gordon <peter@pg-consultants.com> writes:

It does not look "normal" in that I do not see anything that pushes your change back so others can build on top of it. Also cherry-pick is valid but it probably is easier to use "git rebase" frontend.

You need to answer one policy question at the project level. Do you want the shared central repository to be a place for your developers to also share their not-quite-ready-for-master-work-in-progress?

Assuming you don't, for the sake of simplicity for now, you can simplify the workflow by dividing it conceptually into two levels:

 * shared repository 'master' branch is where everybody meets.  Birds-eye
   view of what you do is:

   (0) git clone;

   (1) work locally to advance your 'master';

   (2) "git fetch origin", followed by "git rebase remotes/origin" to make
       sure your changes come on top of whatever others have done while
       you were working in step (1);

   (3) "git push origin master", which pushes back your 'master', so that
       others can build on what you did in step (1);

   (4) go back to (1) to work further.

 * because you always push your 'master' in step (3) above, as long as you
   have what you want in your 'master' at that point, it does not matter
   _how_ you work towards that state in step (1) above.

   You can employ local topic branches (or you can use guilt patch stack),
   and nobody else needs to know about it.  If you have a long-running
   work that won't be ready for the shared 'master', you may locally:

   (a) "git checkout -b my-topic master";

   (b) work locally whenever you find time;

   (c) "git checkout master" if you get interrupted and have more urgent
       things to do;

   (d) "git checkout my-topic" to continue, but from time to time, it
       would be a good idea to "git rebase remotes/origin" while on that
       branch, and when you are finally done with my-topic, then

   (e) after making sure with (2) above that your 'master' is up-to-date,
      "git checkout master", "git merge my-topic".

   (f) then finally "git push origin master".

   But you can consider these steps (a)-(e) merely "implementation
   details" of how you would perform (1) above.

Once you got comfortable with the workflow without topics, more advanced developers among you would find local topic branches handy way to organize their work. But you do not have to. And if you do not use local topics, there is no reason to avoid working directly on 'master'.