[Biopython-dev] Working directly on the main git repository

Peter biopython at maubp.freeserve.co.uk
Mon Jun 7 09:35:15 UTC 2010


Hi all,

I thought I'd write down some notes about how I've been using git recently.
This may be of interest to any of the other core developers (those of us
with read-write access to the main repository), and I might get some good
tips from any discussion. The key point is that I have read+write access
to two repositories on github (the official repository AND my own fork),
so there are different advantages/disadvantages about which I choose
to work with directly as my main repository.

Our official repository has just a single stable master branch, and I
often need to work directly with this (e.g. committing small bug fixes
or adding more documentation). I therefore if I setup a clone of the
master repository I can work on the main branch very easily.

Now, when working on a branch for new features, I could just do this
locally, and when they are ready, merge them direct to the master.
However, this means others cannot look at my work (and I find it a
problem when working on multiple machines).

Alternatively, I could push the branches to the public "master" repository.
This would be the simplest option BUT the high visibility gives any such
experimental branch disproportionate status. I think this would be
a good idea for important (multi-person) efforts, like Python 3 work.

Instead, I have a github repository of my own (what github calls a
fork), and I push branches there.

http://github.com/biopython/biopython - the official branch(es)
http://github.com/peterjc/biopython - my branches

How does this work in practice? Like this - I clone the master
and add a reference to my repository (and I do the same when I
want to grab a branch from another developer):

git clone git at github.com:biopython/biopython.git
cd biopython
git remote add peterjc git at github.com:peterjc/biopython.git
git fetch peterjc

Then make a new local branch as usual, and when ready to share
it publicly, I push it to *my* repository on github:

git branch new-work
git checkout new-work
git commit ...
git push peterjc new-work

This would then appear as a new-work branch on my github page.
Then if I (or someone else) wants to access these branches later
(e.g. from another machine) just use the checkout tracked remote
branch. For example,

git clone git at github.com:biopython/biopython.git
cd biopython
git remote add peterjc git at github.com:peterjc/biopython.git
git fetch peterjc
git checkout -t peterjc/seqio-imgt

This then looks like a normal branch (called just "seqio-imgt" in
this example), but git knows it is linked to the remote branch on
the "peterjc" repository (not the origin which is the "official"
repository).

I'd have to check, but I guess that if the original git clone is done
with git://github.com/biopython/biopython.git instead (read only
access) the same procedure could be used by non core devs.
However, I'm not sure this is clearer for them. I think the current
procedure (on our wiki) where you add a remote reference to
the "upstream" official repository works better in this case.

Comments?

Peter

Useful links from Google searches:
http://www.gitready.com/intermediate/2009/01/09/checkout-remote-tracked-branch.html
http://www.gitready.com/beginner/2009/03/09/remote-tracking-branches.html



More information about the Biopython-dev mailing list