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 <[email protected]> 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 <[email protected]> wrote: > >> re: Maven JGitFlow Plugin - that sounds like quite a bit better approach > >> for > >> 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
