Re: Rebasing with merges and conflict resolutions

From: Jon Seymour <jon.seymour@gmail.com>
Date: Mar 26, 2010, 18:11 UTC
Message-ID: <2cfc40321003261111x5a500ef4q9b0caea65a48b21f@mail.gmail.com>
In-Reply-To: <20100326171603.GA12592@kiwi.sharlinx.com>

Show 12 quoted lines

> > > In the future, is there a better way for two developers to work in the same
> > > back-and-forth fashion (code ping pong!) without leading to *heavily* merged
> > > histories that are unpossible to untangle?
> >
> > Discipline. Keep developers focused on their topic. Merge only after a
> > topic is completed. Do not give in to "oh, *your* feature is cool, *I*
> > want to have it now, so I merge it".
>
> I think that's easier said than done, with backend work I'm able to clearly
> define topics, whereas the front-end developers (as it is in this case)
> typically overlap ever so slightly in their work
>

If two developers are working together, then set them up so that each has a public and private repo.

The rule should be:

1. before publishing, A fetches from B to ensure that A has B's latest
public tip
2. A confirms that B's tip includes A's public tip
3. A rebases own private changes (between A public and A private) onto
B's public tip
4. A pushes her rebased private tip to her own public repo
5. B then repeats the cycle with the roles reversed.

This will work provided that B doesn't republish after 2 and before 4, so does require that A and B talk to each other before performing step 4.

jon.