text: History in Git - Azure Repos | Microsoft Docs
  If you can't find a change in your Git history that you know you made, learn more about how Git history simplification works at Git lost my changes: Taking a look at Git's history simplification.
  Commit A is the parent of commit B, and commit B is the parent of commit C. This history looks very similar to a CVCS. The arrow pointing to commit C is a branch. It's named main because that's the default name for the mainline branch in a Git repo. Branches are pointers to specific commits, which is why branching is so lightweight and easy in Git.
  A key difference in Git compared to CVCS is that I have my own full copy of the repo. I need to keep my local repository in sync with the remote repository by getting the latest commits from the remote repository. To do this, I'll pull the main branch with the following command:
  This copies ("pulls") all commits from the main branch of the remote repo (called origin by default) to the main branch of the local repo. The pull operation copied one new commit, and the main branch in the local repo is now pointing to this new commit.
  My commits are reachable by the cool-new-feature branch since I made them in that branch. I'm done with my feature and want to merge it into main. To do that I'll use the following command:
  git merge cool-feature main
  The graph structure of history becomes visible when there's a merge. Git creates a new commit when I merged my branch into another branch. This is a merge commit. There aren't any changes included in this merge commit since I didn't have conflicts. If I had conflicts, the merge commit would include the changes needed to resolve those conflicts.
  Here is an example of Git history that more closely resembles code in active development on a team. There are three people who merge commits from their own branches into the main branch around the same time.