Consider git rebase instead of git merge

You are working on a branch feature/new-feature to add a new feature. You are ready to push to remote and start a pull (or merge) request.

Some of your colleagues already pushed and merged new code in the remote repository, so you need to pull those changes first and merge them with your local copy.

git fetch
git merge master

and you are ready to push. The last commit in your history will be a merge commit.

But if you worked on feature/new-feature for a small amount of time, and you did not push any change already, so that nobody could have pulled it locally, you might want to rebase instead of merge.

You can do it with

git rebase master

The difference is that now, from your repository history, it looks like you started working on feature/new-feature from the new master.

Another difference is that you will need to solve conflicts by one by one and not all together.

First find the conflicts with git diff, then fix it. Then tell git that you solved it with git add <filename> and continue with the rebase git rebase --continue.