

How I learned to love rebase - roguelynn
http://www.pyladies.com/blog/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?

~~~
jarrighi
It is good to be alerted that the font isn't rendering properly on Windows
Chrome, though. I think most of the PyLadies who use Chrome are on Mac or
Linux, and the current design of the site is relatively new. Now we know we
need to fix this.

~~~
threedaymonk
There probably ought to be some general principle of web design here: don't
get fancy with stuff you can't support. If you don't have a wide range of
devices for browser testing, that's OK: just stick to the standard fonts that
work everywhere. If you are going to get fancy, do it right, and test
exhaustively.

I know everyone opts for fancy, though!

------
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.

~~~
enoch_r
I hadn't realized--thanks for the tip!

------
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>

~~~
snprbob86
This is where smaller code projects with clearer dependencies come in to play.
You can designate maintainers, integrators, reviewers, etc on a per-
project/per-boundary basis. This means that failure to understand rebase has
severely localized effects. As a bonus, you'll get better factored code backed
by developers with an enhanced sense of ownership.

~~~
alinajaf
Or you know, you could just spend a few hours learning about how a tool
_you're probably going to be using for over a decade_ works.

------
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.

------
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.

~~~
antris
Even better is avoiding shared branches and just rebasing locally, merging to
master whenever a task is complete.

~~~
threedaymonk
I frequently push work-in-progress branches as insurance. If my SSD dies, or I
get mugged on the way home, I'll still have the code tomorrow.

~~~
antris
There's two possible answers:

1\. Your are not merging to master often enough. If you split your tasks and
use environment flagging effectively, there's no reason why you wouldn't want
to merge to master on a daily basis.

2\. If you absolutely need to diverge from master so much that you have many
days of work sitting on your hard drive, you should be pushing to a _non-
shared_ repository in that case, or use other form of backup.

~~~
threedaymonk
Generally, I'm merging to master frequently (several times an hour). Things
like upgrading Rails can be multi-day odysseys, however (even though there's
sometimes an opportunity to make compatibility changes in master).

However, I don't see WIP branches as a problem, and certainly not one that
justifies setting up additional repositories or backup systems just to avoid.
If I'm working for someone else, it's not my place to set up shadow
repositories all over the place, either.

------
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.

