On 10 November 2013 15:11, Robert Newson <[email protected]> wrote: > "I would agree with Jan/Dave that squashing branches to one commit is > undesirable. On the other hand, I would also say that keeping all the > commits on the feature branch as you created them is probably bad > form." > > Absolutely, neither of those ideas are sensible. What we do at > Cloudant is, at the completion of a code review, to transform the > commits on a branch into logical distinct commits before we merge (and > most pull requests start as multiple commits). That is often a single > commit (the original one squashed with several follow-up tidying or > bugfixing commits) but is sometimes several. Each should be > self-contained and readable (though they do not have to be standalone) > and the set of them should achieve the goal. > > It is as wrong to obscure the nature of your change by collapsing too > far as it is wrong to preserve, forever, all "oops, whitespace" and > "oops, typo" commits you added to your feature branch while hacking. > > B.
>From your feedback and my questions I conclude that we should make things clear here and write it down. I would like to do that (I am writing a lot of notes recently ;-) ). My point of view now is probably the same Robert has. And this results basically in the way Dirkjan described the process with: > - create feature branch from master > - work on feature branch > - rebase feature branch onto current master > - clean up feature branch commits > - merge feature branch into master > > Where "clean up" means that I end up with commits like this: > > - clean up whitespace in code area > - minimally complete refactoring #1 > - minimally complete refactoring #2 > - minimally complete refactoring #3 > - actual feature/fix, part #1 > - actual feature/fix, part #2 I am happy with that because it is basically the same I do with the difference, that the described process fits better for big feature branches where logical units are needed for understanding. The only thing I would change is the order. I would first cleanup the feature branch commits and then rebase the feature branch onto the current master resulting in: > - create feature branch from master > - work on feature branch > - clean up feature branch commits > - rebase feature branch onto current master > - merge feature branch into master Doesn't make that more sense? Or do I oversee something? Cheers Andy > > On 10 November 2013 13:45, Dirkjan Ochtman <[email protected]> wrote: > > On Sun, Nov 10, 2013 at 2:07 PM, Andy Wenk <[email protected]> wrote: > >> - create feature branch from master > >> - work on feature branch > >> - rebase the work on the feature branch into one commit > >> - rebase master into feature branch > >> - checkout master > >> - merge feature branch into master > >> > >> I know there are many ways to do this task and believe me I had many > many > >> discussions on that. What I want to know, is how it is done here and > then I > >> will follow the way. > > > > I think we have an open issue to decide on our git workflow, that we > > keep putting off for some stupid reason. So if you want to help us > > pull through that discussion and get to something well-defined, that > > would be great. ;) > > > >> I discussed Jan's commit 659699de with Dave and understood, that all > >> commits from the feature branch are still there and on top is a info > merge > >> commit with all messages. So that's the way it should be? > > > > I would agree with Jan/Dave that squashing branches to one commit is > > undesirable. On the other hand, I would also say that keeping all the > > commits on the feature branch as you created them is probably bad > > form. My ideal feature branch is something like this: > > > > - create feature branch from master > > - work on feature branch > > - rebase feature branch onto current master > > - clean up feature branch commits > > - merge feature branch into master > > > > Where "clean up" means that I end up with commits like this: > > > > - clean up whitespace in code area > > - minimally complete refactoring #1 > > - minimally complete refactoring #2 > > - minimally complete refactoring #3 > > - actual feature/fix, part #1 > > - actual feature/fix, part #2 > > > > Where each refactoring is a chunk of change that is coherent by > > itself, helps me towards making the feature or fix, and doesn't break > > the build by itself. This is often easy, but can be hard or even (in > > edge cases) impossible. > > > > The other thing we'd need to discuss is how to deal with maintaining > > both master and maintenance branches. That issue has mostly been > > solves by the fact that we don't really do bugfix-only releases > > anymore in the current release schedule, but in the event of, say, a > > security release, it would have my preference to land security/import > > bug fixes on the oldest maintenance branch first, then merge it > > forward into newer maintenance branches/master (e.g. prefer merging -- > > but only forward -- over cherry-picking). > > > > Cheers, > > > > Dirkjan > -- Andy Wenk Hamburg - Germany RockIt! http://www.couchdb-buch.de http://www.pg-praxisbuch.de GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
