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