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