Hi Akila, Thank you for the information. These is really helpful.
On Fri, Sep 11, 2015 at 2:59 AM, Akila Ravihansa Perera <raviha...@wso2.com> wrote: > Hi Devs, > > Thought of sharing this since we have some new committers. These are some > guidelines that I think we can adopt in Stratos project. This is only my > personal view, and open to discussion :) > > 1. Always create a branch in your fork when developing a feature or fixing > a bug. We tend to forget this or even deliberately ignore it because we > might think that the fix being done is not worth it. But Git was made for > branching and merging is very cheap. This will avoid many merge conflicts. > Once you are done-done with your task, merge it back to master. > > 2. Know when to use Git rebasing and merging > If you continuously rebase your commits, then the chronological order of > commits will be lost. Meaning that it is very hard to trace a bug by going > through Git history. If you want to know why then read this great article > [1]. > > On the other hand if you continue to use Git merging for even simple > changes, then it will clutter the Git history with lots of ugly merge > commits. Always keep an eye on commit log [2] and try to keep it clean. > This is another good article about rebasing vs merging [3]. > > 3. Incomplete features on the Master Branch > Master branch is not your playground :) Only well tested and complete > features should be merged to master branch. You can continue to work on new > features in your own branch of your personal fork. If someone needs to try > out the latest feature that you are working on then he/she can "pull" from > your "personal" fork, not from our main repo. I don't see any reason why we > should maintain separate branches for new features. If multiple people are > working on a new feature then those people can pull/push from/to each > others' personal forks. Once everything is done-done, that can be merged > back to master. > > 4. No broken builds on the master branch, ever > Please make sure you run a complete maven build "with tests" before you > push major changes to upstream repo. Yes it takes time and resources but > build breaks can negatively affect everyone. If you break the build, others > won't be able to continue with their work and in most cases only you would > know where/how to debug and properly fix it. Mistakes can happen, but if > you happen to build the break please fix it ASAP or temporary revert the > commit until it is resolved. > > Tip: keep a separate VM on the cloud to run complete builds against your > personal branches. There are lots of free cloud offering these days. > > 5. All new features or major changes should be tracked in JIRA > Please put adequate information when you create JIRAs. Also put the commit > ID, fix version(s) in the JIRA when you resolve them. > > > [1] > http://geekblog.oneandoneis2.org/index.php/2013/04/30/please-stay-away-from-rebase > [2] https://github.com/apache/stratos/commits/stratos-4.1.x > [3] > https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/ > > Please share your thoughts. > > Thanks. > -- > Akila Ravihansa Perera > WSO2 Inc.; http://wso2.com/ > > Blog: http://ravihansa3000.blogspot.com > -- *Dinithi De Silva* Associate Software Engineer, WSO2 Inc. m:+94716667655 | e:dinit...@wso2.com | w: www.wso2.com | a: #20, Palm Grove, Colombo 03
