I use rebases in my workflow, and I never run git pull
. git pull
is git fetch
+ git rebase
; and it makes more sense to run those two commands separately. After fetch you can see if there were a lot of changes, and it's more natural to do git rebase --abort
and go back to the pre-rebase state
Instead, I do as follows:
- I use my alias
git tree
, which translates togit log --oneline --graph --decorate --all
. There I can see what kind of changes I'm about to rebase on - If it goes very bad, I rebase not on
origin/master
but few commits before. In this way, I can fix conflicts more step by step - if you have to solve conflicts, it makes sense to squash your commits on a branch to an almost final state. If you have 5 commits, it can happen that the same conflict you will have to fix 5 times. If you squash it into 1, same work; but you don't have to repeat it
- as a last resort, you can use git merge
origin/master
. Git often manages merges ok, and if you care about tree shape (no merge commits, and personally I avoid them) you can justgit checkout <the-result-of-merge>; git reset origin/master
and create a new commit with just with the file changes
I general, if you work with a team that uses a workflow that uses rebases, you should learn a bit more about git internals & branching. Good materials on that are:
- visual, game-like explanation - https://learngitbranching.js.org/
- the chapter on git internals in Pro Git book: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
Top comments (0)