[Documentation] Add explanations of branches to the repo docs#1195
Conversation
|
|
||
| When cutting a [release](https://github.com/18F/web-design-standards/releases), we merge from `staging` to `master`. The `master` branch holds the latest production-ready release, as well as [the production website](https://standards.usa.gov/). | ||
|
|
||
| The branches `18f-pages` and `18f-pages-staging` _used_ to be the primary release & development branches, back when the site was hosted on `pages.18f.gov`. Those branches still auto-deploy to 18F Pages, but will now only contain minimal redirects to the new site. |
There was a problem hiding this comment.
Love use of emphasis on this line 👍 Thanks @yozlet
There was a problem hiding this comment.
Hey! A few minor tweaks to line 118:
When developing, we create a feature branch from staging, do our work in that branch, and then create a pull request that merges back into staging.
There was a problem hiding this comment.
Re: Line 122: Now, this might seem super nitpicky, but I'd recommend replacing the & with the word and (unless there's a specific stylistic reason for using the ampersand).
There was a problem hiding this comment.
One final note (line 122): Please remove the hyphen from auto-deploy!
There was a problem hiding this comment.
Done, and thank you for the nitpicking! (And if you have any pointers for good hyphenation practice, I'm keen to learn.)
There was a problem hiding this comment.
You're most welcome! And hyphenating is, admittedly, tricky business. A general rule of thumb is to hyphenate in instances where the hyphen will clarify the intended meaning — for example, to hyphenate compound adjectives:
mean-spirited dog
However, if the description comes after the noun, no hyphen is necessary:
the dog is mean spirited.
At any rate, I'm always game to talk hyphenation!
|
@kategarklavs could you take a look at the content changes here? The branches have been renamed from |
|
hey @rogeruiz! @kategarklavs and I are going to pair on this later this evening. Hoping to help figure out a better way to do content reviews in PR! 😄 🎉 |
|
Yep! Stay tuned ... we'll have more info soon. On Thu, May 26, 2016 at 9:38 AM, Julia Elman notifications@github.com
|
|
@juliaelman I realised that my branch explanation is wrong, as it talks about merging straight from |
|
@juliaelman gave a 👍 over Slack, so merging. Thanks everyone! |
|
|
||
| The `staging` branch is the bleeding edge of development. When developing, we create a feature branch from `staging`, do our work in that branch, and then create a pull request that merges back into `staging`. New commits to `staging` are automatically deployed to [our staging site](https://standards-staging.usa.gov/). | ||
|
|
||
| The `master` branch always holds the latest production-ready release, as well as [the production website](https://standards.usa.gov/). When cutting a [release](https://github.com/18F/web-design-standards/releases), we create a release branch from `staging` named for the new version: for example, `0.9.2`. Once we've completed QA on that branch, we tag the release and merge it into the `master` branch. |
There was a problem hiding this comment.
@yozlet our release branches follow the v0.9.x naming convention, 0.9.2 is used for tags and releases.
There was a problem hiding this comment.
Double oops, you already did. Thank you!
Description
Minimal explanations of what the
master,staging,18f-pages&18f-pages-stagingbranches are for. Fixes #1189.