If there are different changes on both the remote and the local branch, instead of just pulling the master by git pull
, I rather would do:
git pull --rebase
I even have it in my default config so that it will always will do a rebase if required on git pull
:
git config --global pull.rebase true
A rebase avoids a merge commit and keeps your changes on top of the current remote branch.
Yet you still have to resolve any occurring merge conflicts when different people are working on the same branch, which is a bad practice especially because it leads to conflicts.
(Also be aware that in the scope of a rebase, the meaning of theirs
and ours
is switched.)
In cases with minor changes, yours are just applied on the top.
You are changing the history, yet only your local one, not the remote's.
You won't need to git push --force
. You just git push
it as you are used to it.
In general, you should be working on feature branches and merge those back to the master branch.
When working on feature branches one can also keep the feature branch close to the master
by:
git checkout feature-branch
git fetch && git rebase origin/master
Yet here one would need to git push --force
the feature-branch, so one should be careful not to use this strategy if more than one person is working on the same feature-branch.
If one wants to use rebase and push forcing, consider using git push --force-with-lease
over git push --force
as it prevents accidentally deleting other's commits on the remote.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…