uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: git process to make changes, for committers
Date Thu, 06 Jun 2019 13:34:43 GMT
nice!  -M

On 11/30/2018 3:08 AM, Joern Kottmann wrote:
> I personally also prefer the type of workflow Richard described, all
> (or the great majority) commits is done via feature branches e.g.
> named after the jira ticket.
> This has the advantage that things can be reviewed and improved before
> they are pushed to the master branch.
> At OpenNLP we usually vote with two +1 on the PR before we merge it,
> or at least try to if possible.
> One thing I don't like much are merge commits for tiny amounts of
> work, because that makes it hard to understand the history, and also
> makes it more difficult to use the build in git bisect tool.
> Which I use sometimes and think is a very powerful tool to figure out
> when a bug was introduced.
> The workflow goes like this:
> - Write a test which fails due to the bug
> - Move the test commit back in the history where it runs through
> - Now git bisect can run the test on every commit until it finds the
> commit which introduced the bug (this is done via binary search)
> In git you can rebase the PR on top of master and then commit it, and
> this leads to a much clearer and easier to understand linear history
> compared to merge every PR with a merge commit.
> Jörn
> On Wed, Nov 28, 2018 at 7:36 PM Marshall Schor <msa@schor.com> wrote:
>> Wrapped up into this discussion is an (implicit) choice of a git workflow.
>> See https://www.atlassian.com/git/tutorials/comparing-workflows
>> If I had to guess, I'd say that uimaFIT is following the feature branch git
>> workflow:
>> https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
>> The JGitFlow plugin seems appropriate if  you have a project following the
>> gitFlow workflow:
>> https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
>> It probably would be a good idea to put into some central spot (say, for
>> instance, in uima.apache.org, under perhaps a new page: Git_Workflows) something
>> that describes the intended workflow for various kinds of contributors (e.g.
>> committers, non-committers, etc), and various kinds of actions (doing a new
>> feature, doing a "release", how releases are "tagged", etc.).
>> -Marshall
>> On 11/26/2018 4:26 PM, Richard Eckart de Castilho wrote:
>>> On 26. Nov 2018, at 22:21, Marshall Schor <msa@schor.com> wrote:
>>>> re: Maven JGitFlow Plugin - that sounds like quite a bit better approach
>>>> releasing, when on Git.
>>> I don't see the benefit so far. It's surely hip, but I prefer the traditional
>>> way with the Maven Release Plugin.
>>> Mind, I have no idea so far how to sensibly set up a Jenkins and deploy
>>> SNAPSHOT builds to a Maven repo when using GitFlow.
>>> -- Richard

View raw message