github-mirrors/kibana
1
0
Fork 0
mirror of https://github.com/elastic/kibana.git synced 2025-04-23 01:13:23 -04:00
Code Issues Projects Releases Packages Wiki Activity

Add details on how we use Git and GitHub to CONTRIBUTING.md. (#8996)

Browse source 
Backports PR #8978

**Commit 1:**
Add details on how we use Git and GitHub to CONTRIBUTING.md.

* Original sha: d42dd74668
* Authored by CJ Cenizal <cj@cenizal.com> on 2016-11-04T23:50:03Z

**Commit 2:**
Fix typo and add branching examples in CONTRIBUTING.md.

* Original sha: d28e9cea58
* Authored by CJ Cenizal <cj@cenizal.com> on 2016-11-07T17:46:33Z
This commit is contained in:
jasper 2016-11-07 14:26:54 -05:00 • committed by CJ Cenizal
parent 7990617774
commit 5b2bb402a0
1 changed files with 29 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

29
CONTRIBUTING.md
View file

@ -12,6 +12,10 @@ A high level overview of our contributing guidelines.
- [Voicing the importance of an issue](#voicing-the-importance-of-an-issue)
- ["My issue isn't getting enough attention"](#my-issue-isnt-getting-enough-attention)
- ["I want to help!"](#i-want-to-help)
- [How We Use Git and GitHub](#how-we-use-git-and-github)
- [Branching](#branching)
- [Commits and Merging](#commits-and-merging)
- [What Goes Into a Pull Request](#what-goes-into-a-pull-request)
- [Contributing Code](#contributing-code)
- [Setting Up Your Development Environment](#setting-up-your-development-environment)
- [Customizing `config/kibana.dev.yml`](#customizing-configkibanadevyml)
@ -65,6 +69,31 @@ Feel free to bump your issues if you think they've been neglected for a prolonge
We enjoy working with contributors to get their code accepted. There are many approaches to fixing a problem and it is important to find the best approach before writing too much code.
## How We Use Git and GitHub
### Branching
* All work on the next major release goes into master.
* Past major release branches are named `{majorVersion}.x`. They contain work that will go into the next minor release. For example, if the next minor release is `5.2.0`, work for it should go into the `5.x` branch.
* Past minor release branches are named `{majorVersion}.{minorVersion}`. They contain work that will go into the next patch release. For example, if the next patch release is `5.3.1`, work for it should go into the `5.3` branch.
* All work is done on feature branches and merged into one of these branches.
* Where appropriate, we'll backport changes into older release branches.
### Commits and Merging
* Feel free to make as many commits as you want, while working on a branch.
* When submitting a PR for review, please perform an interactive rebase to present a logical history that's easy for the reviewers to follow.
* Please use your commit messages to include helpful information on your changes, e.g. changes to APIs, UX changes, bugs fixed, and an explanation of *why* you made the changes that you did.
* Resolve merge conflicts by rebasing the target branch over your feature branch, and force-pushing.
* When merging, we'll squash your commits into a single commit.
### What Goes Into a Pull Request
* Please include an explanation of your changes in your PR description.
* Links to relevant issues, external resources, or related PRs are very important and useful.
* Please update any tests that pertain to your code, and add new tests where appropriate.
* See [Submitting a Pull Request](#submitting-a-pull-request) for more info.
## Contributing Code
These guidelines will help you get your Pull Request into shape so that a code review can start as soon as possible.