Re: Workflow on git with 2 branch with specifc code

[Gordon Freeman <freemanmtc@gmail.com>]

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.
>>
>>
>>
>