Re: [git-users] Git newbie trying to form a development workflow
Hi William, 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?) If the changes made in a branch are not big, the merge will probably be simple. However, it can be a mess if the feature branch took a long time to be done. So, I think that the best way is to divide the feature in small tasks that don't take a long time to be completed and merged in the main branch. We are also trying to implement branch per task workflow in our company. To do a feature X, we divide the feature into several small task that can be done by several people. It is often that the task are depends on other task, so we often have a situation where certain people need to wait for a task to be merged into master before they can start their work. The task that the other tasks depend on is probably has been (functionally) finished, but still pending for approval due to code-review, sanity check, etc. This become a major problem for us. How do you handle such scenario? Regards, Chen --
Re: [git-users] Git newbie trying to form a development workflow
I've been reading about git-flow and doing some experiments, and though I am no expert with it yet, I think its a good tool for these types of scenarios. I have not tried this with the team yet but my idea would be to use git-flow to create a feature branch locally and push that branch up to the origin so that other people can work on that branch. And when all the work is complete, git-flow will merge it back into the development branch and eventually into master, for deployment. On Sunday, December 16, 2012 10:34:59 PM UTC-5, Chen Hendrawan wrote: Hi William, 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?) If the changes made in a branch are not big, the merge will probably be simple. However, it can be a mess if the feature branch took a long time to be done. So, I think that the best way is to divide the feature in small tasks that don't take a long time to be completed and merged in the main branch. We are also trying to implement branch per task workflow in our company. To do a feature X, we divide the feature into several small task that can be done by several people. It is often that the task are depends on other task, so we often have a situation where certain people need to wait for a task to be merged into master before they can start their work. The task that the other tasks depend on is probably has been (functionally) finished, but still pending for approval due to code-review, sanity check, etc. This become a major problem for us. How do you handle such scenario? Regards, Chen --
Re: [git-users] Git newbie trying to form a development workflow
Hello Chen, it is really a big problem when we have tasks that depends on other tasks. To avoid this, our PO try to select tasks that don't depend on each other per iteration. In the next iteration, if the task is done (it includes code-review, test...), the PO selects a task that depends on already done tasks. However, sometimes it's not possible to do. In these cases, I think that the best solution is to define the api of the tasks and create a branch for each one. You don't need to know how the task will be done (implementation), but you know what the task will do (api) and use it in other tasks. This way, we can start a task B that depends on a task A even if A is not done yet. After A is completed, we can merge the branch A into branch B and finish the task B. William Seiti Mizuta @williammizuta Desenvolvedor da Caelum On Mon, Dec 17, 2012 at 1:34 AM, Cahyadi Hendrawan chen.hendra...@gmail.com wrote: Hi William, 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?) If the changes made in a branch are not big, the merge will probably be simple. However, it can be a mess if the feature branch took a long time to be done. So, I think that the best way is to divide the feature in small tasks that don't take a long time to be completed and merged in the main branch. We are also trying to implement branch per task workflow in our company. To do a feature X, we divide the feature into several small task that can be done by several people. It is often that the task are depends on other task, so we often have a situation where certain people need to wait for a task to be merged into master before they can start their work. The task that the other tasks depend on is probably has been (functionally) finished, but still pending for approval due to code-review, sanity check, etc. This become a major problem for us. How do you handle such scenario? Regards, Chen -- --
[git-users] Git newbie trying to form a development workflow
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! --
Re: [git-users] Git newbie trying to form a development workflow
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.comwrote: 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! -- --
Re: [git-users] Git newbie trying to form a development workflow
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.comjavascript: 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! -- --
