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@xxxxxxxxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html