{"thread":{"id":"9786","subject":"Re: best practice for a 3 devs team?","startedAt":"2007-09-05T19:50:06Z","lastAt":"2007-09-05T19:50:06Z","messageCount":1,"participants":["Jan Hudec"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"52626","messageId":"20070905195006.GG3786@efreet.light.src","threadId":"9786","inReplyTo":"6b6419750708281520u12857b4j3e8f1ca0508f7d51@mail.gmail.com","subject":"Re: best practice for a 3 devs team?","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-09-05T19:50:06Z","receivedAt":"2007-09-05T19:50:06Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Aug 28, 2007 at 17:20:25 -0500, Patrick Aljord wrote:\n> Hey all,\n> We are 3 developers working on the same project. I was thinking what\n> would be the best practice for us. We have just switched from svn and\n> for now we are all working on the master branch that we push to a ssh\n> git repository.\n> I was thinking about maybe each of us could create our own branch like\n> 'git branch <dev_name>' but then how would it go? Each one of us would\n> push our own branch to the remote repository and each one of us could\n> cherry pick the change from the remote branch of each developer. Is\n> this the best way to do it? (I guess there is no best way but still :)\n> \n> any advice welcome\n\nI'd vote against 1-to-1 mapping between developers and branches. It's\neither needlessly inflexible or needlessly complicated, depending how quickly\nthe mainline changes and how stable it needs to be.\n\nFor project under heavy development (where occasional breakage won't hurt too\nmuch and fast progress is desired), I'd recommend you to just keep pushing to\nmaster everyone. This makes new changes immediately visible -- and tested --\nby others, so you notice errors quickly. It also makes the workflow easiest,\nsince you only rebase on master and push it (I'd recommend rebasing work in\nprogress instead of merging to make the history easier to read). You can\noccasionally create a feature branch in the central repository if you want\nsomeone else to test your work in progress, but making your local\nrepositories readable by the others would work just as well.\n\nOn the other hand for project that is expected to provide stable releases,\nespecially if it's supposed to provide them often, something similar to what\nJunio uses for git seems most reasonable. That is, you'd have a master (or\nstable) branch for the oncoming release, one or more branches for testing and\na lot of feature branches that would come and go (yes -- in git when you\nmerge a feature branch for final, you can, and should, just remove it!). Each\ndeveloper could have a prefix assigned to avoid conflicts in feature branch\nnames (Junio currently uses initials of author as prefix).\n\nFor every logical change you do, you'd push a feature branch to the central\nrepository. Than somebody else would pick it up, review it and if it seems\nsane, merge it to the most experimental branch. That branch would than be\nsubjected to testing. Junio currently reverts changes from this most\nexperimental branch (called 'pu' (proposed updates)) by deleting it,\nbranching it from 'next' again and re-merging all the still prospective\nfeature branches in again. This (re-creating a branch) is called rewinding\nand you must be careful not to branch of it, or if you do, use rebase rather\nthan merge with it, but you should not base work on this experimental branch\nanyway -- it only exists for creating the test build.\n\nNow the individual feature branches that have seen enough testing in this\nexperimental branch will go, depending on how careful you need to be, either\nto the master, or to a branch, that will be subjected to system test and\nbecome next master after current release (this is the 'next' branch in git).\nThis branch should now be available for basing further development on, so you\nmay no longer rewind, so any bugs found here have to be fixed or reverted by\napplying reverse patch to whatever one introduced them.\n\nAs I said, I'd in any case avoid having per-developer branches and keep\nstrictly per-feature (per-task). In git, commits don't belong to branches.\nBranch is just a pointer to it's head commit. Once further commits are made\non top of it, it does not need any name to be accessible anymore. Therefore\nonce your features make it into 'master' (or even just 'next'), you can\nremove their names -- and reuse them. This way you don't have to think twice\nabout the feature names, because they are temporary (besides you can also\nrename them at any time).\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"}]}