Re: Workflow on git with 2 branch with specifc code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jan 18, 2014 at 10:05 AM, brian m. carlson
<sandals@xxxxxxxxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]