Starting on your newBranch:
git checkout master to get back on the master branch
git pull origin master to get the most up-to-date version of the master branch
git checkout newBranch to get back on your newBranch
git rebase origin/master -i to perform an interactive rebase. The command will take you through and let you pick commits, rename them, squash them, etc. Assuming you will want to keep them all, it will pause when there are merge conflicts and then you'll have to resolve them in your text editor, it will tell you where (in your text editor) that the conflicts occur. You will have to add those files after fixing them then do git rebase --continue to proceed with the rebase.
When you're done with the rebase your newBranch will be synced up with master and have any commits in master that weren't there when you started your work, and all merge conflicts will be resolved so that you can easily merge your newBranch.
Answer from chevybow on Stack OverflowStarting on your newBranch:
git checkout master to get back on the master branch
git pull origin master to get the most up-to-date version of the master branch
git checkout newBranch to get back on your newBranch
git rebase origin/master -i to perform an interactive rebase. The command will take you through and let you pick commits, rename them, squash them, etc. Assuming you will want to keep them all, it will pause when there are merge conflicts and then you'll have to resolve them in your text editor, it will tell you where (in your text editor) that the conflicts occur. You will have to add those files after fixing them then do git rebase --continue to proceed with the rebase.
When you're done with the rebase your newBranch will be synced up with master and have any commits in master that weren't there when you started your work, and all merge conflicts will be resolved so that you can easily merge your newBranch.
It seems that your GitLab is configured to not allow feature branches with merge commits to be merged into the master branch. This is where you took a wrong turn:
After that I committed my local changes and pulled the changes in newbranch to local branch.
What you should have done is to commit your work, and then pull via rebase from the remote newbranch branch. To remedy the situation, I suggest nuking the merge commit which happened when you pulled from GitLab. A merge commit is likely what happened, because git pull by default uses the merge strategy, not the rebase strategy. Check git log, and see how many commits were introduced due to the incorrect pull. Assuming there were only a single merge commit, then the following should do (NOTE: all uncommitted modifications in the working directory will be irreversibly deleted, so save/commit before proceeding):
git reset --hard HEAD~1
Verify again that git log looks correct. You should now see only your latest commit on the top of the branch. Assuming you do see this, then you are good to pull via rebase:
git pull --rebase origin newbranch
This will bring in your colleague's commit, then replay your latest commit on top of the branch. Finally, you may push the branch out, and the problem should be resolved:
git push origin newbranch
Note that doing a hard reset as I have suggested above is generally not a good thing to do. But in your case, no one has seen that merge commit yet, because GitLab rejected your attempt to push. So you should be safe in removing it.