I’ve been involved in many pull requests where the pull request got discarded and re-created from scratch with a reason of “merge conflicts”. Or people taking half a day to solve “unexpected” or “weird” behavior in their git repository. While reasons are various, one pattern emerged: Most of the time people were committing to the local master, potentially pushing it and having an out-of-sync master on their fork repository, and further along merging from a branch called “master” that doesn’t represent what they think master should represent.
One of the simplest solution is to just not have a local master.
git branch -d master
Further, besides a lot of git features that can be leveraged, I usually get along with the following commands to get the essntial branching right:
# ensure to have the latest local version, and checkout the latest version of the master branch
git fetch origin
git checkout origin/master
# create a branch after checking out origin/master
git checkout -b MyFeatureBranch
# when my pull request has merge conflicts, or I need the latest from master
# in my branch, I prefer rebase instead of merging to keep my history clean and simple
git rebase origin/master
There are some repositories where I keep a local master, for example when working with forked repositories on GitHub. But even then, I only use the master to merge the latest changes from upstream, but follow the pattern described abover.