git add -p
to selectively stage chunks for committing. In this way you can group your changes into commits. Using git add -p
is also just plain handy to stage changes for commit in general because it helps prevent accidentally committing something you do not intend. For the same reason, git commit -a
should be avoided because you don't have the explicit step to review what you are committing. Remember you can do git diff --staged
right before commit for one last review."Fix bug"
and not "Fixed bug"
. This convention matches up with commit messages generated by commands like git merge and git revert. Use the imperative mood ("Move cursor to..."
not "Moves cursor to..."
):art:
🎨 when improving the format/structure of the code.:racehorse:
🐎 when improving performance.:non-potable_water:
🚱 when plugging memory leaks.:memo:
📝 when writing docs:bug:
🐛 when fixing a bug:white_check_mark:
✅ when adding testsmain
or develop
back into it the branch. Merging should be done as a non-fast-forwards (--no-ff
) to ensure a record of the merge exists. However, all merging should be done by means of pull requests, so you don't need to worry about non-fast-forward merges — this doesn't apply to the preview
branch, which is a throw-away branch anyway.main
by means of git rebase main
. This prevents your branch from getting cluttered with merge commits from main
. Be careful if you rebase commits after having pushed to a remote, as if others have the feature branch on their machines, they will likely get ugly merge conflicts when they try to update their feature branch. This is because git-rebase
rewrites the history. (These same cautions go for using git commit --amend
.)main
and the project uses semantic versioning, then the merge should be accompanied by a Git tag.main
Branchmain
branch is protected to prevent direct pushes. All merges should be made through a pull request, which ensures all code changes are peer reviewed before merging to prevent unintentional code reversions. Additionally, protecting branches provides the following benefits:main
. When a new feature or bugfix is complete, we will do a non-fast-forward merge from that branch to staging
or preview
to verify the feature or fix on the stage environment.main
main
branch as the canonical source for live, production code. Feature branches will branch off main
and should always have main
merged back into them before requesting peer code review and before deploying to any staging environments.main
as well, and should be named preview
, staging
or stage-{environment}
for consistency and clarity. Staging branches will never be merged into any other branches. The main
branch can be merged into both staging and feature branches to keep them up-to-date.staging
and main
it is recommended to create a feature branch to act as a staging area. We do this by branching from main
to create the primary feature branch, and then as necessary, create additional branches from the feature branch for distinct items of work. When individual items are complete, merge back to the feature branch. To pull work from main
, merge main
into the feature branch and then merge the feature branch into the individual branches. When all work has been merged back into the feature branch, the feature branch can then be merged into staging
and main
as an entire unit of work.git checkout main
git branch -D branch-name; git push :branch-name
git checkout main
git tag archive/branch-name branch-name
git branch -D branch-name; git push :branch-name
git push origin archive/branch-name
main
branch represents a stable, released, versioned product. Ongoing development will happen in feature branches branched off a develop
branch, which is itself branched off main
. This pattern is commonly referred to as the Gitflow workflow.develop
and, once complete, merged back into develop
using a non-fast-forward merge.develop
is at a state where it’s ready to form a new release, create a new release/<version>
branch off of develop
. In this branch, you’ll bump version numbers, update documentation, and generally prepare your release. Once ready, merge your release branch (using a non-fast-forward merge) into main
and tag the release:Note: Once a version is tagged and released, the tag must never be removed. If there is a problem with the project requiring a re-deployment, create a new version and tag to reflect the change.
main
into develop
so that develop
includes all of the work that was done in your release branch and is aware of the current state of main
.svn-push
script in wp-dev-lib to facilitate the syncing of plugins to WordPress.org. This integration can even be automated by Travis CI.CHANGELOG.md
file, written around the Keep A Changelog standard.develop
branch should contain at least one line in the change log, describing the feature or fix.