How to merge branches in 2 different repositories?

Question

I am new to git and I would like to know how to merge Master branch from Sample Project 2 TO UAT branch in St

Answer 1

I would suggest you to create a local clone of the Staging/Support repository. Then you add the project repositories as further remote repositories, which allows you to interact with them in your local repository. Do the merges locally and push the result to the Staging repository.

This can be achieved using the following steps.

Initialization and first merge

$ git clone -o staging http://staging

This clones your staging repository. You will need to replace "http://staging" with the correct URL to your Staging/Support repository. You might also want to give a path where to clone the repository as another parameter. The parameter -o makes sure the remote repository is called "staging" which helps to distinguish it from the project repositories later on.

Next step is to add the remote repository to merge from (in this case "Sample Project 2")

$ git remote add project2 http://sampleproject2

Again, replace "http://sampleproject2" with the URL of the repository "Sample Project 2". You can also change "project2", which is the name of the remote repository, to better fit your project.

After doing that, git branch -r will show the branches from both staging and project2, like this:

$ git branch -r
staging/Production
staging/UAT
project2/Master
project2/QA
project2/DEV

Next checkout the branch you want to merge to, like this:

$ git checkout -b staging_UAT --track staging/UAT

This creates a new local branch called staging_UAT which tracks the remote branch UAT from the staging repository. The new branch will be checked out immediately.

Now you have a copy of the UAT branch from staging checked out. You can merge in the changes from project2:

$ git merge project2/Master

Now all changes from the branch Master of project2 are merged into the current branch (which is staging_UAT). You might want to have a look at git log to see the result. If it fits your expecations, you can push it to the Staging repository:

$ git push staging staging_UAT:UAT

Doing this you push the current state of your local branch staging_UAT to the branch UAT in the remote repository called staging.

You can handle the other projects equally and also add a branch like staging_Production to merge your changes into the Production branch of Staging.

Future merges

You can use the same clone for future merges without doing all the cloning and branch creation again and again. However in this case you need to update your local information about the remote branches:

$ git checkout staging_UAT
$ git pull

First you need to update staging_UAT to match the current version of UAT in the Staging repository. This is done by "pull"ing the changes. As the branch staging_UAT was created with "--track staging/UAT", git knows from where to pull the changes. If UAT on staging is never changed on any other way than this one (meaning: using exactly this local clone to push there from staging_UAT), this is not required.

If UAT is changed on Staging and you do not pull, you will get an error when pushing, saying:

Updates were rejected because the tip of your current branch is behind its remote counterpart.

The other update affects the Project2 repository:

$ git fetch project2

Also the branches of the repository project2 might have been changed. As you can see git fetch is used to get those changes. The difference between fetch and pull is that pull will also update your local copy of the branch. As there is no local copy of the project2 branches, fetch is the way to go. (In fact git pull is just a shortcut for git fetch and git merge).

Adaptions

If you already have a local copy of a repository containing the code, you could also use that for the merging process. You just need to make sure you do not mix up local development and merging and maybe you need to handle more remote repositories as you have some more for your development.

The local branch staging_UAT could also be called just UAT, making the pushing quite simpler (git push would be enough in that case). However this might be confusing as there are branches with this name in multiple remotes.

Alternatively you could change your setting "push.default". See documentation to find out how that would affect your pushing.