Workflow on git with 2 branch with specifc code

Workflow on git with 2 branch with specifc code

[Gordon Freeman]

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.

Any help here will be apreciated.
Thx for all.

~                                                                                                                                               
~                                                                                                                                               
~                                                                                                                                               
~                                                                                          

Re: Workflow on git with 2 branch with specifc code

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

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.

What you might try instead is a slightly different workflow.  Have each
developer create a feature branch to add a feature or fix a bug.  Merge
these into master as they become ready.  Have a specific person or group
of people be integrators, and have them merge master into the client
branch as necessary, fixing up any conflicts.  When conflicts are
non-trivial, use pair programming or a review process to ensure that the
result is good.

We use a similar workflow at my regular employer, and it is generally
very successful for a department with 45 employees.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Workflow on git with 2 branch with specifc code

[Jon Seymour]

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.

Re: Workflow on git with 2 branch with specifc code

[Gordon Freeman]

Hello!
Thx you all guys for the help. That's no need more explanations here for 
rebases Jon.
I alredy do a lot of  this when i need to change configs  of databases 
and domains and other things,
of my local branch to do some tests, so this is ok for me.
Seems that i just need some. some people organization here.
I will get that info that you guys provide to our devel group and aply that.

Thaks you all for the help.

On 18/01/2014 01:30, Jon Seymour wrote:
> 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.

Re: Workflow on git with 2 branch with specifc code

[Gordon Freeman]

On 01/22/2014 12:23 PM, Gordon Freeman wrote:
> On 01/22/2014 12:16 PM, Gordon Freeman wrote:
>> Oh, sorry if i misunderstand you. My english is not so good.
>> it will be a pleasure if you could explain that.
>>
>> I did some research about topic branchs, and get a lot of useful info 
>> of workflows on the way that you suggest.
>> I did a lot of tests from the info that i got, most of it from 
>> https://github.com/dchelimsky/rspec/wiki/topic-branches
>> what i got here from the site is pretty the same of what you wrote 
>> about i think. and the results are pretty good so far.
>> On the processes i did'nt loose any info, i got some conflicts but 
>> all of them easily solved.
>>
>>
>> 2014/1/20, Gordon Freeman <freemanmtc@gmail.com> wrote:
>> Oh, sorry if i misunderstand you. My english is not so good.
>> it will be a pleasure if you could explain that.
>> Tanks and sorry for you trouble so far.
>>
>>
>>     2014/1/18 Jon Seymour <jon.seymour@gmail.com>
>>
>>         Actually, it wasn't the rebasing I was going to explain, but
>>         a good process for using rebase and preserving the history of
>>         the original, integrated client branch after you have rebased
>>         it. There are good ways and less good ways to do this.
>>
>>         jon.
>>
>>
>>         On Sun, Jan 19, 2014 at 3:07 AM, Gordon Freeman
>>         <freemanmtc@gmail.com> wrote:
>>
>>             Hello!
>>             Thx you all guys for the help. That's no need more
>>             explanations here for rebases Jon.
>>             I alredy do a lot of  this when i need to change configs
>>              of databases and domains and other things,
>>             of my local branch to do some tests, so this is ok for me.
>>             Seems that i just need some. some people organization here.
>>             I will get that info that you guys provide to our devel
>>             group and aply that.
>>
>>             Thaks you all for the help.
>>
>>             On 18/01/2014 01:30, Jon Seymour wrote:
>>
>>                 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.
>>
>>
>>
>