Why do we bother doing git fetch if we know that we will have to merge whatever changes in the remote repo eventually?
I understand that git fetch downloads new data from the remote repo and unlike git pull, it does not integrates with data in our workspace. We can in return check for differences in data/commits before running git merge.
From simply googling, all I can see is that people saying git fetch git merge is a safer practice than git pull. I kind of get it, you do not want to do a git pull and found out that you merged something that ruined data in your workspace. The thing is if that happens, I can choose to do a rollback.
Is there a bigger purpose or reason to use git fetch besides checking for differences between your local and remote repo?
I know this might sound like a simple or even stupid question to most people and I do not why it bothers me so much. I just want someone to convince me more about doing git fetch. Also, I am not writing this to rant or complain, I really just want to learn all the safe practices of git.
CodePudding user response：
Besides checking differences and doing merge/rebase, I also
- cherry-pick commits
- inspect the sizes of the blob objects
- create patches
- create git bundles or zip/tar packages
- checkout a commit
- retrieve data like bug tickets from commit messages
- count additions and deletions
- search commits for a string and find out who contributes to the string
and etc.
Basically I read data from the repository database. To read the latest data, I need git fetch first.
CodePudding user response：
Why do we bother doing git fetch if we know that we will have to merge whatever changes in the remote repo eventually?
Bad premise. You don't have to merge everything, you might not be the one having to merge anything. If you're just installing, you fetch and maybe checkout, not necessarily first or even ever to an existing work tree. If you're carrying a patch, you're going to fetch and rebase. If you're bughunting you fetch and bisect. Like that.
Also: don't believe everything you read. I'm kind of on board with the warnings against git pull, not because of anything intrinsic about it, it's all I ever use in ... by count it's in most repos I use regularly, but instead as a warning to give to people who don't already know what they're doing. Learn what it's doing, learn what its options and configuration knobs can do for you. Don't think you can cruise on mental autopilot before you learn to drive, Git's just ridiculously simple underneath but the complexity of the work makes that hard to see.
CodePudding user response：
I use git fetch all the time so that I can run a git log --graph and view the changes before doing a merge. Also, sometimes you want to do a rebase, not a merge. You can do simple rebases by adding flags to git pull, but again, I often want to look at the graph first to make sure I get the rebase right.
CodePudding user response：
I cannot tell you how many of my teammates call me puzzled than their pull request to main includes 20 commits instead of the expected 3 commits (for example) from their feature branch.
They need to fetch, and then rebase their feature branch on top of the updated remote tracking branch origin/main, before force pushing their branch.
That updates the pull request in progress, which now displays only the 3 commits from their branch.