Hi William. Thanks for your reply. Havent thought much about bug fixes, but I suppose they could be done on master directly. Is that what youre doing on your current project?
Who is responsible for merging a feature branch with master? I'm guessing there are no restrictions. I think that would be one difference from the forking method, since with forking, not everyone would have\need access to commit\push to the 'main' repo. How would you handle a scenario where someone completes work on a feature branch, merges it into master and then finds that its broken? Would you simply revert master back to known working state and merge the feature branch back in at a later date when its fixed and working? (Wondering if doing something like that messes with the history and causes problems down the line when merging feature branches into master?) Thanks again, Bryan On Wednesday, December 12, 2012 11:00:05 AM UTC-5, William Mizuta wrote: > > Hey Bryan, > > in my current project, we use feature branch to do our tasks, i.e. for > each task we create a new branch in the main repository and everyone can > commit in this branch. Once the task is completed and approved, we merge > the branch into the main (master) and delete this branch. With this > workflow, everyone can continue a job that someone stopped and the main > branch contains only approved features. > > Another way that I know that can help you is pull request. Every member of > the team fork the main project and work on his fork. Once the task is > completed, he can ask for a pull request in the main project, which can be > approved or declined before it is merged in the main project. I don't like > this way of work because each member can ask only one pull request at time. > This way, the member can't start a new task before his pull request was > approved. > > Hope that helped you > > > William Seiti Mizuta > @williammizuta > Desenvolvedor da Caelum > > > > On Wed, Dec 12, 2012 at 1:44 PM, Bryan Migliorisi > <br...@migliorisi.com<javascript:> > > wrote: > >> Hey all, >> >> Just learning Git and I am trying to understand the best workflow for our >> team. For arguments sake, assume we are using Github for >> our private repositories and using Heroku for hosting. >> >> I'd like to have a workflow where our development team commits changes to >> a development branch. Someone (likely me) will be responsible for cherry >> picking commits from the development branch (or branches maybe?) and >> pulling them into a QA branch which is then pushed to our Heroku QA >> repository\app. >> >> Once QAed and approved, I'd like to pull (merge?) the entire QA branch >> into the production branch and push that to our Heroku production >> repository. >> >> >> Some questions: >> >> 1. At a high level, does this make sense and is there a better way? >> The goal is mostly to allow concurrent development while allowing us to >> selectively deploy specific changes. >> 2. Is it best to have separate repositories for each developer and >> have them push changes, once complete, to the main development repo? Or >> should everyone just commit their code to the main development repo? >> 3. Related to above: Should each developer have a separate branch or >> a separate repository? >> 4. Are there any tools to facilitate a workflow like this? Obviously >> command line is immensely powerful. Ive been using SourceTree >> and liking it so far. Also hear Tower is great. GitHub for Mac(\Windows) >> is pretty limiting. >> >> I've read a few blogs\articles describing some workflows similar to this >> but I havent really been able to wrap my head around it entirely. Any >> links would be appreciated. >> >> Thanks in advance! >> >> >> -- >> >> >> > > --
