Re: Workflow example for remote repository use of GIT

I have been trying to set-up a workflow for developers in my group using GIT. I came up with this simplified flow. Do you all see any problems with this approach?

Thanks,

Sean

Always work out of master

  git checkout master

Getting The Latest Upstream Code into master

  git pull origin master

Create a topic branch for your development work

  git checkout -b <new topic branch name>

Do your development in the topic branch

  edit/debug/test

Committing Changes

  git commit -a

Switch back to master

  git checkout master

Update the master branch from origin again

  git pull origin master

Now Merge your topic branch

  git pull . <topic branch to merge into current branch>

How do I push my changes to the original repository?

  git push origin master

Hi,

all in all, a good quick start.

On Tue, 28 Nov 2006, Sean Kelley wrote:

This gives the impression that the 2nd argument of pull specifies which _local_ branch stuff gets merged to. But it means that you pull into the _current_ branch from the _remote_ master.

Ciao, Dscho

Sean Kelley <sean.v.kelley@gmail.com> wrote:

...

That can be streamlined slightly:

  git fetch
  git checkout -b <new-topic> origin

as fetch would by default download from remote 'origin' and update
the tracking branches.  And of course developers may not want to
create their new branch from origin, e.g. if they are doing a bug
fix to an earlier release of the product.  I think its a good habit
to be in to always specify the origination point for a branch when
creating it.
 

Sure, that's CVS-like and rather simple.
 

Yes, that works and will get you a merge message like

  Merge branch 'my-topic' into master

which is probably what you want if there actually was a merge. If there wasn't (its just a fast-forward) then you won't get the merge message. It also has the nice property that the "trunk (if there is such a thing)" is the first parent in every merge, with the topic(s) in the other parents.

Though I tend to just pull the origin into the current branch and push that directly, e.g.:

  git pull origin master
  git push origin HEAD:master

Sean Kelley wrote:

This conflicts a bit with later "Create a topic branch" statement.
The statement should be I think twofold: "Never work out of tracking
branches" (if you use separate remotes, git takes care of that for
yourself), and for typical workflow "Always work out of master
or merge changes into master".
 
This of course deopends on the structure of your repo. For example,
how many development branches are there. Git repository uses four
development branches: 'maint' (maintenance, stable, bugfixes),
'master' (trunk, main development, stable), 'next' (development)
and 'pu' (proposed updates, a kind of topic branch digest).

It always is "merge into current branch".

Please read what this mean in git-pull(1):

    ?  A parameter <ref> without a colon is equivalent  to  <ref>:  when
       pulling/fetching,  so  it  merges  <ref>  into the current branch
       without storing the remote branch anywhere locally.

So what "git pull origin master" do is to fetch _single_ remote branch 'master' from remote (repository) 'origin' _without_ storing it anywhere locally (with separate remotes it would be 'remotes/origin/master', without separate remotes it would be 'origin'), and merge it into _current_ branch.

What you usually want to do, when you are on branch "master", is

  git pull origin

or even

  git pull

One might want to create topic branch off other commit than HEAD, using

  git checkout -b <new topic branch name> <branch point>

Depending on your project policy, it might be "git commit -a -s", i.e. add signoff line.

The same comment as above.

By the way, this is _not_ CVS, you can merge your topic branch first, _then_ pull from origin.

I'd point out that '.' means current repository here.

Probably (and better) just "git push origin" if everything is set up correctly.