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 Wed, 07 Oct 2015 10:51:16 GMT
Yea pretty much. All other tutorials also point to the same description.

On Wed, Oct 7, 2015 at 3:43 PM, Edward J. Yoon <edwardyoon@apache.org>
wrote:

> The main purpose of rebase seems related with
> http://stackoverflow.com/questions/4603221/git-merge-in-only-one-commit
> Am I right? :-)
>
> and, Is there other opinions about suggested branching model?
>
> On Wed, Oct 7, 2015 at 5:35 AM, Zachary Jaffee <zij@case.edu> wrote:
> > I am familiar with rebase, instead of thinking of it as a distinct
> branches
> > being fused together with master, think of it as you are plucking the
> > branch you are rebasing off of and putting it on top of the master
> branch.
> > Generally the reason you'd want to do this is that your master branch is
> > very linear in its structure, rather than storing old branches, as old
> > branches, that were merged in. A good general git tutorial is
> > http://pcottle.github.io/learnGitBranching/ but look at some of the
> > tutorials that relate to rebasing, where there is one in most of the
> > categories.
> >
> > On Tue, Oct 6, 2015 at 4:04 PM, Behroz Sikander <behroz89@gmail.com>
> wrote:
> >
> >> *>>I heard that any open pull requests referencing master will need to
> be*
> >> *rebased*
> >> 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.
> >> http://sethrobertson.github.io/GitFixUm/fixup.html
> >>
> >> On Tue, Oct 6, 2015 at 2:43 PM, Edward J. Yoon <edward.yoon@samsung.com
> >
> >> wrote:
> >>
> >> > +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
> >> > >
> >> >
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > Zach Jaffee
> > B.S. Computer Science
> > Case Western Reserve University Class of 2017
> > Operations Director | WRUW FM 91.1 Cleveland
> > Secretary | Recruitment Chair | Phi Kappa Theta Fraternity
> > (917) 881-0646
> > zjaffee.com
> > github.com/ZJaffee
>
>
>
> --
> Best Regards, Edward J. Yoon
>

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