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
> 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,
> This become a major problem for us. How do you handle such scenario?