So we really need to come up with something that works for everyone, but
at least one of these well defined flows:
https://www.atlassian.com/git/tutorials/comparing-workflows
The idea is to use a well established workflow that has at least some
background and stick to it. It's easy to say I've used this and that and
it works for me. That seems to be a more of a git 'problem' that allows
everyone to come up with their own flow. Kind of a step away from a
standard API, but this seems to be why git is winning the scm war. It's
not about personal taste, it is about what do we enforce upon the future
devs that join the project (and ourselves) that will leave them (and us)
in good standing for the rest of the world.
So let's work together to come up with a choice.
I really like the 'Feature Branch Workflow', but if we cannot use it due
to Apache restrictions that would be huge minus for me and make me
wonder why SVN was dropped in the first place. Gitflow 'just' adds a
develop branch as the trunk, and that makes sense to me (master just
being used like the svn 'tags' branch). But it does seem to upset at
least a few people (must just be an Atlassian mistake, and let's not go
anywhere near 'Forking Worklow' ...yes I said 'Forking' :-D ).
The release manager actually faces this maintenance challenge every time
a release is performed in svn or git, as the project was/is not
compatible with any standard/automated Maven release process or plugins
(due to the lack of separation of the OpenEJB and TomEE projects).
Andy.
PS. Something that really got me the other day is the inability to just
export a single directory (eg. examples) from the remote git repo (in a
one liner cmd). How did that get missed in the dev process, or does
anyone have a magic solution to that?
On 27/10/2014 09:12, Jean-Louis Monteiro wrote:
Unfortunately, not enough GIT background to help much in this discussion.
I can only say that I used (copied) the Deltaspike workflow in the past and
it was enough for our needs.
Jean-Louis
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Sun, Oct 26, 2014 at 10:11 PM, Mark Struberg <[email protected]> wrote:
Folks, that gitflow is totally nuts imo!
First, this is a project with only senior devs, this would be the first
ASF project which has Review-Then-Commmit (RTC) on trunk/master. RTC is
usually only done for maintenance- and/or relaese-branches. Everything else
is CTR. The develop branch is just a useless buffer without a build/release
manager who does the review and merging. It will be a hell to maintain.
Second: Creating tons of temporary branches is NOT a good idea for an
upstream cannonical repo.
git push -u origin TOMEE-007
Such things are perfectly fine on private repos or for sending pull
requests, but not on the central ASF repo. Why? Simple because you cannot
delete those branches later (ASF repos are usually configured to prevent
history rewrite). And also opposite to SVN you cannot get back a branch
someone deleted or a history someone rewrote. Once a GIT repo is trashed,
then you can only do a restore of the whole repo from some file backup.
git pull origin develop
Third: You should explain the difference between pull and fetch resp git
pull --rebase
Otherwise our history will either be broken (history rewrite) or full with
useless merge-commits.
LieGrue,
strub
PS: I am using GIT since 2006 and I e.g. wrote the maven-scm-providers-git
stuff back then. GIT IS cool, but also a strong weapon to shoot yourself in
the knee if you don't be careful.
On Friday, 17 October 2014, 17:35, Romain Manni-Bucau <
[email protected]> wrote:
yes, so master is just a single branch showing only tags, what's the
need behind?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-10-17 17:30 GMT+02:00 Andy Gumbrecht <[email protected]>:
Release branches act as a buffer between feature development (develop)
and
public releases (master).
Whenever you merge something into master, you should tag the commit for
reference
git tag -a tomee-1.7.2 -m "TomEE 1.7.2 Release" master
git push --tags
On 17/10/2014 16:46, Romain Manni-Bucau wrote:
sorry I'm surely slow today but it if can avoid me 1h ;): so
what's
different with tags? ie when do you go to master without having a
release?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-10-17 16:41 GMT+02:00 Andy Gumbrecht
<[email protected]>:
Not quite, the /release /branch takes place 'whenever' -
This means it
would
be 'nice' to create it from a stable /develop/, but is NOT
required (this
is
the big +1 for me).
The /release /branch is where the release is polished and prepared
and
all
the tests must 'eventually' pass - work can continue in
/develop/
(another
big +1) - everyone can help make the /release /stable.
When the /release /branch is ready then it is merged to /master
/*and
*/develop /(if there were changes in the /release /then they also
need to
get merged back to /develop/)
The /master /branch only ever contains stable production ready
code.
Andy.
On 17/10/2014 15:54, Daniel Kasmeroglu wrote:
Regarding the creation of a release branch I assume that
creating the
branch from 'develop' implies that all available tests
and quality
criteries must be matched before the actual branching takes
place.
Am I right on this ?
Best regards
Daniel Kasmeroglu
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
