activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <>
Subject Re: Git workflow for committers
Date Thu, 11 Jun 2015 06:08:13 GMT
Any branch can be deleted, see 'git branch -d' and 'git branch -D'. Also,
remote branches (like one pushed to the origin) can be removed by doing a
'git push origin :branch_name'.

My only question about the use of git feature branches (which I agree
should definitely be used) is the workflow used to get the commits on a
feature branch back to the master, especially for long-lived branches that
are pushed to the origin like Dan is suggesting. Several experiences have
taught me that allowing the default git merging strategy (i.e.,
fast-forward merges) is a very bad idea because it co-mingles all commits
when a feature branch is merged back to the master branch. In the event
that bad commits need to be plucked out after the merge takes place,
fast-forward merges make this task nearly impossible and can create a very
big mess. I've learned through experience that it is always a better idea
to rebase the master onto the feature branch, resolve all conflicts in
isolation on that feature branch and only then do a non-fast-forward merge
of the feature branch to the master branch. Using non-fast-forward merging
keeps the existence of the feature branch intact (even after it has been
deleted and this is key). Use of non-fast-forward merges makes plucking out
commits from a feature branch much, much easier.


On Tue, Jun 9, 2015 at 9:34 PM, Daniel Kulp <> wrote:

> > On Jun 9, 2015, at 9:56 PM, Clebert <> wrote:
> >
> > +1. Although Only question I have:
> >
> > With git it's not really needed to create a branch in the main repo for
> temporary branches.
> Depends on the purpose…..  If I was going to work on a relatively large
> idea/change and want to collaborate with another committer, a branch at
> Apache makes a lot of sense.   For example, I’m thinking about creating one
> to work on the CXF change.  I can keep working on it, all commits would
> still go to the commits@ list so everyone can see what’s going on.
>  Others could help out, etc…  Once “done”, it could be merged to master and
> the branch removed.
> > But If someone did it thought.  Is it easy to remove a branch with
> Apache git?  I have the impression that you need Infra guys to delete
> branches?
> > If only infra structure guys can delete branches I would not encourage
> branches on the main repo.
> The only branch you cannot remove is master.   Anything else is just like
> normal.
> Dan
> >
> > -- Clebert Suconic typing on the iPhone.
> >
> >> On Jun 9, 2015, at 20:22, Daniel Kulp <> wrote:
> >>
> >> I guess if it was up to me to actually write a formal doc describing
> the process it would go something like:
> >>
> >>
> >> ———————
> >>
> >> ActiveMQ uses a Commit-Then-Review process for getting changes
> contributed to the development branches.   In general, this means the
> ActiveMQ committers are free to directly commit their own work to master
> and push those changes to the canonical repository at Apache.   However,
> the expectation is that the developer has made a good effort to test their
> changes and is reasonably confident that the changes that are being
> committed will not “break the build.”
> >>
> >> What does it mean to be reasonably confident?  That may depend on the
> developer.  If the developer has run the same maven commands that the CI
> builds are running, they can likely be reasonably confident.   However, if
> the changes are significant, touches a wide area of code, or even if the
> developer just wants a second opinion, they are encouraged to engage other
> members of the community to obtain an additional review prior to commit.
>  This can easily be done via a pull request on github, a patch file
> attached to an email or JIRA, committed to a branch in the Apache git repo,
> etc…  There are a variety of options open to them.    Having additional
> eyes looking at significant changes prior to committing to the main
> development branches is definitely encouraged if it helps obtain the
> “reasonable confidence” that the build is not broken and code quality has
> not decreased.  We also have automatic builds setup to test github pull
> requests in advance to help establish a good level of confidence in the
> build.
> >>
> >> However, “things happen”.   We’re all human.   In the case where the
> build does break, the expectation is that the developer will make a best
> effort to get the builds fixed in a reasonable amount of time.    If it
> cannot be fixed in a reasonable amount of time, the commit can be reverted
> and re-reviewed.
> >>
> >> ———————
> >>
> >> Everyone:  does that about cover it?    Did I miss anything?    The
> github pull requests and gui tools are definitely a good tool chain in
> certain cases and I would still encourage those folks that find value in
> them to continue using them.   However, they cannot be “required”.
> >>
> >>
> >> Dan
> >>
> >>
> >>
> >>
> >>
> >>
> >>>> On Jun 9, 2015, at 7:57 PM, Clebert Suconic <
>> wrote:
> >>>>
> >>>> +1 to stay with the existing CTR practice that is well established in
> the
> >>>> ActiveMQ community. That's why committership is granted. It's a level
> of
> >>>> trust and confidence that you don't make low hanging fruit errors.
> >>>
> >>> I actually screw up all the time ;) But I rather make eventual
> >>> mistakes than not do something :)
> >>>
> >>> Anyways... lets keep the pull requests as a tool. For instance I just
> >>> prevented an issue because of a PR Build
> >>>
> >>>
> >>>
> >>>
> >>> But I don't want to talk about the issue itself on this Thread... This
> >>> is a meta discussion.. I will talk about the issue itself on another
> >>> post I'm about to make
> >>
> >> --
> >> Daniel Kulp
> >> -
> >> Talend Community Coder -
> >>
> --
> Daniel Kulp
> -
> Talend Community Coder -

perl -e 'print
unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );'

ActiveMQ in Action:

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