[OT] Question about Git branches

Jason Swails jason.swails at gmail.com
Tue Sep 16 09:19:29 EDT 2014


On Tue, 2014-09-16 at 10:59 +0200, Frank Millman wrote:
> "Chris Angelico" <rosuav at gmail.com> wrote in message 
> news:CAPTjJmr5gh8=1zPjG_KdTmA2QgT_5jj=kh=jyvRFv1atL1EeKw at mail.gmail.com...
> > On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
> >> "Frank Millman" <frank at chagford.com>:
> >>
> >>> You are encouraged to make liberal use of 'branches',
> >>
> >> Personally, I only use forks, IOW, "git clone". I encourage that
> >> practice. Then, there is little need for "git checkout". Instead, I just
> >> cd to a different directory.
> >>
> >> Branches and clones are highly analogous processwise; I would go so far
> >> as to say that they are redundant.
> >
> > But rather than listening to, shall we say, *strange* advice like
> > this, Frank, you'll do well to pick up a reliable git tutorial, which
> > should explain branches, commits, the working tree, etc, etc, etc.
> >
> 
> I don't want to turn this into a full-on Git discussion, so briefly -
> 
> 1. I have read all the 'git' tutorials I can find, but they have not 
> addressed my question.
> 2. Albert's response 'commit or stash files before switching branches' makes 
> sense, and actually answers my question.
> 3. I have sympathy for Marko's position of using clones rather than 
> branches. I realise it does not follow the 'git' philosophy, but it does 
> make it more obvious 'where you are', and lessens the chances of shooting 
> yourself in the foot.

I'm with Chris on this one.  I use git extensively (I manage more than
just software with it -- I used it as version tracking when I was
working on my dissertation, articles I'm writing, script databases,
project management, etc.)

One of the code git repos I work with every day is ~4 GB for a working
repo and ~1.6 GB for a bare one.  At any given time, I have ~6 branches
I'm working on.  To have a separate repo for each branch is madness
(especially on a SSD where storage is expensive).  A trick I use to
avoid ever getting lost inside my git repository is to set up my
command-line prompt so it always displays the active branch [1]:

swails at batman ~/amber (master) $ git branch
  amber12-with-patches
  amber13-with-patches
  amber14-with-patches
  amoeba2
  amoeba2_diis
* master
  sander-python
  yorkmaster
swails at batman ~/amber (master) $ git checkout sander-python
Switched to branch 'sander-python'
Your branch is up-to-date with 'origin/sander-python'.
swails at batman ~/amber (sander-python) $ 

Doing everything as branches in the same repository has a number of
other advantages as well.  Merges don't have to be preceded by a fetch
(e.g., a git-pull).  You can cherry-pick individual commits between
branches.  You only have one copy of the git objects.  You can use "git
diff" or "git difftool" to directly compare specific files or folders
between branches or different revisions in diverged history between
branches.  I wouldn't expect you to know all of this git-magic from the
outset, but you will learn it as you need to.  Assigning each branch to
a new clone severely limits git's capabilities. [2]

All the best,
Jason

[1] See http://jswails.wikidot.com/using-git#toc48 for details of how to
do this

[2] Technically this isn't true since each repository will know about
the branches of the other repositories it pulls from, but
cherry-picking, merging, diffing, etc. between a branch and a remote
copy of a branch on the same machine is a lot more convoluted than
working with everything in the same repo (that and you never
accidentally look at an outdated version of a 'local' branch because you
forgot to fetch or pull!)




More information about the Python-list mailing list