8 Matching Annotations
  1. Feb 2021
    1. Rebasing For feature/topic branches, you should always use the --rebase flag to git pull, or if you are usually handling many temporary "to be in a github pull request" branches, run the following to automate this: git config branch.autosetuprebase local

      That's what I keep telling people. Glad to see I'm not the only one...

  2. May 2020
    1. What I think we're lacking is proper tooling, or at least the knowledge of it. I don't know what most people use to write Git commits, but concepts like interactive staging, rebasing, squashing, and fixup commits are very daunting with Git on the CLI, unless you know really well what you're doing. We should do a better job at learning people how to use tools like Git Tower (to give just one example) to rewrite Git history, and to produce nice Git commits.
  3. Apr 2020
  4. Jan 2020
  5. Dec 2019
  6. Nov 2019
    1. But in general the guideline is: code should be clean, history should be realistic.
    2. If you push to a public branch you shouldn't rebase it since that makes it hard to follow what you're improving, what the test results were, and it breaks cherrypicking
  7. Jan 2014
    1. Rule of thumb: When pulling changes from origin/develop onto your local develop use rebase. When finishing a feature branch merge the changes back to develop.