Re: Parallell Development / Switching to GIT

From: Andreas Ericsson <ae@op5.se>
Date: Jun 25, 2009, 10:11 UTC
Message-ID: <4A434D6F.2090105@op5.se>
In-Reply-To: <loom.20090625T095000-90@post.gmane.org>

Patrick Neuner wrote:

Show 8 quoted lines

> Hello,
> 
> we are using SVN right now and with the way we do / need to develop, it seems we
> are constantly get in a merging horror. 
> I did quite some reading about git now, but I am still not really sure if that
> what we try to accomplish can be done with git,
> Or if we are really doing something a too odd way. 
>

Conflicts will still happen with git, but "merge horror" no longer applies,
for a couple of reasons (I come from a similar background, but switched to
git in late 2005).
1. In SVN (and CVS), you're merging *unknown changes* into *unsaved state*.
   You haven't committed your changes to the repository before you merge,
   and you haven't (usually) looked at the upstream changes before you
   try to merge. Git doesn't have this problem (and neither does any other
   distributed version control system), since you first fetch changes from
   someone else and then merge them into an already saved state. When a
   merge conflict resolution goes wahoonie-shaped, you can easily restore
   either of the previously saved states with zero hassle.
2. Git has "rerere", which records and reuses previously resolved merge
   conflicts, so you won't get the same merge-conflict more than once, if
   you enable rerere.
3. SVN (and CVS) won't remember which changes are already merged in, so
   they will fail horribly at repeated same-branch merges. Git (and other
   DAG-based scm's) can and do calculate the merge-base for you so you'll
   never have to think about that yourself.

Show 26 quoted lines

> Let my try to describe – I also added an image. 
> 
> ---- repo 1
>   |
>    - repo 2 (=branch of repo 1 - for our external developers)
> 
> We have the main branch and 2nd branch for external developers. 
> 
> We work inside the repo1, which are usually features/updates that go life after
> a short turn. 
> Our external developer work on different features that will be merged into repo1
> from time to time. 
> 
> Usually during development, we sometimes need to push features from repo1 to
> repo2, and later the features developed on repo2 will be pushed back to repo1, 
> And also smaller bug fixes come from repo2 that needs to go into repo1. 
> 
> But this is a constant process, meaning, that both branches will exist,
> especially repo2 will exist after this feature has finished for smaller
> updates/bugfixes. 
> We don’t want to do a new branch for each bugfix, for each new small feature,
> but have different branches for different developer teams. 
> 
> So I was wondering, if this could cause troubles with GIT in case of merging
> around without closing a branch. 
>

Git doesn't take away merge conflicts, but it does make it (a LOT) easier to handle them when they appear, for the reasons stated above. What you want to do sounds pretty reasonable, although I'd personally use feature-branches for both internal and external developers, since they make it possible to pick which features and fixes you want to release while allowing developers to make as many commits as they feel is necessary for each feature.

> I am adding an link to an image that might show what I tried to explain. 
> http://temp.in.futureweb.at/parallell-development.png
>

We're quite fond of ascii-art here on git@vger. Since I don't know what the different colors mean in the picture, ascii would probably have made more sense (since I then could have commented on it).

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.