Difference between revisions of "Development workflow - webdev"
Line 102: | Line 102: | ||
single space, with blank lines in between, but conventions vary here | single space, with blank lines in between, but conventions vary here | ||
</pre> | </pre> | ||
− | |||
== issues and commits == | == issues and commits == |
Revision as of 22:25, 6 March 2013
This page describes the development model used by the web development team at WormBase using git as our version control system. This includes our branching strategy and release management.
Contents
Overview Diagram
Editable version of the diagram
Branch Strategy
We use branches to help with our release management, testing strategy, and helping with parallel development among the team.
Main branches
Inside the WormBase/website
repository, there are three main branches: master
, dev
and production
.
master
: current, stable code. All new changes brought into master have been tested on staging.wormbase.org and approved by either the curator requesting the change, or the development lead.
dev
: any features/changes ready for testing should be pushed to thedev
branch. This code gets pushed nightly to staging.wormbase.org.
production
: the code currently in production. Branched off ofmaster
at each release.
Supporting branches
Other types of branches used can include feature branches and hotfixes. These branches are only intended to live until the new feature is merged into dev
or the fix is completed.
Feature branches
Any new major features should branch off dev
. Once the feature is ready for testing, it can be merged back into dev
.
Starting a feature
Create a branch from dev
for your work on this feature/issue/bug
git checkout -b myFeature dev
Finishing a feature (ready for testing)
When you're ready to incorporate your feature and have it tested on staging.wormbase.org, you can push your feature branch back to dev
For a smaller feature:
git checkout dev git merge --squash myFeature git commit -v #reference the github issue in your commit message here
You can use --squash
to remove any checkpoint commits you may have added to your branch during development, ie. you may have committed debug statements, or broken changes you have since removed.
If your feature is larger and would benefit from having the work broken down into several commits, you can rebase instead:
git checkout myFeature git rebase --interactive dev
This will open your editor with a list of commits. Each line has the operation to perform (pick
or squash
), the SHA1 for the commit, and the commit message. By default, each commit has the pick
operation:
pick 8af9b68 Update search pick c180b1b bug fix pick 36afac4 work on field titles
Changing the operation to squash
will squash that commit.
pick 8af9b68 Update search squash c180b1b bug fix pick 36afac4 work on field titles
When you save and close the editor, a new editor will pop up for a commit message for the combined commit. Reference the github issue for this feature here.
Now, comment on the github issue to notify all parties involved that the feature will be ready for testing on staging soon.
Moving a feature to master
(pass testing)
Once all features currently on the dev
branch have been tested on staging and approved by either the requesting curator or the development lead, dev
can be merged onto the master
.
git checkout master git merge dev
Hotfixes
If a major bugfix is needed in production, create a hotfix branch from production. When finished, the branch needs to be merged back into production
and dev
Begining a fix
git checkout -b hotfix-issXXX production
Fix the bug and commit the fix in one or more commits. Reference the github issue:
git commit -m "Severe production bug * search redirecting to home page * fix #XXX"
Closing the fix
The fix needs to be merged back to both production
and dev
git checkout dev git merge hotfix-issXXX
git checkout production git merge hotfix-issXXX
Note on Commit Messages
Here is a template originally written by Tim Pope at tpope.net:
Short (50 chars or less) summary of changes More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here
issues and commits
issues 2.0 the next generation
Link to an issue whenever a commit is related to that issue #xxx
.
Using fix #xxx
will close the issue when this commit is pushed to master and notify that the issue will be closed [1].
The following synonyms are supported:
fixes #xxx fixed #xxx fix #xxx closes #xxx close #xxx closed #xxx
Release Management
When production is ready to updated for release WSXXX:
git checkout production git merge master git tag -a WSXXX