So, in the past, I got confused by how a git revert command affected the merges. Part of it is due to my TFS background. But anyway, as it turns out, it works exactly how it is supposed to work, once you have a better understanding of how Git works.

A git revert rolls back a specific commit made in the repo. In addition to that, it adds a new commit to indicate that the previous commit was rolled back.

To better explain how this affects merges, I'll try to go over a scenario where I merge branches, then revert a commit in one branch, then try to merge the branches again. So here goes.

Imagine that I have two branches, develop and master. The develop branch was created based off the master branch, so they should have the same code in them.

Let's say that in the develop branch, there were new commits added. Let's call them Commit 1A, Commit 1B and Commit 1C.

Then I decided to merge develop into master.

After the merge, both branches are in sync again. If you look at the history of commits into both branches, at the top of the list would be Commit 1C, then Commit 1B then Commit 1A.

Depending on how you do your merges, the master branch would normally have an extra commit showing the merge from the develop branch. Let's call that Commit 2A. But after that commit though, you would still see Commit 1C, then Commit 1B then Commit 1A, just like in the develop branch.

Anyway the point is, at this moment in time, both branches have the same set of changes/commits. Everything that is in the develop branch, is also in the master branch.

Table below shows the history of commits for both branches.

But then I decided to revert a change in the master branch because it broke something. Let's say I reverted Commit 1B in the master branch. Since a git revert command creates a new commit, it will show up in the history for the master branch too. Let's call this Commit 2B.

Around the same time, I also pushed new code to the develop branch. Let's say that was Commit 1D.

The updated table below shows the commits for both branches at this point in time.

And so what happens now when I merge the develop branch into the master branch?

Previously, I expected that if I merged develop into master at this point in time:

1. I would get Commit 1D added to the master branch and...
2. I would get Commit 1B added back to the master branch...

But that is not how Git works. At least not for the 2nd expectation. That may be the case with a merge in TFS, but not in Git. And that's because of the effect of the git revert command and how Git compares differences between branches during a merge.

The git revert command creates a new commit to track the rolling back of a previous commit. In this case, it created Commit 2B. When you merge develop into the master branch at this point, Git will look at the commit history in the develop branch and will say, “Hey, the master branch has all of the same commits except Commit 1D, so I'll only add Commit 1D into the master branch.”

So what about Commit 1B that was reverted in the master branch, but is still in the develop branch? Why was that not merged?

Since merges are directional (source branch to target branch), Git sees that Commit 1B in the develop branch (source branch) is already in the history of commits for the master branch (target branch). So as far as a merge goes, Commit 1B is already in the master branch and so there is no need to add it during a merge.

Now if you were to reverse the direction of the merge, if you were to merge the master branch into the develop branch, Git will now see that Commit 1B was reverted in the master branch (source branch) via Commit 2B. And so Git will then revert Commit 1B in the develop branch (target branch) by copying the changes from Commit 2B as part of the merge.

So, there you go. I hope this post can help someone else who had trouble understanding how reverts and merges work in Git.

Tags: #Git

Useful References:

• How Git Works
• The Ultimate Guide to Git Reset and Git Revert (freecodecamp.org)

Discuss... or leave a comment below.

git config --global --list

When setting config options, you need to add the location of the config file. So for example, if you want to set core.autocrlf to false as a global or system option, you can run either one of the following commands (depending on the location you want to run it for):

git config --global core.autocrlf false
git config --system core.autocrlf false

Tags: #Git

Discuss... or leave a comment below.

I don't think there is an equivalent in TFS for the git fetch command. The closest thing to it in TFS is probably viewing history, then manually checking to see what changes you are missing. Or doing a merge of branches to see what is different.

In comparison to the git pull command, running git fetch will not pull down any changes. From what I understand, all it does is compare the changes/code in the remote repository with your own local repository. Then it can tell you whether your local repository is behind or ahead, as far as changes go, with the remote repository. This is even better than what you can do in TFS, because it allows you to see exactly what changes you don't have on your local repository.

Tags: #Git #TeamFoundationServer

Discuss... or leave a comment below.

Doing so shows you who made changes, when those changes were made, and what changeset those changes belong to, for the specific line of code you are looking at. It's pretty helpful especially when you're trying to understand the context or history of a specific line of code.

I've been looking for the same feature in Visual Studio Code. Unfortunately, this feature doesn't exist when using Git with Visual Studio Code. But, you can install an extension called Gitlens that does the same thing and then some.

And just to clarify, there is no “Annotate” command/feature in Git. But there is a corresponding one called git-blame.

Tags: #VisualStudioCode #Extensions #Git

Discuss... or leave a comment below.

Here are some notes I made from watching that video:

• The git status command will show you files and folders that have changes. It also shows you files that you've already committed into your local repository, but haven't pushed yet into a remote server.
• The git add command adds files that have changes into a staging area on your local computer.
• The git commit command will commit those changes into your local repository. Emphasis on local. At this point your changes are not saved to a remote server like Github just yet. The committed changes are still on your local Git repository.
• The git push command is the one that will send your changes up to your remote Github repository.

This next tip is not something I learned from the video, but from someplace else that I don't remember.

• To get out of a long results screen from using the git log command, you can type q.

Tags: #Git

Discuss... or leave a comment below.