Re: best practice for a 3 devs team?

Re: best practice for a 3 devs team?

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 4037 bytes --]

On Tue, Aug 28, 2007 at 17:20:25 -0500, Patrick Aljord wrote:
> Hey all,
> We are 3 developers working on the same project. I was thinking what
> would be the best practice for us. We have just switched from svn and
> for now we are all working on the master branch that we push to a ssh
> git repository.
> I was thinking about maybe each of us could create our own branch like
> 'git branch <dev_name>' but then how would it go? Each one of us would
> push our own branch to the remote repository and each one of us could
> cherry pick the change from the remote branch of each developer. Is
> this the best way to do it? (I guess there is no best way but still :)
> 
> any advice welcome

I'd vote against 1-to-1 mapping between developers and branches. It's
either needlessly inflexible or needlessly complicated, depending how quickly
the mainline changes and how stable it needs to be.

For project under heavy development (where occasional breakage won't hurt too
much and fast progress is desired), I'd recommend you to just keep pushing to
master everyone. This makes new changes immediately visible -- and tested --
by others, so you notice errors quickly. It also makes the workflow easiest,
since you only rebase on master and push it (I'd recommend rebasing work in
progress instead of merging to make the history easier to read). You can
occasionally create a feature branch in the central repository if you want
someone else to test your work in progress, but making your local
repositories readable by the others would work just as well.

On the other hand for project that is expected to provide stable releases,
especially if it's supposed to provide them often, something similar to what
Junio uses for git seems most reasonable. That is, you'd have a master (or
stable) branch for the oncoming release, one or more branches for testing and
a lot of feature branches that would come and go (yes -- in git when you
merge a feature branch for final, you can, and should, just remove it!). Each
developer could have a prefix assigned to avoid conflicts in feature branch
names (Junio currently uses initials of author as prefix).

For every logical change you do, you'd push a feature branch to the central
repository. Than somebody else would pick it up, review it and if it seems
sane, merge it to the most experimental branch. That branch would than be
subjected to testing. Junio currently reverts changes from this most
experimental branch (called 'pu' (proposed updates)) by deleting it,
branching it from 'next' again and re-merging all the still prospective
feature branches in again. This (re-creating a branch) is called rewinding
and you must be careful not to branch of it, or if you do, use rebase rather
than merge with it, but you should not base work on this experimental branch
anyway -- it only exists for creating the test build.

Now the individual feature branches that have seen enough testing in this
experimental branch will go, depending on how careful you need to be, either
to the master, or to a branch, that will be subjected to system test and
become next master after current release (this is the 'next' branch in git).
This branch should now be available for basing further development on, so you
may no longer rewind, so any bugs found here have to be fixed or reverted by
applying reverse patch to whatever one introduced them.

As I said, I'd in any case avoid having per-developer branches and keep
strictly per-feature (per-task). In git, commits don't belong to branches.
Branch is just a pointer to it's head commit. Once further commits are made
on top of it, it does not need any name to be accessible anymore. Therefore
once your features make it into 'master' (or even just 'next'), you can
remove their names -- and reuse them. This way you don't have to think twice
about the feature names, because they are temporary (besides you can also
rename them at any time).

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]