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 <[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
