Re: Rebasing with merges and conflict resolutions

[Jon Seymour <jon.seymour@gmail.com>]

> > > 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.