Hi Akila,

Shall we add these into our wiki?

thanks

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
>



-- 
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/

Reply via email to