From: Gordon Freeman Date: Wed, 22 Jan 2014 15:00:35 GMT Subject: Re: Workflow on git with 2 branch with specifc code Message-ID: <52DFDD13.1010109@gmail.com> In-Reply-To: <52DFD444.4010907@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 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 >> >> 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 >> 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 >> 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. >> >> >> >