The typical effective way to work with Git is to develop on master while running &quot;git pull --rebase&quot; regularly, and before you commit. Prefer to build up a feature as one commit, with &quot;git commit --amend&quot; or &quot;git commit --fixup&quot;. Since you pull and rebase regularly, your code is closely in sync with all shipped changes, and if there are any conflicts you get to resolve them in small incremental pieces. When your change passes CR, push it.<p>The result is a simple, clear, linear commit history with a minimum of effort spent on branching and merging fuss. The fuss is rarely worth it. This model works for quite large teams. After a certain size, it might be better to split the package into several rather than add branching&#x2F;merging complexity.