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 <freeman...@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.seym...@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.


        On Sun, Jan 19, 2014 at 3:07 AM, Gordon Freeman
        <freeman...@gmail.com> wrote:

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

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to