To ensure 2, IMO it’s better to enforce that every commit start with a jira ticket number. Then at least we can run an eyeball groupby on the commit history.
> On Sep 23, 2015, at 11:54 PM, Chris Hillery <[email protected]> wrote: > > On Wed, Sep 23, 2015 at 6:29 PM, Ted Dunning <[email protected] > <mailto:[email protected]>> wrote: > > Cherry picking (in my experience) works very much as desired. The fact that a > commit exists on two branches doesn't seem to cause any trouble at all at > merge time. > > That's good to hear. I have definitely had bad experiences when dealing with > cherry-picked commits, but I have not been able to pin down a specific case > where they don't do what you might hope. I'm not sure how the git magic > works, but it would certainly be compelling if it did work. > > Rebasing interactively is another case. I routinely use this to make my > local history more sensible. Within reason, it allows me to squash and > re-order my own commits so that there appears to be more order in the > historical record than was in my head at the time I did the work. > > Yes, this is a good strategy that we would definitely want to encourage if we > were to stop doing the full-squash at commit time. The golden rules IMHO are: > > 1. Don't rewrite history (which includes squashing or amending commits and > force pushes) on a branch that has been shared to anyone else. > > 2. Ensure that the commits which are ultimately pushed to master are > sensible, self-contained, well-documented, etc. > > There's a small amount of tension between those two rules, but it can be > handled. > > Ceej > aka Chris Hillery Best, Jianfeng Jia PhD Candidate of Computer Science University of California, Irvine
