5

For f***s sake, use fetch and merge, /not/ pull.

Comments
  • 5
    Why?
  • 1
    Just commenting because I'm curious as well.
  • 0
    @sm1th @BellAppLab

    There are tons of reasons, merge conflicts, screwing up the history, not seeing what has changed etc. More elaborate explanation here: http://longair.net/blog/2009/... and here

    if you don't care about your changes locally, use "git reset --hard origin/master"
    or whatever remote/branch you use
  • 2
    Don't use merge.

    Imagine you have 3 branches (a, b & c) all being worked on concurrently. When it comes time to deploy the 3 branches get merged together and your history ends up looking like:

    aacbabbcacbac

    But oh no! A bug has been found and you need to roll back the "c" branch changes. Because the history is entwined you need to roll back to after commit 2, erasing all the "b" branch changes and most of those from "a".

    But if you rebase then your history looks like

    aaaaabbbbcccc

    So rolling back your "c" branch becomes much easier as your history is not all jumbled.

    Ideally you'd squash and then rebase so your history looks like

    abc
Your Job Suck?
Get a Better Job
Add Comment