Shiloh/brotherton-erpnext
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update CONTRIBUTING.md

Browse Source
This commit is contained in:
Rushabh Mehta 2017-03-27 20:41:51 +05:30 committed by GitHub
parent 8bf58367b8
commit fe5c95e360
1 changed files with 23 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
.github/CONTRIBUTING.md vendored
View File

@ -1,21 +1,21 @@
## General Overview
We have three branches where all the work happens:
There are three branches where all the work happens:
* **master** - This is the stable branch based on which we do releases. This branch is for production.
* **develop** - This is an unstable branch for development purposes, it has bleeding edge features and fixes, but it's not recommended for production. Bug fixes and new features go here.
* **hotfix** - This is a branch dedicated to hotfixes on the master branch. Urgent bug fixes go here.
* **master** - This is the production / stable branch for releases.
* **develop** - This is bleeding edge with features and fixes. Non critical bug fixes and new features go here. All updates to master also get pushed to develop.
* **hotfix** - Urgent bug fixes go here. This is merged into master for releases.
## Release Cycles
Once we deem the develop branch to be stable, we merge it into the master and do a major release. The hotfix branch is solely for making urgent bug fixes on the current master branch, which we then merge into master.
We almost never push directly to master.
Usually, hotfix / develop is pushed to master roughly every week.
If we are close to a major release, then all bugfixes get pushed to hotfix and a release is done every week or as necessary.
***
##Workflow
## Contributing
Contributing to ERPNext is not very different from the usual Pull Request workflow on GitHub.
@ -25,19 +25,25 @@ Contributing to ERPNext is not very different from the usual Pull Request workfl
* You need to have a Fork of the [ERPNext repo](https://github.com/frappe/erpnext) in your personal Github account
* You need to add a [remote](#glossary) for your Forked repository. `git remote add origin [your-erpnext-repo-url]`
### The Process:
1. Make sure you're in the right branch. **develop** for adding features / fixing issues and **hotfix** for urgent bug fixes
2. Make your changes
3. Create and checkout a new branch for the changes you've made. `git checkout -b [branch-name]`
4. Add and commit your changes `git commit -am "[commit-message]"
5. If you have been working on sometime for a long time, you should [rebase](#glossary) your branch with our develop branch. `git pull upstream develop --rebase` where `upstream` is the remote name of our repo
5. If you have been working on sometime for a long time, you should [rebase](#glossary) your branch with main develop branch. `git pull upstream develop --rebase` where `upstream` is the remote name of our repo
6. Now, push your changes to your fork. `git push origin [branch-name]`
If you rebased your commits, you will have to [force push](http://vignette2.wikia.nocookie.net/starwars/images/e/ea/Yodapush.png/revision/latest?cb=20130205190454) `git push origin [branch-name] --force`
7. You should now be able to see your pushed branch on Github, now create a pull request against the branch that you want to merge to.
8. Wait for us to review it
### Your Pull Request Should have
1. Clear explanation of the use case
1. Screenshots / Screecast GIF
1. Test Cases (if applicable)
1. Update to documentation
### Common Problems:
* During rebase you might face _merge conflicts_. A merge conflict occurs when you have made changes to the same file that someone else has, in the commits you're pulling. You need to resolve these conflicts by picking which code you want to keep, yours or theirs. You can use `git mergetool` for help.
@ -46,7 +52,7 @@ If you rebased your commits, you will have to [force push](http://vignette2.wiki
### Good practices:
* You should rebase your branch with the branch you plan to make a Pull Request to as often as you can.
* You should rebase your branch with the branch you plan to make a Pull Request (PR) to as often as you can.
* Your commit messages should be precise and explain exactly what the commit does. Same goes for the Pull Request title.
* When making a PR make sure that all your code is committed properly by checking the diffs.
* If you're working on different things at the same time, make sure you make separate branches for each.