2

I required to merge two repositories without loosing the history of either. I searched several forums but none could provide a complete solution. After performing several steps taken from various sources I could manage to join the missing dots and merge two separate repositories into one repository with their histories intact.

There are several other answers which talk about merging branches or just not with complete instructions/steps.

Nitin Suri
  • 960
  • 1
  • 8
  • 20
  • 1
    Possible duplicate of [How do you merge two Git repositories?](https://stackoverflow.com/questions/1425892/how-do-you-merge-two-git-repositories) – phd May 09 '19 at 08:21
  • https://stackoverflow.com/search?q=%5Bgit%5D+merge+two+repositories – phd May 09 '19 at 08:21
  • Tell a little bit more about the repos and what you want to do. Do they have distinct branches? Or common branches? What should happen to them? What about the working directories? Are they disjunct? Or shall they be merged in some way? – Marcus May 09 '19 at 09:03
  • Hey @Marcus, The two repositories are for the same project but with had different code, one repo had frontend code while the other had the backend code (I was not part of the initial dev so don't even ask why such a foolish setup). Each of the repo only had the MASTER branch. As the code/folder structure is different, the two repositories just required to be merged. Disjunct, YES and NO, as I explained above, same project but code of different areas. – Nitin Suri May 13 '19 at 00:26

2 Answers2

6

If both repos are on your machine, for example you have folders

A/.git
A/client-src

B/.git
B/server-src

simply go to one of them:

cd A

and type:

git remote add repo-b ../B

This creates a symbolic link from repo-a to repo-b ("repo-b" is just a symbolic name, you can choose anything you want) and then

git fetch repo-b

will combine the two repos. At this point, you will have both histories in one repository, but still in different branches. Branch "master" (the master of the folder you are in) will contain client code. Branch "repo-b/master" will contain the server code.

Then you only have to merge the two:

git merge repo-b/master --allow-unrelated

After this, you will have in Repo A a combined master branch. If you are sure there is no other meaningful information in Repo B (Tags, other branches), you can discard it and continue working with Repo A. Both histories will be intact.

For completeness, you should finally delete the now useless link from Repo-A to Repo-B:

git remote remove repo-b
Marcus
  • 617
  • 3
  • 8
1

Below are the steps

git clone <NEW REPO>
cd <NEW REPO FOLDER>
dir > README.MD --> this step is just to initiate the new repository.
git commit -m "initiate the new repository"
git remote add -f <RANDOM NAME A> <OLD BRANCH A>
git remote add -f <RANDOM NAME B> <OLD BRANCH B>
git pull origin master --allow-unrelated-histories
git push -u origin master
git merge --allow-unrelated <RANDOM NAME A>/master
git merge --allow-unrelated <RANDOM NAME B>/master
git push origin master

I believe this post should be of helpful for others.

Nitin Suri
  • 960
  • 1
  • 8
  • 20
  • That's not a particularly good way to do it. In particular, this adds a pointless commit to add a file named `deleteme.txt` and then leaves the commit, and the file, in the merged results. This also combines *two* unrelated histories with a a third repository, which doesn't match the question itself, which only mentions two (not three) input repositories. Last, it only merges `master` branches, when the three repositories may all have multiple branches. But it's not a *wrong* answer: it does tie these three disparate histories together. – torek May 09 '19 at 05:46
  • @torek, I have updated the steps above, instead of the deleteme.txt, you can add a readme.md file. This step is required just to initialise the new repository. – Nitin Suri May 13 '19 at 00:05
  • No separate initialization is necessary, though if you *want* a README.md you should create a real one (and that's a good reason to make a first commit before doing your merges, and hence a good reason for doing it this way). – torek May 13 '19 at 07:16