The git fetch command copies commit, files, and references from a remote repository to your local repository. Fetching is what you do when you want to know what other people have been up to. It works similarly to the svn update in that it shows you how the central history has advanced without forcing you to merge the changes into your repository. Git separates fetched content from existing local content, so your local development effort is unaffected. The git checkout command must be used to check out the fetched content. As a result, fetching is a secure way to evaluate contributions before committing them to your local repository.
Git pull and git fetch are commands that can be used to obtain content from a remote repository. The git fetch command is the safer version of the two instructions. It will download the remote content but not update the working state of your local repo, preserving your existing work. The more aggressive option is git pull, which will download the remote content for the active local branch and then run git merge to create a merge commit for the new remote content. If you have any pending charges, this will result in conflicts, which will trigger the merge conflict resolution flow.
How does a git fetch work?
Let’s look at how Git organizes and stores commit to better understand how git fetch works. Git maintains all local and remote commits in the repository’s./.git/objects directory behind the scenes. Through the usage of branch refs, Git distinguishes between remote and local branch commits. Local branch refs are kept in the./.git/refs/heads/ directory. A list of local branch refs can be found by running the git branch command. With some demo branch names, here’s an example of git branch output.
git branch main feature1 debug2
Examining the contents of the /.git/refs/heads/ directory would reveal similar output.
ls ./.git/refs/heads/ main feature1 debug2
Remote branches are similar to local branches, but they map to commits in another repository. To avoid confusion with local branches, remote branches are preceded by the distance to which they belong. Git has refs for remote branches, just like it does for local branches. The./.git/refs/remotes/ directory contains remote branch refs. The following code snippet illustrates the branches that may appear after obtaining a remote repo with the handy name remote-repo:
git branch -r # origin/main # origin/feature1 # origin/debug2 # remote-repo/main # remote-repo/other-feature
This output shows the local branches we looked at before, but now they’re prefixed with origin/. Additionally, remote branches are now prefixed with remote-repo. You can check out a remote branch exactly like a local branch, but you’ll be in a detached HEAD state as a result (just like checking out an old commit). They can be thought of as read-only branches. Simply add the -r argument to the git branch command to see your remote branches.
Fetching changes from a remote repository
To get fresh work done by other individuals, use git fetch. When you fetch from a repository, all of the new remote-tracking branches and tags are grabbed without being merged into your own branches.
You can get all the new information by running git fetch remote name in the terminal if you already have a local repository with a remote URL set up for the desired project:
git fetch remotename # Fetches updates made to a remote repository
Otherwise, you can always add a new remote and then fetch.