Git workflow

Hi.

There are a number of us working on a project. We each have a HEAD, and work on branches, using git-checkout -b MyPatch. When we have finished working on the branch, we move back to the HEAD, with git-checkout master, do a git-pull and then git-cherry-pick sha1.....

I have two questions. 

1) Is this the normal way to work with git.

2) Also, we sometimes get a log of 
Merge branch 'master' of git://sgit/MyProject which has no commits. Why
does this happen?

Thanks,

Peter

On Mon, 10 Mar 2008 14:37:43 +0200 Peter Gordon <peter@pg-consultants.com> wrote:

Since you always work on your own 'branch', you have no need to check
out a new branch to be independent of others.
If you 'do' work on your own branch, the easier way would be to do one
of the following:
a) git pull
b) Separate branches for separation..
  git checkout master
  git pull -- may cause a merge
  git merge <your branch> -- if you worked on your own branch..git pull
c) Get the latest changes and linearize history
  git fetch
  git rebase origin/master

a - Easiest and more sane
	If you want to work on your own branches you can always
	work on that branch and pull updates from the master
b - Might keep workflow simpler and follows your workflow without
cherry-picks
c - Might be good if you create a simple patch and don't care about the
history and haven't published the branch

git pull performs explicit merges if your repository is not at the exact same point as another. Depending on what has happened, there might be no code changes, but the history is different (perhaps out-of-order 'cherry-picks')

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'.