The default pull behaviour is to perform a merge which can also then create a merge commit, and thus can result in changes being made to the commit history. Whilst this is the original default behaviour of git it is often argued not to be the optional approach.
git pull => git fetch; git merge
A rebase is often prefered whan your local changes are not so significant as to require a separate branch off of whatever branch is currently active (e.g. main or dev). A rebase can be used to reconcile a divergent branch, rather than using a merge, to commit over the remote branch and so as to maintain a single branch both locally and remotely. This avoids the sometime confusion of createing minor branches of branches, and works nicely in team development.
git pull --rebase => git fetch; git rebase
There are diverse opinions as to whether to do a merge or a
rebase. A rebase is more like the
update of earlier version control systems (like Subversion
and CVS). It reduces the number of minor branches being merged and so
leaves merging as an operation on major branches of activity.
git config --global pull.rebase true
The default is:
git config --global pull.rebase false
Some recommend the dafault to simply be an attempt at a fast forward over the upstream commits and to fail if that is not possible.
git config --global pull.ff only
Further explanations are available from:
Your donation will support ongoing availability and give you access to the PDF version of this book. Desktop Survival Guides include Data Science, GNU/Linux, and MLHub. Books available on Amazon include Data Mining with Rattle and Essentials of Data Science. Popular open source software includes rattle, wajig, and mlhub. Hosted by Togaware, a pioneer of free and open source software since 1984. Copyright © 1995-2022 Graham.Williams@togaware.com Creative Commons Attribution-ShareAlike 4.0