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