CODEWITHSUNDEEP
gitgit-branchgit-merge
Code Junkie
Code Junkie

Reputation: 1372

How to avoid merge conflits with multiple branch merges?

I am working on a web application with a medium sized team. We are versioning/collectively coding this project using Git. Between my co-worker and myself, I think we are about to run into a difficult merge, and I'd like to see if there's anything we can do better before we run into trouble.

We are primarily working in Git on the develop branch:

D-E-F-G

My co-worker created a branch to work on a big change:

     A
    /
D-E-F-G

Then I pulled that branch down, fixed some bugs in it, and am about to merge it back in. Meanwhile, my co-worker started a new branch for another feature:

     A-B-C-D
    /
D-E-F-G-H-I-J
      \
       A-B-C

Now, I need to create a new feature that uses styles from my co-worker's new branch, but his new branch needs a lot more work before it can be merged back into develop, so I'm branching off of his branch to take advantage of his styles and have a consistant look when his stuff gets merged back in:

     A-B-C-D
    /
D-E-F-G-H-I-J
      \
       A-B-C..
           \
            A

But, we really also need some of the styles he developed in his other branch, so I'm thinking of rebasing develop into my branch as soon as we merge his other branch back into develop:

     branch 1: A-B-C-D
              /       \
 develop: D-E-F-G-H-I-J..
                 \      \
        branch 2: A-B-C..\
                       \  \
              branch 3: A-B..

This way, my branch that I need to work on will have the code I need from both of his branches, but will have been rebased from develop to hopefully reduce conflicts. What concerns me is that he may run into a lot of problems when he tries to merge branch 2 back into develop. Will there be a lot of conflicts for him? Is there something better we can do?

Upvotes: 1

Views: 164

Answers (2)

Adam Dymitruk
Adam Dymitruk

Reputation: 129564

You are running into issues where by merging you are introducing changes you do want and some you don't want.

Make your features smaller.

Start your features from a common point - no matter how clumsy it feels at first.

Use rerere to make remerging easier.

This is summed up in my branch-per-feature post:

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Upvotes: 0

Rodrigo Flores
Rodrigo Flores

Reputation: 2461

For this answer I will assume two things from your explanation:

  • develop is a ready-to-deploy branch which can receive bug-fixes commits and be deployable (or released) anytime (if you don't do this, I strongly recommend you to do so :P).
  • You have only two developers developing features. So, you will not have significant features on develop branch.

So, I would suggest that you create a branch called feature-integration that is rebased with develop on a daily basis (or when you have changes on the develop branch). Then, when your colleague does a significant part of his work, he can merge his code into feature-integration branch and you can use it on your development rebasing feature-integration onto your working branch. You (and your colleague as well) should also keep your working branch code rebased on a regular (I would suggest daily or at least weekly) basis with feature-integration to keep your code updated and solve some eventual conflicts during the development, so you shall not have a painful merge when you decide to merge it into develop.

Upvotes: 2

Related Questions