Re: Git workflow

From: Thomas Harning <harningt@gmail.com>
Date: Mar 11, 2008, 01:58 UTC
Message-ID: <20080310215852.7f4d7ab5@shiva>
In-Reply-To: <1205152663.3470.12.camel@tigger>

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

Show 12 quoted lines

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

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

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

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