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.
|
1 |
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:
|
1 2 3 4 5 6 7 8 9 10 |
# 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.