Understanding the Git Workflow

Personally I find the "git isn't enough like SVN" argument to be basically the "I stick with Windows because Linux is scary" or "MacOS X sucks because I tried it once and none of my Windows shortcut keys worked."

It basically comes down to:

1) You probably shouldn't just dive into git if you don't have someone that does know it to help you out (or unless you're willing to go seek out help from mailing lists, irc, etc).

2) You shouldn't assume that just because RCS/CVS/SVN are the only VCS's that you've ever used that it means that's what all VCS's should look/work like.

I'm wondering how people address one of the scenarios raised in the post, specifically this:

"It’s safest to keep private branches local. If you do need to push one, maybe to synchronize your work and home computers, tell your teammates that the branch you pushed is private so they don’t base work off of it.

You should never merge a private branch directly into a public branch with a vanilla merge. First, clean up your branch with tools like reset, rebase, squash merges, and commit amending."

I'm wonder how people address cleaning a private branch that has been pushed (when your goal is to get its changes into master cleanly). Rebasing the private branch is pretty much out of the picture since it has been pushed (unless you don't care about pushing it again). I can see some ways of doing this:

1) You could do a diff patch and apply it master, then commit.

2) You could checkout your private feature branch, do a git reset to master in such a way that your index is still from the private, then commit it. Ex:

currently on private branch git reset --soft master

Now all the changes from the private branch are changes to be committed on master. This is easy, but it puts everything in one commit.

If you wanted to do a few commits for different, but stable points, but you already pushed the private branch and can't rebase it, you could instead do "git reset --soft" on successive points in the private branch commit chain, committing to master as you go.

If you wanted to reorder commits from the private branch, I guess you could rebase the private branch (which means you can't push again since you pushed it already), then do the tactic from the last paragraph, then ditch the private branch cause it's no longer pushable.

Does anyone have better ways of putting changes to master for private branches that have already been pushed?

> But you will get it in the form that I would like you to have it, not as it happened.

And that's actually a very large part of why I don't use something that makes rebase easy. Because, fundamentally, I do not care how you "want" me to get it. I want to get it how it was put into the repository to begin with. I want to get it how it was committed--because how it was done matters to me, as a developer and as a person. This is an entirely emotional position and I don't care: show me how it was done. It matters to me, and given my personal axioms there is a decent argument, in my mind, that doing otherwise is disrespecting people who might want to see how you "put it all together."

You're certainly welcome to disagree. But because I use Hg for my projects and for any project I contribute to, and because my usual co-workers aren't going to go through the hassle of enabling Hg's rebase extension and using it just for the hell of it, I generally get what I want in the areas I care about. =)

You will probably enjoy 'checkout -p' and 'reset -p' as well (revert and unstage changes hunk-by-hunk)

How are they useful? Why would anyone care about how you developed a single bugfix or a feature?

In your model, often the commits are not even sequential in the log because you might find a mistake only after committing several other changes. I can't see how not rebasing makes commit history better in any way at all. I would like to hear your reasoning.

The way I see it, instead of a series of commits that implement something, you could have a single patch (commit) that implements something, making it much easier to

0) find all the code that implements a certain feature, because it's a self-contained commit,

1) find bugs via bisection,

2) port to other versions via cherry-picking and

3) read the changelog and figure out what the hell is actually happening because there are no trash commits around obscuring things.

EDIT:

Just to clarify, I do not think that this is a matter of opinion or preference. That would imply that both approaches are equally valid.

I consider rebasing a tool that enables a vastly superior workflow. I have given a few reasons why I think it is superior and I am interested in counterarguments or at least reasoning as to why not making perfect commits (to the best of your ability) is preferable or even acceptable at all.