Don't do "git pull" quickly. Always do a "git fetch" THEN "git log HEAD..origin" OR "git log -p HEAD..origin". It is like previewing first what you will "git pull".

OR something like (example):
- git fetch
- git diff origin/master
- git pull --rebase origin master

Sometimes it is a trap, you will pull other unknown or unwanted files that will cause some errors after quickly doing a git pull when working in a team. Better safe than sorry.

Other tips and tricks related are welcome 😀

Credits: https://stackoverflow.com/questions...

Or always work on feature branches so it's always safe to pull on master, and then rebase your branch with master. And do code reviews in PRs, so you don't get surprised with what gets merged. On large teams you might still miss some changes tho, but at least you can check the PR that introduced the conflicting changes to know the reason behind those changes and to know how to resolve them.

@shellbug my fault also, I forgot to check the commit history to see what will be pulled to the develop branch when I did the "git pull origin develop". Oh well at least lesson learned and will not happen again. I also fixed the problem for about 1 hour whew

@rEaL-jAsE hey hey hey

It took 1 hour to fix?

If you do a pull and it automagically merges, quit $EDITOR with an error code (:cq in vim) to tell git to not perform the merge, then execute git merge --abort and you're back to before the pull.

If you get a conflict, execute git merge --abort and you're back to before the pull.

If you can't exit $EDITOR with an error code or for some other reason have to let the merge happen, make sure there's nothing in the working directory you want to lose, and execute git reset --hard <commit ID of HEAD before pull> and you're back to where you were before the pull.

@fdgram the 1 hour to fix is not git related but a code bug