On Wed, Dec 12, 2012 at 3:21 PM, Bryan Migliorisi <br...@migliorisi.com>wrote:
> 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? > Yeah. If a task is very urgent like a bug fix, we do directly in the main branch. > > Who is responsible for merging a feature branch with master? I'm guessing > there are no restrictions. > You are right, Everyone in the team can merge a feature branch in the main. However, the member wait for a approval from the PO (product owner) to merge his changes into the master. > 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. > Yes, this is a good point using pull request. However, like a said in the previous email, a person can only have one pull request. > > How would you handle a scenario where someone completes work on a feature > branch, merges it into master and then finds that its broken? > When someone finishes his task, he tests the task in dev. He doesn't need to merge into the master to test his feature. After the PO approves what he have done in his branch, the changes are merged into the main branch. > 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. --
