Because syncing up the local and remote repositories is so common, Git has a special command that will git fetch and git merge origin/master in one go
git pull
To see an example of this, I've created a new commit on GitHub. Now we run
git pull
In the Git Bash image, you can see how Git first fetched the updates and then automatically performed a merge (fast-forward merge in this case).
Since you will probably be working on teams, most of the time updating your local repository will not be so straightforward since while you were making commits on your local repository, other team members were making commits on their local repositories. Once done, you'll send your changes to the remote (an action called pushing which we'll cover next). But what happens if your local main branch and the remote main branch have diverge?
Because updating the local repository involves fetching the origin and merging, the situations you may encounter are the same as when you merge two local branches: either 1) the other person changed some file which does not affect the files you are changing, or 2) you both updated the same file and you'll have to resolve a merger conflict when pulling.
Let's see an example of the first situation: you changed some files in your local repository that have not been changed in the remote repository. To do this, first we go back to GitHub and write yet another line in the README.md file. Then we create a new local file and commit it. Finally, we git pull.
Because our local and remote main branches had diverged, Git used a three-way merge and created a merge commit.
Because this creates a non-linear history, some people prefer using a git pull --rebase. To see this, first we need to undo the merge commit. Then we run
git pull --rebase
Now we have a linear history, and there is no merge commit.
