+1000 on rebase before pushing from feature branch -- Clebert Suconic typing on the iPhone.
> On Jun 11, 2015, at 02:08, Bruce Snyder <bruce.sny...@gmail.com> wrote: > > Any branch can be deleted, see 'git branch -d' and 'git branch -D'. Also, > remote branches (like one pushed to the origin) can be removed by doing a > 'git push origin :branch_name'. > > My only question about the use of git feature branches (which I agree > should definitely be used) is the workflow used to get the commits on a > feature branch back to the master, especially for long-lived branches that > are pushed to the origin like Dan is suggesting. Several experiences have > taught me that allowing the default git merging strategy (i.e., > fast-forward merges) is a very bad idea because it co-mingles all commits > when a feature branch is merged back to the master branch. In the event > that bad commits need to be plucked out after the merge takes place, > fast-forward merges make this task nearly impossible and can create a very > big mess. I've learned through experience that it is always a better idea > to rebase the master onto the feature branch, resolve all conflicts in > isolation on that feature branch and only then do a non-fast-forward merge > of the feature branch to the master branch. Using non-fast-forward merging > keeps the existence of the feature branch intact (even after it has been > deleted and this is key). Use of non-fast-forward merges makes plucking out > commits from a feature branch much, much easier. > > Bruce > >> On Tue, Jun 9, 2015 at 9:34 PM, Daniel Kulp <dk...@apache.org> wrote: >> >> >>> On Jun 9, 2015, at 9:56 PM, Clebert <clebert.suco...@gmail.com> wrote: >>> >>> +1. Although Only question I have: >>> >>> With git it's not really needed to create a branch in the main repo for >> temporary branches. >> >> Depends on the purpose….. If I was going to work on a relatively large >> idea/change and want to collaborate with another committer, a branch at >> Apache makes a lot of sense. For example, I’m thinking about creating one >> to work on the CXF change. I can keep working on it, all commits would >> still go to the commits@ list so everyone can see what’s going on. >> Others could help out, etc… Once “done”, it could be merged to master and >> the branch removed. >> >>> But If someone did it thought. Is it easy to remove a branch with >> Apache git? I have the impression that you need Infra guys to delete >> branches? >>> If only infra structure guys can delete branches I would not encourage >> branches on the main repo. >> >> The only branch you cannot remove is master. Anything else is just like >> normal. >> >> Dan >> >> >>> >>> -- Clebert Suconic typing on the iPhone. >>> >>>> On Jun 9, 2015, at 20:22, Daniel Kulp <dk...@apache.org> wrote: >>>> >>>> I guess if it was up to me to actually write a formal doc describing >> the process it would go something like: >>>> >>>> >>>> ——————— >>>> >>>> ActiveMQ uses a Commit-Then-Review process for getting changes >> contributed to the development branches. In general, this means the >> ActiveMQ committers are free to directly commit their own work to master >> and push those changes to the canonical repository at Apache. However, >> the expectation is that the developer has made a good effort to test their >> changes and is reasonably confident that the changes that are being >> committed will not “break the build.” >>>> >>>> What does it mean to be reasonably confident? That may depend on the >> developer. If the developer has run the same maven commands that the CI >> builds are running, they can likely be reasonably confident. However, if >> the changes are significant, touches a wide area of code, or even if the >> developer just wants a second opinion, they are encouraged to engage other >> members of the community to obtain an additional review prior to commit. >> This can easily be done via a pull request on github, a patch file >> attached to an email or JIRA, committed to a branch in the Apache git repo, >> etc… There are a variety of options open to them. Having additional >> eyes looking at significant changes prior to committing to the main >> development branches is definitely encouraged if it helps obtain the >> “reasonable confidence” that the build is not broken and code quality has >> not decreased. We also have automatic builds setup to test github pull >> requests in advance to help establish a good level of confidence in the >> build. >>>> >>>> However, “things happen”. We’re all human. In the case where the >> build does break, the expectation is that the developer will make a best >> effort to get the builds fixed in a reasonable amount of time. If it >> cannot be fixed in a reasonable amount of time, the commit can be reverted >> and re-reviewed. >>>> >>>> ——————— >>>> >>>> Everyone: does that about cover it? Did I miss anything? The >> github pull requests and gui tools are definitely a good tool chain in >> certain cases and I would still encourage those folks that find value in >> them to continue using them. However, they cannot be “required”. >>>> >>>> >>>> Dan >>>> >>>> >>>> >>>> >>>> >>>> >>>>>> On Jun 9, 2015, at 7:57 PM, Clebert Suconic < >> clebert.suco...@gmail.com> wrote: >>>>>> >>>>>> +1 to stay with the existing CTR practice that is well established in >> the >>>>>> ActiveMQ community. That's why committership is granted. It's a level >> of >>>>>> trust and confidence that you don't make low hanging fruit errors. >>>>> >>>>> I actually screw up all the time ;) But I rather make eventual >>>>> mistakes than not do something :) >>>>> >>>>> Anyways... lets keep the pull requests as a tool. For instance I just >>>>> prevented an issue because of a PR Build >>>>> >>>>> https://builds.apache.org/job/ActiveMQ-Artemis-PR-Build/418/ >>>>> https://github.com/apache/activemq-artemis/pull/22 >>>>> >>>>> But I don't want to talk about the issue itself on this Thread... This >>>>> is a meta discussion.. I will talk about the issue itself on another >>>>> post I'm about to make >>>> >>>> -- >>>> Daniel Kulp >>>> dk...@apache.org - http://dankulp.com/blog >>>> Talend Community Coder - http://coders.talend.com >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com > > > -- > perl -e 'print > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );' > > ActiveMQ in Action: http://bit.ly/2je6cQ > Blog: http://bruceblog.org/ > Twitter: http://twitter.com/brucesnyder
