>If you're consistently writing buggy code and rebasing to fix it, then you're coding badly. Don't fix the symptom by rebasing endlessly, figure out your problem. And you do have a problem, because not only are you writing crap code, but you're committing it as well!
>Look closer at your diffs. Write more unit tests. Run them more often. Whatever, figure out what you need to do to avoid routinely making bad commits.
I disagree with this. Git is fast enough that you can commit early and often - more often than you can afford to run unit tests, even. I find it very useful to be able to commit each minor change of direction; half my commits don't even compile (I also believe in using strong type systems and the "compile error tells me what I need to change next" approach). If I need a "clean" history for review or similar (though honestly I don't see why you would - just review the differences between the branch head and branch base) I can always squash those commits thanks to git's nice history-rewriting features.
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.
Considering my project uses Jenkins and I commit on a sometimes minute basis (including code that won't build) I'd have to say committing broken code works just fine with Jenkins. Now if you're talking about pushing broken code to something like gerrit, that's another story, and that's just one of many reasons why the article is flat out wrong, because you have to rebase to squash commits into a single patch set before you can push them to something like gerrit, which then runs them by Jenkins.
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.
The only way they never go outside of the author's personal computer is if the author squashes (or discards!) them before pushing. Otherwise, they will go outside of the author's personal computer.
However, they will never be a head outside of the author's personal computer, because they are pushed along with later commits that fix the brokenness. CI only ever builds heads, so the existence of the broken commits doesn't matter.
Why would CI ever run a build of more than one commit sent in the same push? Isn't the push atomic? (Certainly it's worked that way for me in practice).
>Look closer at your diffs. Write more unit tests. Run them more often. Whatever, figure out what you need to do to avoid routinely making bad commits.
I disagree with this. Git is fast enough that you can commit early and often - more often than you can afford to run unit tests, even. I find it very useful to be able to commit each minor change of direction; half my commits don't even compile (I also believe in using strong type systems and the "compile error tells me what I need to change next" approach). If I need a "clean" history for review or similar (though honestly I don't see why you would - just review the differences between the branch head and branch base) I can always squash those commits thanks to git's nice history-rewriting features.