{"thread":{"id":"35710","subject":"Re: Workflow on git with 2 branch with specifc code","startedAt":"2014-01-22T15:00:35Z","lastAt":"2014-01-22T15:00:35Z","messageCount":1,"participants":["Gordon Freeman"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"233514","messageId":"52DFDD13.1010109@gmail.com","threadId":"35710","inReplyTo":"52DFD444.4010907@gmail.com","subject":"Re: Workflow on git with 2 branch with specifc code","fromName":"Gordon Freeman","fromEmail":"freemanmtc@gmail.com","sentAt":"2014-01-22T15:00:35Z","receivedAt":"2014-01-22T15:00:35Z","isPatch":false,"sender":{"key":"freemanmtc@gmail.com","avatar":null},"body":"On 01/22/2014 12:23 PM, Gordon Freeman wrote:\n> On 01/22/2014 12:16 PM, Gordon Freeman wrote:\n>> Oh, sorry if i misunderstand you. My english is not so good.\n>> it will be a pleasure if you could explain that.\n>>\n>> I did some research about topic branchs, and get a lot of useful info \n>> of workflows on the way that you suggest.\n>> I did a lot of tests from the info that i got, most of it from \n>> https://github.com/dchelimsky/rspec/wiki/topic-branches\n>> what i got here from the site is pretty the same of what you wrote \n>> about i think. and the results are pretty good so far.\n>> On the processes i did'nt loose any info, i got some conflicts but \n>> all of them easily solved.\n>>\n>>\n>> 2014/1/20, Gordon Freeman wrote:\n>> Oh, sorry if i misunderstand you. My english is not so good.\n>> it will be a pleasure if you could explain that.\n>> Tanks and sorry for you trouble so far.\n>>\n>>\n>> 2014/1/18 Jon Seymour \n>>\n>> Actually, it wasn't the rebasing I was going to explain, but\n>> a good process for using rebase and preserving the history of\n>> the original, integrated client branch after you have rebased\n>> it. There are good ways and less good ways to do this.\n>>\n>> jon.\n>>\n>>\n>> On Sun, Jan 19, 2014 at 3:07 AM, Gordon Freeman\n>> wrote:\n>>\n>> Hello!\n>> Thx you all guys for the help. That's no need more\n>> explanations here for rebases Jon.\n>> I alredy do a lot of this when i need to change configs\n>> of databases and domains and other things,\n>> of my local branch to do some tests, so this is ok for me.\n>> Seems that i just need some. some people organization here.\n>> I will get that info that you guys provide to our devel\n>> group and aply that.\n>>\n>> Thaks you all for the help.\n>>\n>> On 18/01/2014 01:30, Jon Seymour wrote:\n>>\n>> On Sat, Jan 18, 2014 at 10:05 AM, brian m. carlson\n>> wrote:\n>>\n>> On Fri, Jan 17, 2014 at 10:14:28AM -0200, Gordon\n>> Freeman wrote:\n>>\n>> Hello guys, im Gordon. I have a question\n>> about workflow with git that i dont know if\n>> im doing it right. I have 1 repo with 2\n>> branchs the first is the master of the\n>> project. the second is a branch copy of the\n>> master but he need to have some specifc code\n>> because is code for a client. so, every time\n>> that i updade master i need to merge master\n>> with client branch and it give me conflicts\n>> of course that will hapen. Well if was just\n>> me who work on this 2 branchs it will be easy\n>> to fix the conflicts and let all work and\n>> shine. But whe have here, 10 people woking on\n>> master branch and some times code are lost on\n>> merge and we need to look on commits to\n>> search whats goin on. What i just asking here\n>> is if its correct the workflow that i do. If\n>> for some problem like this, the community\n>> have a standard resolution. Or if what im\n>> doing here is all wrong.\n>>\n>> There are many correct workflows. I personally\n>> use the workflow you've mentioned for the exact\n>> same reason (customizations for a client), but\n>> I'm the only developer on that repository.\n>>\n>> I agree with Brian that there are many correct\n>> workflows and which one you choose does depend on\n>> details of the branches you are trying to manage.\n>> Myself, I would tend to avoid a workflow in which you\n>> continually merge from master into the client branch.\n>> The reason is that once you have done this 20 times\n>> or so it will become quite difficult to understand\n>> how and why the client branch diverged from the\n>> master branch. Yes, it is in the history, but\n>> reasoning about diffs that cross merge points is just\n>> hard. Assuming that there is not much actual\n>> development on the client branch, but rather a\n>> relatively small set of customizations to\n>> configuration and things of that kind, then I would\n>> tend to maintain the client changes as topic branch,\n>> then maintain a client integration branch which\n>> represents the merge between master and the client\n>> topic branch. Changes that represent divergence of\n>> the client from the master branch would be committed\n>> to the client topic branch and then merged into the\n>> client integration branch. Refreshes from master\n>> would be merged into the integration branch. Commits\n>> directly to the integration branch would be avoided\n>> where possible. Once master has diverged from client\n>> enough that there start to be frequent conflicts when\n>> merging into the integration branch, then consider\n>> rebasing the client topic branch onto the tip of\n>> master branch and then repeat the cycle again. There\n>> is some risk of history loss with this approach - a\n>> later release of the client branch may not be a\n>> direct descendent of an earlier release of the client\n>> branch, but even this problem can be solved with\n>> judicious use of merge -s ours after you have\n>> successfully rebased the client topic branch. I can\n>> expand on how you do this, if there is interest. jon.\n>>\n>>\n>>\n>\n"}]}