Say I create a feature branch, this is what a day's work might look like.
839a882 Fix bad code formatting [James Kyle]
6583660 Updated plugin paths for publish env [James Kyle]
847b8f3 First stab at a mobile friendly style. [James Kyle]
a70d3f7 Added new articles, updated a couple. [James Kyle]
b743ec3 format changes on article [James Kyle]
68231e7 Some udpates, added an article [James Kyle]
2a92c5e Added plugins to publish conf. [James Kyle]
6dec1e1 Added share_post plugin support. [James Kyle]
070bbd0 Added pep8, pylint, and nose w/ xunit article [James Kyle]
eb8dbcc Corrected spelling mistake [James Kyle]
0b89761 Minor article update [James Kyle]
677f635 Added TLS Docker Remote API article [James Kyle]
d8e94fd Fixed more bad code formatting in nose [James Kyle]
f06dc2d Syntax error for code in nose. [James Kyle]
606ac2b Removed stupid refactor for testing code. [James Kyle]
This might be a very short one. If the work goes on for a couple of days, could be dozens of commits like this.
In the end, it'd be a veritable puzzle what I was trying to send upstream. Also, the merger has to troll through multiple commits and history. It's plain annoying.
So you rebase and send them something like this:
947d3e7 Implemented mobile friendly style. [James Kyle]
And if they want more, they can see the full log with a bullet list:
947d3e7 Implemented mobile friendly style.
- Added plugins x, y,
- Implemented nose tests to account for new feature
Rebasing is about taking a collection of discombobulated stream of thought work flow and condensing it into a single commit with an accurate, descriptive log entry.
Makes everyone's life easier.
edit
It's also very nice to take out frustration generated commits like "fuck fuck fuck fuck fuck!!!" before committing upstream to your company's public repository. ;)
I agree with mkeash's comment. Isn't this also the whole point of the staging area? "Stage multiple fixes into a single coherent commit," is the underlying model. Instead, in the above example there are many granular commits, with rebasing used to then clump them into a logical grouping.
This would indicate to me that you are committing too often or not using the staging area properly.
Committing often allows you to remember the small changes you made throughout the feature. If you let a file sit in the staging area for hours, days, weeks, you will most likely have a hard time remembering why you made all the changes.
Is there a way to do this with the staging area? o.O
Merge commits, particularly those that merged master multiple times effectively destroy history (by preserving it). For that matter, many projects maintain all commits to master should work! Unless you advocate only committing entirely working states (unlikely for large features), you'd have to rebase.
Can you explain what you mean by effectively destroying history by preserving it? That doesn't make any sense to me. And I also don't understand the link between merge commits and a failure to ensure that all commits to master should work. If you make changes in a branch, get everything up and running there, then merge to master, does that not ensure that everything on master works?
I agree with getting rid of noise and adding signal (see my sibling post) but banging a whole feature into a single commit is going way too far IMHO. "Added share_post plugin support" sounds like something that should be in a permanent commit to me. "format changes on article" probably not so much (assuming you created that article in the same feature branch).
I share an svn codebase with a few dozen developers, and while we don't have rebase, the history remains readable. There's a few guidelines that enable this: (1) all work must happen in the context of a jira issue or story, (2) the commit message starts with the jira issue id and its description, and only after that any stream of consciousness remarks, and (3) syntax errors will cause the commit to bounce and failing tests from the CI build will get you frowned upon. The history will usually reveal a few commits for a feature, spread half a day or a day apart. We rely on the local history feature of phpstorm to be able to backtrack to an earlier version (that and good old copy-pasting of the working copy before you start an experiment)
Is there a handy macro/script type thing that simplifies squashing a release branch and using the commit messages as bullet points (with the ability to edit out crap)?
In the end, it'd be a veritable puzzle what I was trying to send upstream. Also, the merger has to troll through multiple commits and history. It's plain annoying.
So you rebase and send them something like this:
And if they want more, they can see the full log with a bullet list: Rebasing is about taking a collection of discombobulated stream of thought work flow and condensing it into a single commit with an accurate, descriptive log entry.Makes everyone's life easier.
edit
It's also very nice to take out frustration generated commits like "fuck fuck fuck fuck fuck!!!" before committing upstream to your company's public repository. ;)