You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2018/11/26 18:47:21 UTC
git process to make changes, for committers
Hi,
In the svn world, we have "trunk" and tags. Users make changes to the trunk,
and commit them. The maven release plugin does things with svn, changing
-SNAPSHOT, committing to svn /tags, and the new version to /trunk.
How does this process work for git?
- should committers push changes to a temp branch, and when done, "rebase"
(unless you want to keep the details of every commit that was done in the
branch), and push to "master"? (This seems to emulate the commit to "trunk").
I guess the maven release plugin has some way of working with git;
see
https://stackoverflow.com/questions/39573409/how-to-setup-the-maven-release-plugin-with-git
Is the process for release to use the same mvn release:prepare, and release:perform?
-Marshall
Re: git process to make changes, for committers
Posted by Marshall Schor <ms...@schor.com>.
re: Jenkins being able to monitor and build on pushes to branch name patters:
good to know!
Thanks for leading the way :-) -Marshall
On 11/26/2018 4:24 PM, Richard Eckart de Castilho wrote:
> On 26. Nov 2018, at 22:14, Marshall Schor <ms...@schor.com> wrote:
>> Thanks. For each PR branch, do you need to set up a specific Jenkins
>> configuration / job to build that branch?
> One Jenkins job per repo can monitor all PRs on that repo. It just requires
> some special setup, namely that it be triggered when somebody pushes to the
> GitHub repo (filtered by a specific branch name pattern) and that it picks
> up the commit hash to trigger the proper build.
>
>> (I'm not sure exactly what a "PR branch" would be. Suppose I open a Jira for
>> something that might be of small-medium size, and did a branch for that. Would
>> that be a "PR branch" ?)
> A PR branch would be any branch underlying a PR - in contrast to e.g. the "master"
> branch or "maintenance" branches such as "2.4.x". Not sure if I am using "official"
> terminology here.
>
> For the projects that I am maintaining, I ask people to open PRs as soon as they
> have started working on something and have made the first commit. That makes it
> easier to see who's working on what and allows code reviews and comments even
> as the work is ongoing. Others might prefer opening a PR only once they are done
> with their changes.
>
> Cheers,
>
> -- Richard
Re: git process to make changes, for committers
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 26. Nov 2018, at 22:14, Marshall Schor <ms...@schor.com> wrote:
>
> Thanks. For each PR branch, do you need to set up a specific Jenkins
> configuration / job to build that branch?
One Jenkins job per repo can monitor all PRs on that repo. It just requires
some special setup, namely that it be triggered when somebody pushes to the
GitHub repo (filtered by a specific branch name pattern) and that it picks
up the commit hash to trigger the proper build.
> (I'm not sure exactly what a "PR branch" would be. Suppose I open a Jira for
> something that might be of small-medium size, and did a branch for that. Would
> that be a "PR branch" ?)
A PR branch would be any branch underlying a PR - in contrast to e.g. the "master"
branch or "maintenance" branches such as "2.4.x". Not sure if I am using "official"
terminology here.
For the projects that I am maintaining, I ask people to open PRs as soon as they
have started working on something and have made the first commit. That makes it
easier to see who's working on what and allows code reviews and comments even
as the work is ongoing. Others might prefer opening a PR only once they are done
with their changes.
Cheers,
-- Richard
Re: git process to make changes, for committers
Posted by Marshall Schor <ms...@schor.com>.
Thanks. For each PR branch, do you need to set up a specific Jenkins
configuration / job to build that branch?
(I'm not sure exactly what a "PR branch" would be. Suppose I open a Jira for
something that might be of small-medium size, and did a branch for that. Would
that be a "PR branch" ?)
-Marshall
On 11/26/2018 2:39 PM, Richard Eckart de Castilho wrote:
> On 26. Nov 2018, at 19:57, Marshall Schor <ms...@schor.com> wrote:
>> or, for trivial changes (fixing a typo, etc.),
>>
>> make changes in master checkout, commit to master (locally), and push to remote?
> Yes - for the kind of change that you'd mark "No Jira".
>
> But most of the time, you'd want the CI server to build the change before it gets
> merged - i.e. you have the CI server monitoring PR branches, auto-building them,
> and giving a thumbs up if all goes well... then you merge the change.
>
> Cheers,
>
> -- Richard
Re: git process to make changes, for committers
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 26. Nov 2018, at 19:57, Marshall Schor <ms...@schor.com> wrote:
>
> or, for trivial changes (fixing a typo, etc.),
>
> make changes in master checkout, commit to master (locally), and push to remote?
Yes - for the kind of change that you'd mark "No Jira".
But most of the time, you'd want the CI server to build the change before it gets
merged - i.e. you have the CI server monitoring PR branches, auto-building them,
and giving a thumbs up if all goes well... then you merge the change.
Cheers,
-- Richard
Re: git process to make changes, for committers
Posted by Marshall Schor <ms...@schor.com>.
or, for trivial changes (fixing a typo, etc.),
make changes in master checkout, commit to master (locally), and push to remote?
-Marshall
On 11/26/2018 1:47 PM, Marshall Schor wrote:
> Hi,
>
> In the svn world, we have "trunk" and tags. Users make changes to the trunk,
> and commit them. The maven release plugin does things with svn, changing
> -SNAPSHOT, committing to svn /tags, and the new version to /trunk.
>
> How does this process work for git?
> - should committers push changes to a temp branch, and when done, "rebase"
> (unless you want to keep the details of every commit that was done in the
> branch), and push to "master"? (This seems to emulate the commit to "trunk").
>
> I guess the maven release plugin has some way of working with git;
> see
> https://stackoverflow.com/questions/39573409/how-to-setup-the-maven-release-plugin-with-git
>
> Is the process for release to use the same mvn release:prepare, and release:perform?
>
> -Marshall
>
Re: git process to make changes, for committers
Posted by Marshall Schor <ms...@schor.com>.
interesting...
On 10/24/2019 1:47 PM, Richard Eckart de Castilho wrote:
> On 24. Oct 2019, at 19:19, Marshall Schor <ms...@schor.com> wrote:
>> I think I didn't ever merge your changes, but rather looked at them and then did
>> a copy of them (with some further modifications) into a different branch.
>> (Before I knew about how to do pull requests).
> Well, at least GitHub *thinks* you merged the PRs:
>
> https://github.com/apache/uima-uimaj/pull/11 -> merged
> https://github.com/apache/uima-uimaj/pull/12 -> merged
>
> -- Richard
Re: git process to make changes, for committers
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 24. Oct 2019, at 19:19, Marshall Schor <ms...@schor.com> wrote:
>
> I think I didn't ever merge your changes, but rather looked at them and then did
> a copy of them (with some further modifications) into a different branch.
> (Before I knew about how to do pull requests).
Well, at least GitHub *thinks* you merged the PRs:
https://github.com/apache/uima-uimaj/pull/11 -> merged
https://github.com/apache/uima-uimaj/pull/12 -> merged
-- Richard
Re: git process to make changes, for committers
Posted by Marshall Schor <ms...@schor.com>.
I'm not sure what you're seeing is caused by "rebase". I think it's caused by
me climbing the learning curve on how to do things in GIT...
I think I didn't ever merge your changes, but rather looked at them and then did
a copy of them (with some further modifications) into a different branch.
(Before I knew about how to do pull requests).
-M
On 10/24/2019 4:13 AM, Richard Eckart de Castilho wrote:
> On 6. Jun 2019, at 16:14, Richard Eckart de Castilho <rec@apache.org
> <ma...@apache.org>> wrote:
>>
>> On 6. Jun 2019, at 16:11, Richard Eckart de Castilho <rec@apache.org
>> <ma...@apache.org>> wrote:
>>>
>>> - rebase is nice for small commits
>>
>> ... small PRs (not small commits)
>
> I'll take that back. Attached is a screenshot which highlights why I don't
> really like rebase commits at all.
>
> The red box contains two branches which I created locally and which I had
> created PRs for. I cannot see easily in the history whether these commits have
> already been merged because there is no "arc" from those branches back to the
> branch into which they were merged. Looking carefully at the history, I can
> indeed see the same messages in the master and v2 branches, so I could assume
> that my PRs have been merged - but they could also be other commits just
> bearing the same message. When I try to delete my local branches, my git
> client (Sourcetree) wisely asks me if I am sure I want to do this, because it
> cannot determine either that the changes were merged. If it could it wouldn't
> ask me.
>
> So for what it's worth: I'd prefer staying away from rebase merges.
>
> Cheers,
>
> -- Richard
>
Re: git process to make changes, for committers
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 6. Jun 2019, at 16:14, Richard Eckart de Castilho <re...@apache.org> wrote:
>
> On 6. Jun 2019, at 16:11, Richard Eckart de Castilho <re...@apache.org> wrote:
>>
>> - rebase is nice for small commits
>
> ... small PRs (not small commits)
I'll take that back. Attached is a screenshot which highlights why I don't really like rebase commits at all.
The red box contains two branches which I created locally and which I had created PRs for. I cannot see easily in the history whether these commits have already been merged because there is no "arc" from those branches back to the branch into which they were merged. Looking carefully at the history, I can indeed see the same messages in the master and v2 branches, so I could assume that my PRs have been merged - but they could also be other commits just bearing the same message. When I try to delete my local branches, my git client (Sourcetree) wisely asks me if I am sure I want to do this, because it cannot determine either that the changes were merged. If it could it wouldn't ask me.
So for what it's worth: I'd prefer staying away from rebase merges.
Cheers,
-- Richard
Re: git process to make changes, for committers
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 6. Jun 2019, at 16:11, Richard Eckart de Castilho <re...@apache.org> wrote:
>
> - rebase is nice for small commits
... small PRs (not small commits)
> - squash is ok for larger commits, in particular those where it
> would be tedious to go through the history and fix the commit
> messages where contributors have e.g. forgotten to reference the
> issue number
... larger PRs (not larger commits)
-- Richard
Re: git process to make changes, for committers
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 30. Nov 2018, at 09:08, Joern Kottmann <ko...@gmail.com> wrote:
>
> 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.
For small PRs, that works - but what if you work on something longer
and regularly wish to pull in the changes from master? Ok, I could
re-base the PR, but then I have to do a force-push and people who
might be collaborating with me on the PR need to drop their local
versions and fetch my force-pushed version.
It happens often to me that I work on a PR and need to pull in changes
from master. Usually, I do this using the "Update branch" button
on the GitHub page for the PR - this creates a merge commit. And after
that, trying to rebase the commit on the final merge would probably
cause more effort then it's worth.
So my experience:
- rebase is nice for small commits
- squash is ok for larger commits, in particular those where it
would be tedious to go through the history and fix the commit
messages where contributors have e.g. forgotten to reference the
issue number
- merge commits are the normal case for me, even if the repo graph
may look funky at times. They preserve all commits (contrary to
squash) and there is no risk to annoy anybody with force-pushes.
Cheers,
-- Richard
Re: git process to make changes, for committers
Posted by Marshall Schor <ms...@schor.com>.
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 <ms...@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 <ms...@schor.com> 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
Re: git process to make changes, for committers
Posted by Joern Kottmann <ko...@gmail.com>.
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 <ms...@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 <ms...@schor.com> 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
Re: git process to make changes, for committers
Posted by Marshall Schor <ms...@schor.com>.
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 <ms...@schor.com> 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
Re: git process to make changes, for committers
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 26. Nov 2018, at 22:21, Marshall Schor <ms...@schor.com> 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
Re: git process to make changes, for committers
Posted by Marshall Schor <ms...@schor.com>.
re: rebase; I agree about not doing it when it would affect others who might
have cloned shared repos. In practice, this means only doing it while commits
are only in a local clone. There's lots of commentary on the internet about this.
re: Maven JGitFlow Plugin - that sounds like quite a bit better approach for
releasing, when on Git.
Thanks for the pointer! -Marshall
On 11/26/2018 2:36 PM, Richard Eckart de Castilho wrote:
> On 26. Nov 2018, at 19:47, Marshall Schor <ms...@schor.com> wrote:
>> How does this process work for git?
>> - should committers push changes to a temp branch, and when done, "rebase"
>> (unless you want to keep the details of every commit that was done in the
>> branch), and push to "master"? (This seems to emulate the commit to "trunk").
> There are various strategies. I prefer this one:
>
> https://dkpro.github.io/contributing/ (see heading "Preparing a pull request").
>
> Normally, I "merge" the pull-request branches. That is the easiest and most
> straight-forward approach - in particular if you don't mind that the history
> of the git repo may at some point look more like a knitwork than a straight line.
> At some point, you won't miss the straight line anymore.
>
> In git, the commits are hashed and the hashes are chained. So if you have a commit
> X whose parent is commit A and you rebase X on top of some new commit B, then the
> identity of X changes. Pushing such an updated identity to a branch requires a
> "force push" and gives other people who might have checked out the branch and
> who might have made their own modifications a hard time. Think you are working on
> feature Foo and your colleague is working on feature Bar which is based on Foo (so
> your colleague branched off from Foo, not from master). If you force-push changes
> into the Foo branch, your colleague will have to spend some time reconciling the
> Bar branch - better avoid it.
>
> In rare cases, I rewrite the commit messages of a branch (e.g. if a contributor
> forgot to mention the issue numbers) or I squash the PR (i.e. all commits
> get squashed down into a single commit which is rebased during merge). But I try
> to avoid it.
>
>> I guess the maven release plugin has some way of working with git;
>> see
>> https://stackoverflow.com/questions/39573409/how-to-setup-the-maven-release-plugin-with-git
>>
>> Is the process for release to use the same mvn release:prepare, and release:perform?
> Yep, works. There are alternatives though. Using the Maven Release Plugin requires that
> the development branches always have a version ending in "-SNAPSHOT" in their POMs. Some
> people prefer that e.g. the master branch always represents the latest release. For these,
> people, the Maven Gitflow Plugin may work better. I'm personally using the Maven Release
> Plugin.
>
> Cheers,
>
> -- Richard
Re: git process to make changes, for committers
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 26. Nov 2018, at 19:47, Marshall Schor <ms...@schor.com> wrote:
>
> How does this process work for git?
> - should committers push changes to a temp branch, and when done, "rebase"
> (unless you want to keep the details of every commit that was done in the
> branch), and push to "master"? (This seems to emulate the commit to "trunk").
There are various strategies. I prefer this one:
https://dkpro.github.io/contributing/ (see heading "Preparing a pull request").
Normally, I "merge" the pull-request branches. That is the easiest and most
straight-forward approach - in particular if you don't mind that the history
of the git repo may at some point look more like a knitwork than a straight line.
At some point, you won't miss the straight line anymore.
In git, the commits are hashed and the hashes are chained. So if you have a commit
X whose parent is commit A and you rebase X on top of some new commit B, then the
identity of X changes. Pushing such an updated identity to a branch requires a
"force push" and gives other people who might have checked out the branch and
who might have made their own modifications a hard time. Think you are working on
feature Foo and your colleague is working on feature Bar which is based on Foo (so
your colleague branched off from Foo, not from master). If you force-push changes
into the Foo branch, your colleague will have to spend some time reconciling the
Bar branch - better avoid it.
In rare cases, I rewrite the commit messages of a branch (e.g. if a contributor
forgot to mention the issue numbers) or I squash the PR (i.e. all commits
get squashed down into a single commit which is rebased during merge). But I try
to avoid it.
> I guess the maven release plugin has some way of working with git;
> see
> https://stackoverflow.com/questions/39573409/how-to-setup-the-maven-release-plugin-with-git
>
> Is the process for release to use the same mvn release:prepare, and release:perform?
Yep, works. There are alternatives though. Using the Maven Release Plugin requires that
the development branches always have a version ending in "-SNAPSHOT" in their POMs. Some
people prefer that e.g. the master branch always represents the latest release. For these,
people, the Maven Gitflow Plugin may work better. I'm personally using the Maven Release
Plugin.
Cheers,
-- Richard