Disclaimer: I'm not an expert in Git. This post is me trying to understand how it works, by trying to explain it to someone else. If I've said something wrong in this post, please don't hesitate to correct me by leaving a comment below or getting in touch with me.
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.
To get a list of the global config options for Git, you can run this:
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):
The git pull command is basically like “Get Latest Version” in TFS. It pulls down the latest changes for a repository and merges them into the local files in your computer.
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.
Visual Studio, when used with TFS (Team Foundation Server), has this feature called “Annotate”. You get to it by right clicking somewhere in the code, then selecting Source, then Annotate.
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.
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.