DEV Community

loading...

git - how to avoid weird situations while pulling from remote repository

Marcin Wosinek
Javascript developer
Updated on ・2 min read

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 to git 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 just git 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:

Discussion (0)