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 <[email protected]> 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
