With "Please, oh please use git pull --rebase" I didn't mean to preach but to convince some of the people I code with to maintain at least basics of a clean git history, thus the 'please' in title. I wrote it some time ago and only yesterday I was surprised at the sudden popularity of that post :)
No, it does not. CI never builds those broken commits because they never go outside of authors personal computer. Commit often, push when it's done and only push commits that work.
Why would someone take one of the most important features of git (local history) and throw most of it away by abandoning ability to edit it?
If you pushed a broken commit push another fixing it, just like in merge-based workflow.
Having dates switched is not important, having four different branches on said Tuesday gives you a lot headache searching who introduced a bug. And git bisect won't help you. ;)
Exactly. Keep remote history clean, keep local history dirty. Commit broken code, commit experimental features, do whatever it takes for you to write your code.
Squash, rebase interactively, rearrange, amend, merge, --no-ff before you push so other can read only a good, maintainable code served in meaningful and ordered commits.
Also rebase onto origin master often so you won't get lost in milion pages long diffs and conflicts.
Yes, --no-ff merge after a rebase gives a clear indication that's a feature merged from a feature branch. It's easy to cherry-pick it to another branch (for example for a backport to an old version), easy to bisect this branch or remove the entire feature.
Yes, I did. If you're using continuous delivery or at least continuous integration system you can revert the build, bisect easily the history in a matter of minutes (for a use case missed by all the tests) and have a feature release saved. :)
Yes, but I used the title for people to actually start using rebase. Caring about history beyond avoiding useless merges and broken commits is another step I'd like at least my co-workers to take ;)
From my experience it is common for a group of developers co-working on some feature to share codebase very often.
Also in an actively developed project there are likely to be many new commits every single day, and you want to be up to date with remote codebase to ease the pain of merging your features into it.
If you rebase your work onto master often you'll greatly speed up the release of your feature when it is ready. You'll also avoid late surprises when something you depend on elsewhere in codebase change.
You can also notify your co-workers about inconsistencies between developed features and detect incompatibilities early.
It also works in macro scale - projects released often with small changes shorten the feedback loop and can be adjust properly for their requirements.
I do prefer feature branches (especially git flow: https://coderwall.com/p/d1pkgg ), but for day to day 'agile' development in a small team we don't use them often. YMMV.
But for pulling changes working on local branch git pull --rebase (or autorebased branch) is many times more readable (and avoid ugly merge bubbles in history).
Branch when you need branches, merge when you mean merging, rebase when you're just updating your codebase from shared repository. Keep your local (not pushed/pull-requested yet) branches dirty (commit often!), rebase them into a clean, obvious history before you share them.
Remember - commit history is for other people to READ.