I’ve used git for well over a decade, sometimes in a team, but mostly on my own. Once again my career has me working on git in a team, so git pull becomes an issue. Thought I’d write this down to help myself transition away from that command.

This post is a simplification of git, mostly meant to serve as an aide for myself.

git pull is actually two commands

When you run git pull it actually runs git fetch first, and then git merge most likely, depends on your git config.

So it’s perfectly fine to run git pull if you know that you can handle the merge or rebase it will trigger.

But in my experience that’s rare when working with other team members, or just contributing to open source projects.

Because the more activity is done to a remote repo by others, the more likely you are running into conflicts. Conflicts arise when someone else has been working on the same branch as you, and pushed their changes to the remote before you.

It really breaks my workflow when I have to stop and resolve git conflicts, and for the first years with git nothing was scarier to me than a merge conflict.

You really need to learn about git fetch

git fetch fetches all changes from the remote to my local tree, but doesn’t touch my local branch. It’s just there, in the .git folder, ready to be used.

Three things you can do after git fetch

git merge (dry run)

git merge --no-commit --no-ff origin/main to initiate a merge without changing anything, just to see if there are any conflicts.

Then abort the merge with git merge --abort.

git diff

git diff origin/main -- src/server.py will compare the python source file you have in your local branch, with the one you just fetched from the remote.

git log

git log --oneline HEAD..origin/main will tell you what new commits have been added to the remote.

And finally

Run git merge origin/main to actually finish your merge once you know there aren’t any conflicts you can’t resolve easily.

What about rebase?

git rebase is also something worth understanding, and it’s the hardest one for me to explain.

The best docs I’ve seen on git rebase are the Gitlab docs, but I have 22 years of professional experience in IT and I’m still confused when they say “moving a pointer” or “tip of target branch”.

Tip in this case is just the end of the branch, the end of the long series of commits you can see in git log.

When you’re working on a feature branch and run git fetch origin, followed by git rebase origin/main, the target branch is main, all the changes done to main after your fork will be inserted into your feature branch, but your local changes will always be at the end, at the tip of the target branch main in other words.

With that said, rebase is very often used to catch up to all the changes made to main while you were working on your feature-branch. And catching up is important because you need to resolve potential conflicts before you submit your merge request. When you rebase it’s as if you just forked your branch again.