Re: Workflow on git with 2 branch with specifc code

> On Sat, Jan 18, 2014 at 10:05 AM, brian m. carlson 
> <sandals@crustytoothpaste.net> wrote:
>> On Fri, Jan 17, 2014 at 10:14:28AM -0200, Gordon Freeman wrote:
>>> Hello guys, im Gordon. I have a question about workflow with git 
>>> that i dont know if im doing it right. I have 1 repo with 2 branchs 
>>> the first is the master of the project. the second is a branch copy 
>>> of the master but he need to have some specifc code because is code 
>>> for a client. so, every time that i updade master i need to merge 
>>> master with client branch and it give me conflicts of course that 
>>> will hapen. Well if was just me who work on this 2 branchs it will 
>>> be easy to fix the conflicts and let all work and shine. But whe 
>>> have here, 10 people woking on master branch and some times code are 
>>> lost on merge and we need to look on commits to search whats goin 
>>> on. What i just asking here is if its correct the workflow that i 
>>> do. If for some problem like this, the community have a standard 
>>> resolution. Or if what im doing here is all wrong. 
>> There are many correct workflows. I personally use the workflow 
>> you've mentioned for the exact same reason (customizations for a 
>> client), but I'm the only developer on that repository. 
> I agree with Brian that there are many correct workflows and which one 
> you choose does depend on details of the branches you are trying to 
> manage. Myself, I would tend to avoid a workflow in which you 
> continually merge from master into the client branch. The reason is 
> that once you have done this 20 times or so it will become quite 
> difficult to understand how and why the client branch diverged from 
> the master branch. Yes, it is in the history, but reasoning about 
> diffs that cross merge points is just hard. Assuming that there is not 
> much actual development on the client branch, but rather a relatively 
> small set of customizations to configuration and things of that kind, 
> then I would tend to maintain the client changes as topic branch, then 
> maintain a client integration branch which represents the merge 
> between master and the client topic branch. Changes that represent 
> divergence of the client from the master branch would be committed to 
> the client topic branch and then merged into the client integration 
> branch. Refreshes from master would be merged into the integration 
> branch. Commits directly to the integration branch would be avoided 
> where possible. Once master has diverged from client enough that there 
> start to be frequent conflicts when merging into the integration 
> branch, then consider rebasing the client topic branch onto the tip of 
> master branch and then repeat the cycle again. There is some risk of 
> history loss with this approach - a later release of the client branch 
> may not be a direct descendent of an earlier release of the client 
> branch, but even this problem can be solved with judicious use of 
> merge -s ours after you have successfully rebased the client topic 
> branch. I can expand on how you do this, if there is interest. jon.