Some good practices for the workflow

• It is not a good idea to open pull requests from the master branch of your fork. (See this) This is mainly because all commits to origin master, after opening the PR and before getting accepted, become a part of the pull request.

• Feature branches can be named feature/*, bugfixes as bugfix/* and hotfixes as hotfix/*. This is purely optional, but it makes it easier for other developers to know what was done in the branch.

• The above convention might also come in handy when configuring automated docker builds for your repository. For e.g. docker image update branch names can be docker/* and the appropriate regex can be configured in docker hub.

• Merging conventions

  • If you want to retain the commit history of the branch, then use the fast forward option while merging:

    git merge --no-ff <branch>
    

    Doing this helps in identifying the exact commits where the feature started and ended.

  • If the branch has a lot of silly commits (maybe you were trying to get travis to work), say something like this:

    

    Surely, you wouldn’t want your clean git log to now show up these commits (these are terrible commit messages by the way). So the solution is to Squash and Merge. If you’re doing it on the terminal, then:

    git checkout master
    git merge --squash <branch>
    git commit
    git push origin master
    

  • The third option is to just use merge which fast-forwards commits by default. If done on the terminal:

    git checkout master
    git merge <branch>
    git commit
    git push origin master