How I learned to love rebase

[GilbertErik]

Sorry to nag, but I haven't yet brought myself to make it past the first paragraph. Maybe it looks elegant or classy on someone else's screen, but I had to go re-enable Evernote Clearly just to be able to read it. Am I the only one?

[sophacles]

Sorry to rant, but I haven't yet brought myself to understand this position. Maybe it makes sense to designers or snobs but I have go calm down for a while just be able to reply. Am I the only person who thinks that ignoring good content to complain about formatting choices is vacuous at best?

[krelian]

Chrome's Windows font rendering rears it's ugly head again. While the fault here is entirely with Chrome I still don't understand how so many people (and even some high profile projects/organizations) choose to use those web fonts which are unreadable in Chrome.

[Jenk]

http://i.imgur.com/XcqHLyE.png

Was about to post the same complaint :)

[DoggettCK]

The content of the article was great, but I had to remove the font-family style from the body tag with Firebug due to the way Firefox was handling aliasing on the font.

Aside from that minor nitpick, I learned something new and valuable, so it's worth reading if you don't already know about git rebase.

[throwawayG9]

I only use Firefox and Liferea (when I find a good RSS to add), so I had to close this article because it was unreadable (I don't have other software to "fix" blogs, like the other commenters).

I don't see anything wrong with complaining about this. It's feedback for the author. Would you not complain if someone posted an invisible article, to which you need to apply some trick to make it appear? Would you not want to know why potential readers/subscribers are bouncing?

Another thing I usually hate in these blogs: small fonts. But at least I can just do ctrl+, so I never complain about that. But still hate it.

[GilbertErik]

https://docs.google.com/file/d/0B_sHgQoVOruvTmJjdHlWUTk4dGM/...

Ya know what. It looks fine in Firefox, but that font looks like garbage rendered in Chrome. I don't know if it's the font-family or the font-size, but something's making me want to scratch my eyes out or make me want to kill my screen with fire.

It's probably an unfair generalization to assume that all female Python developers don't use Chrome.

[ineedtosleep]

Chrome and thin fonts don't mix well. That said, I still don't understand why people use thin fonts for body copy. It reduces readability so much (even on FF where the rendering is fine).

[lloeki]

Here the glyphs are rendered fine, but the kerning is really bad.

[mimiflynn]

Same here, can barely read it so I sent it to Pocket to read later.

[nightpool]

Not just Chrome: It's pretty terrible on older Firefoxes too. Firefox 16 here, and while it's not as bad as Chrome, its not very great either.

[lucian1900]

Indeed. Completely unreadable on both Chrome and Firefox, on Ubuntu. Had to use ireader.

[corresation]

Chrome 25 on Windows here and the same problem -- the font has extraordinarily poor hinting (or Chrome is malfunctioning), leading to critical elements of the text being discarded at that size.

[enoch_r]

    git reflog

Before I learned that command, I'd seen git as a backup tool with some scary options for manipulating history that I didn't want to touch for fear they'd blow up on me. After learning about git reflog, I finally understood that this was like being scared of pressing backspace on the keyboard. Yes, it can erase commits you really really needed--but all you need to do to get them back is:

    git reflog

(to find the commit hash you want to get back to), then

    git reset --hard ${old commit hash}

to get to it.

Now, without any reason to fear experimentation, I can use git like it's meant to be used. I can edit my local history without fear, then push it to the remote repo.

(One reason to still stay slightly cautious--some git commands run garbage collection automatically, and garbage collection will destroy any disconnected commits. Running "git config --global gc.auto 0" will fix this--I prefer to manage the garbage collection myself anyway, personally.)

[tmhedberg]

Automatic garbage collection won't destroy any unreachable objects less than 2 weeks old. This is the default time window; you can override it via the `gc.pruneexpire` config option.

Given this grace period, disabling AGC altogether is probably overkill, but there is nothing wrong with that, if it's really what you prefer.

[snprbob86]

I don't understand why anyone considers rebase to be scary. It's really quite simple:

Primarily, rebase is a tool for modifying patches. Patches are as much about communication as they are about modifying code.

You edit your emails before you send them, so why not your patches? You proof read your edited emails before you send them, so why wouldn't you test rebased patches?

There are plenty of reasons to use rebase and as many advanced use cases as there are git enthusiasts. However, it's not "rewriting history" because you've always got reflog and cryptographically secure version hashes. It's not any more scary to rebase than it is to "undo" and subsequently "redo" in your text editor. The only caveat is that you shouldn't rebase code on branches that you've shared publicly for the exact same reasons that you shouldn't publish version 3.2.1 and then re-publish it with a bug fix without calling it version 3.2.2.

[alinajaf]

> The only caveat is that you shouldn't rebase code on branches that you've shared publicly for the exact same reasons that you shouldn't publish version 3.2.1 and then re-publish it with a bug fix without calling it version 3.2.2.

<rant>

When one is on a development team that doesn't really understand how rebase (or git for that matter) works and are suitably trigger happy with `git pull --rebase`, this itty bitty caveat makes origin a minefield when working with branches.

In that situation, one would honestly wish one were using svn instead. Then at least one could use git-svn locally and treat trunk as origin/master, which is what ones team really wants.

</rant>

[aaronblohowiak]

>it's not "rewriting history" because you've always got reflog and cryptographically secure version hashes

To avoid having to go to the reflog, you can follow this simple procedure: branch before rebase. Then when you're comfortable, just change the branch to point at the new ref. This is the rename(2) approach to rebasing :D

[pkteison]

Can somebody try to explain what considerations go into picking between merge and rebase, or when rebase is a better option? The example here "you've branched that file and made some changes. Meanwhile, someone else has modified that same file on the master branch..." says 'merge' to me, and I'm not sure what consideration goes into the decision that rebase is the right tool instead. I've tried to google a bit, and read some posts on it on stack overflow, and it still just doesn't click for me.

[newishuser]

You rebase to clean up your own, non-shared, local commit history. That is it. As soon as your commits are shared you can no longer rebase them or feel the wrath. If you don't care about cleaning up your local history, before you share it, then don't rebase.

A merge creates a new commit that doesn't effect history so it's always safe to merge.

[base698]

My simple rule is if I'm on my feature branch that no one else is working off of, then I rebase. If I am working on a shared feature branch I merge.

Another good use case for plain merge is to play Dr. Frankenstein, combining many feature branches not yet in the main line to give an impromptu demo or see how the automated tests are shaking out.

[jlatt]

I do not understand why these metaphorical articles persist. They do not help anyone understand the procedure, which is simple:

    - Walk the commit tree backwards to the specified rebase point, writing each commit as a temporary diff file.
    - Set the current working space to the rebase target commit/hash/tag like `git reset --hard $commit`.
    - Apply each diff file in forwards order (that's the reverse of the  way diffs were generated in the first step).

Rebase is just a good shorthand for moving sequences of commits and (potentially interactively) resolving conflicts along the way.

[neebz]

Unfortunately rebase doesn't fit well with our team workflow (team is geographically distributed). we use branches and commits to check which user is on which task. everyone pushes code at the end of the day even if it's incomplete. Pushing code prevents rebase usage.

Rebase is really good especially when you are contributing in open source repositories but our experience has been limited in our private repositories.

[threedaymonk]

In your scenario, it sounds like you'd be better served by pushing the incomplete work to temporary branches. At least, if I were working with you, I'd rather have working code in master than a bunch of "git commit -am Hometime" dumps.

[shuzchen]

I personally don't subscribe to the "you should never rebase commits that you have pushed to a public repository" tenant. For me it's more "you should never rebase commits that you have pushed to a repository other people use".

That is, your personal WIP branches are fine, so long as you're the only person that pushes/pulls from it. These WIP branches should be labeled in such a way that the team knows at a glance which are WIP.

This also means your team members need to get used to doing a `git push -f`, as well as making sure their push.default is configured to "current".

[antris]

> we use branches and commits to check which user is on which task. everyone pushes code at the end of the day even if it's incomplete

I think your fundamental problem is trying to use git for task management. There's better software for doing that, e.g. Trello.

[michaelmior]

I occasionally do the same thing, but as long as I know no one else is working off the code I push, I still feel comfortable rebasing after pushing.

[j_s]

  > It's possible to be careful about rebasing code, say by duplicating the master 
  > branch and rebasing your code on that new version to see if you accidentally 
  > destroy the world before trying to rebase within the actual master.

Is it possible to ask 'What would you do if I rebased' without a test branch?

[threedaymonk]

You can always do "git rebase --abort" if you're stuck in the middle of a rebase, or, if you've rebased and don't like it, "git reflog" to find the previous state followed by "git reset --hard <hash>" to get back to where you were.

[jmount]

So there is no possibility that if it is rendering poorly in a particular browser it may be the browser's fault instead of the website? Good article, please shut up about the fonts.

[speg]

I like to `merge --squash` when I bring it back into master to keep things real tidy.