I find often that people have hard time to understand Git, they often get stuck in between the local repository and the remote repository where the local is detached and suddenly they end up in a merge conflict.

The conceptual idea of what Git is, is most of the time the main issue, and what shall be stored in Git. You cannot always blame the users when organizations force non-experienced developers to use a version-control system to store various things, without a thought of what shall be stored in Git.

In organizations there are a mixture of people in which does not always have a background in software development, they will more or less use Git as it was a network file system with some extra steps where you put things in to share with your peers.

What experienced developers do really bad is explaining Git with Git terms which will only make a lot more confusing situation. The moment you trying to explain Git you will start pouring out words like, clone, commit, stage, branch, merge, merge conflict, resolve, push, pull, rebase.

When it is just the conceptual idea of how Git sees the world as a tree with snapshots which pointing to a parent snapshot, and how you can as a user change these links between the snapshots, then you can also explain why some commands need to be executed.

!

Otherwise it will end up in as XKCD #1597 explains which you can read above. So if you try to explain Git for some one please make sure you know whats happening with the graph tree, which Git is based on; DAG (Directed Acyclic Graph) which is in simple words a graph without loops, If you follow the relationships from one node you will never end up in the same one you started with. In Git every node in the graph is a commit, a snapshot of the code you working with.

The snapshots can be stored on your computer or on other computers, how you choose to transfer the state of your DAG is up to you, one way is to format patches with git format-patch give it you your friend and and then use git am to apply it, or you can send it by e-mail with git send-mail you can find a good tutorial of git send-mail here. Most common way is to setup a remote with git remote add URL and use the commands push and pull.

The way it is designed the only commit you will have to care about is the latest, because it will always point to a parent commit, and the parent commit will point to it’s parent until the “initial commit”, so then you have the full history.

A commit can have many children which means it is branched. You can change the parent of a commit with the command rebase, this is useful if your local commit is behind the remote tree which is common if you have team mates which is faster than you to write and commit code to the repository. Simple solution is the command bellow:

git pull origin --rebase

That’s how you most of the time can avoid merging every time there is a new commit on the remote. What git is doing it will apply your changes as new commits on top of the latest from the remote origin. This means that you can also delete commits your are not proud of, by adding git pull origin --rebase=i and you have options for each commit. You can also use rebase within branches git rebase a_branch_name

Want to play with rebase follow this tutorial