How exactly (with a diagram) does Git Fetch + Merge work?

Question

I'm attempting to merge Git repositories into subfolders under one large repository. Everything was working fine, and I was basically doing:

git remote add -f <name> <url>
git merge <name>/master

However, after doing those steps above, I accidentally removed the new files that came from the remote. I then git-committed. I wanted to "add" them again, so I did another git merge /master, but nothing appeared, and the console output, "Already up-to-date". In my mind, the remote is name/master, which essentially points to the GitHub directory AKA files that I want to add; since my local master branch is pointing to a bunch of files that is missing the remote files, I can just merge them and wah-lah. But apparently I'm definitely misunderstanding something here..

I'm a newbie to all this, so I think it'd be super helpful to have a diagram with pointers and such describing what the above steps do, and what went wrong when I deleted my files?

Appreciate any insight!

Answer 1

Your mistake wasn't that you removed the new files (it can happen to anyone), your error was the new commit. When you did that, your local branch moved forward with your work, then your remote branches were one commit behind. That's why the new git merge didn't work (all your repositories were already merged).

Maybe, you could have undone your last commit:

$ git commit ...(removed files)
$ git reset --soft HEAD~1 (undo last commit)

See this similar example:

Answer 2

Before you deleted the files, the below was the state of your local repo. Note that I am assuming that name of your remote is "origin". Also note that the arrows point from child to parent commit, ie time flows from left to right:

Then, you committed the deletions of the file. This makes master move ahead to point to the new commit:

Then you did a git merge origin/master . What this basically means is "make it so that origin/master is reachable from master ". But as you can see from the diagram, origin/master already is reachable from master . That is why Git says that master is "up to date"; in fact, it is more than "up to date," it is actually ahead of origin/master .

So the question is, how to undo this commit? Well, there are two options. If you have not pushed yet, you can simply move master to point to the last good commit, ie git reset --hard C3 . This will erase any local changes in your working directory, so be careful. After this step, the repo will look like the first diagram.

If, however, you have pushed to the central repo, you are better off making a commit that is the exact opposite of C4 . You do that with git revert C4 . If you do that, your repo will look like:

In this case, C3 and C5 will be exactly identical, and you will have the files back.

By the way, I would highly recommend you go through the Git book , as it explains all this, and much more, in great detail.