3

We use stash(i.e. bit bucket)

We have multiple developers in OUR team who are specialized in different modules in same GIT repository code. And modules are in different directories. Also there are OTHER teams who work on same source (in 'develop' branch) and they could make changes in any of the modules.

e.g.

src

|--module A --

|--module B --

Our team work in a team branch, which is branched off from 'develop' branch.

Now we want to merge 'team' branch to 'develop' branch, and there are merge conflicts in different modules. Specialized developer for each module should fix the merge conflict. Another developer should review the changes via stash (Bit bucket) pull request

What is the best way to achieve this ? To clarify further, What I want to know is how to perform the merge collaboratively ? [I know how to perform a GIT merge using merge tools]

Use same login by all developers and fix the merge conflicts ?

aKumara
  • 395
  • 1
  • 12

2 Answers2

0

Learn how to resolve that here https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-using-the-command-line

OR

Try: git mergetool

It opens a GUI that steps you through each conflict, and you get to choose how to merge. Sometimes it requires a bit of hand editing afterwards, but usually it's enough by itself. It is much better than doing the whole thing by hand certainly.

The command doesn't necessarily open a GUI unless you install one. Running git mergetool for me resulted in vimdiff being used. You can install one of the following tools to use it instead: meld, opendiff, kdiff3, tkdiff, xxdiff, tortoisemerge, gvimdiff, diffuse, ecmerge, p4merge, araxis, vimdiff, emerge.

Below is the sample procedure to use vimdiff for resolve merge conflicts. Based on this link

Step 1: Run following commands in your terminal

git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false

This will set vimdiff as the default merge tool.

Step 2: Run following command in terminal

git mergetool

Step 3: You will see a vimdiff display in following format

  ╔═══════╦══════╦════════╗
  ║       ║      ║        ║
  ║ LOCAL ║ BASE ║ REMOTE ║
  ║       ║      ║        ║
  ╠═══════╩══════╩════════╣
  ║                       ║
  ║        MERGED         ║
  ║                       ║
  ╚═══════════════════════╝

These 4 views are

LOCAL – this is file from the current branch

BASE – common ancestor, how file looked before both changes

REMOTE – file you are merging into your branch

MERGED – merge result, this is what gets saved in the repo

You can navigate among these views using ctrl+w. You can directly reach MERGED view using ctrl+w followed by j.

More info about vimdiff navigation here and here

Step 4. You could edit the MERGED view the following way

If you want to get changes from REMOTE

:diffg RE  

If you want to get changes from BASE

:diffg BA  

If you want to get changes from LOCAL

:diffg LO 

Step 5. Save, Exit, Commit and Clean up

:wqa save and exit from vi

git commit -m "message"

git clean Remove extra files (e.g. *.orig) created by diff tool.

Community
  • 1
  • 1
Lewa Bammy Stephen
  • 401
  • 1
  • 5
  • 14
  • sorry if the question is confusing. What I want to know is the best way to do a collaborative merge ? i know how to do a merge individually. – aKumara Oct 21 '19 at 05:36
0

and there are merge conflicts in different modules.

There should not be merge conflicts when merging team to develop.
Each team should develop in its own module dedicated branch, and rebase said dedicated branch on top of develop first: once the conflicts are resolved locally by the module team, then a (trivial) merge can take between that module branch and develop.
Other teams can then rebase their own module branch, making sure each team member reset their own module branch to take into account the new history, and go on from there.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Hi @VonC, I edited the question "Also there are OTHER teams who work on same source (in 'develop' branch) and they could make changes in any of the modules." Since other teams can make changes in develop branch there could be merge conflicts – aKumara Oct 21 '19 at 04:30
  • @aKumara Exactly: those changes should be make in module dedicated branch (one branch per module). But if those modules are linnked together, then rebase the all team branch on top of develop, and ask each team developer to reset their own local clone of the team branch. The conflict resolution will be local (done by the team), and the merge to develop will then be local. – VonC Oct 21 '19 at 04:32