Skip to content

5. Git workflow

Jump to bottom
Dominik Schilling edited this page Feb 12, 2016 · 9 revisions

Branches

We use the git flow branching model.

Important: Whenever you have to merge a branch, use the --no-ff flag.
This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature.

  • The master branch represents latest version released in WordPress.org's plugin directory. HEAD of this branch is always equal to last tagged release. The masterbranch is a protected branch.

  • The develop branch represents the cutting edge version. This is probably the one you want to fork from and base your patch on. This is the default GitHub branch.

  • Release branches: When a new version is going to be released, we'll branch from develop to release-x.y.z. This marks version x.y.z code freeze. Only blocking or major bug fixes will be merged to these branches. They represent beta and release candidates.

  • Hotfix branches: When one or several critical issues are found on current released version, we'll branch from master to hotfix-x.y.z+1. If an issue was found on an older version, we'll branch from tags-x.y.z to hotfix-x.y.z+1.

  • Fix or feature branches: Proposed new features and bug fixes should live in their own branch. Use the following naming convention: if a GitHub issue exists for this feature/bugfix, the branch will be named ISSUEID-keywords where ISSUEID is the corresponding GitHub issue ID. If a GitHub issue doesn't exist, branch will be named keywords. These branches will be merged in:

    • hotfix-x.y.z if the change is a fix for a released version,
    • release-x.y.z if the change is a fix for a beta or release candidate,
    • develop for all other cases.

Updating PR's

If you need to update a PR, instead of doing a git merge develop, do a git rebase -i develop followed by a git push -f (forced push) to prevent unneeded commit messages. Read also git merge vs. rebase.

Squash commits into a single commit

In order to keep the develop branch easy to navigate, it is asked that you squash your commits down to a few, or one, discreet changesets before submitting a pull request. Fixing a bug will usually only need one commit, while a larger feature might contain a couple of separate improvements that is easier to track through different commits.

Once you have rebased your work on top of the latest state of the upstream master, you may have several commits related to the issue you were working on. Once everything is done, squash them into a single commit with a descriptive message.

To squash four commits into one, do the following:

$ git rebase -i HEAD~4

In the text editor that comes up, replace the words "pick" with "squash" next to the commits you want to squash into the commit before it. Save and close the editor, and git will combine the "squash"'ed commits with the one before it.

If you've already pushed commits to GitHub, and then squash them locally, you will have to force the push to your branch.

$ git push origin branch-name --force

Helpful hint: You can always edit your last commit message, before pushing, by using:

$ git commit --amend

Thanks to “Todo.txt for Android” for the text.

Clone this wiki locally