On 01/22/2014 12:23 PM, Gordon Freeman wrote:
Show 118 quoted lines
> 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.
>>
>>
>>
>