horn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Behroz Sikander <behro...@gmail.com>
Subject Re: [DISCUSS] Community's development guidelines
Date Tue, 06 Oct 2015 20:04:02 GMT
*>>I heard that any open pull requests referencing master will need to be*
Hmm I am also new to rebase command and it is just like the merge command
with some internal differences. I do not understand your question fully.

*>>**directly pushed changes to the master cannot be removed.*
I think removal is possible because once we committed credentials of AWS on
github, we had to remove them from the commit history.

On Tue, Oct 6, 2015 at 2:43 PM, Edward J. Yoon <edward.yoon@samsung.com>

> +1 for having some extra branches.
> I heard that any open pull requests referencing master will need to be
> rebased, and directly pushed changes to the master cannot be removed.
> --
> Best Regards, Edward J. Yoon
> -----Original Message-----
> From: Behroz Sikander [mailto:behroz89@gmail.com]
> Sent: Tuesday, October 06, 2015 6:20 PM
> To: dev@horn.incubator.apache.org
> Subject: Re: [DISCUSS] Community's development guidelines
> Hi,
> I have been using git for a while now and I think I can do this task. If
> anyone is also looking to work on this task, he can join me :).
> Here is the git proposed workflow for contributors:
> http://www.apache.org/dev/git.html
> First, I think we should discuss our branching model in Git. Currently, we
> just have 1 branch "master" and to handle a project like Horn we might need
> some extra branches to ease the development and deployment. Here is a very
> good model that I have used previously and it will fit in our project
> nicely [1]. According to this model we should have the following branches
> 1- master - The main branch (Trunk). It holds the horn's production-ready
> code.
> 2- develop - All the current development work is merged here. This work is
> not yet released.
> 3- feature - These are temporary branches and once work is done in these
> branches, it will be deleted and the code will be merged into develop
> branch. All contributors will create a feature branch on their local git
> repos against a Horn Jira issue and once the development is complete they
> can open a pull request. If the pull request is accepted then it will be
> merged to develop branch.
> 4- release - A release branch will be created before any new release of
> Horn.
> 5- hotfix  - If there is a critical Jira issue and we need to fix it asap
> then we create a new hotfix branch, fix the issue and merge the code back
> in develop and master branches.
> This is a suggestion from my side and we can discuss on it.
> [1] http://nvie.com/posts/a-successful-git-branching-model/
> Regards,
> Behroz
> On Tue, Oct 6, 2015 at 3:34 AM, Edward J. Yoon <edwardyoon@apache.org>
> wrote:
> > Hi forks,
> >
> > One of the items to be done is a draft of the community's development
> > guidelines. Firstly, we have to define the rules: 1) Creating and
> > Applying Patches and Pull Requests 2) How to merge patches or pull
> > requests.
> >
> > Does anyone volunteer? Unfortunately, I'm a newbie to git.
> >
> > --
> > Best Regards, Edward J. Yoon
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message