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


Reply via email to