- --[no-]all
Fetch all remotes. This overrides the configuration variable
fetch.all
.- -a
- --append
Append ref names and object names of fetched refs to theexisting contents of
.git/FETCH_HEAD
. Without thisoption old data in.git/FETCH_HEAD
will be overwritten.- --atomic
Use an atomic transaction to update local refs. Either all refs areupdated, or on error, no refs are updated.
- --depth=<depth>
Limit fetching to the specified number of commits from the tip ofeach remote branch history. If fetching to a shallow repositorycreated by
git clone
with--depth=<depth>
option (seegit-clone[1]), deepen or shorten the history to the specifiednumber of commits. Tags for the deepened commits are not fetched.- --deepen=<depth>
Similar to --depth, except it specifies the number of commitsfrom the current shallow boundary instead of from the tip ofeach remote branch history.
- --shallow-since=<date>
Deepen or shorten the history of a shallow repository toinclude all reachable commits after <date>.
- --shallow-exclude=<revision>
Deepen or shorten the history of a shallow repository toexclude commits reachable from a specified remote branch or tag.This option can be specified multiple times.
- --unshallow
If the source repository is complete, convert a shallowrepository to a complete one, removing all the limitationsimposed by shallow repositories.
If the source repository is shallow, fetch as much as possible so thatthe current repository has the same history as the source repository.
- --update-shallow
By default when fetching from a shallow repository,
git fetch
refuses refs that require updating.git/shallow. This option updates .git/shallow and accepts suchrefs.- --negotiation-tip=<commit|glob>
By default, Git will report, to the server, commits reachablefrom all local refs to find common commits in an attempt toreduce the size of the to-be-received packfile. If specified,Git will only report commits reachable from the given tips.This is useful to speed up fetches when the user knows whichlocal ref is likely to have commits in common with theupstream ref being fetched.
This option may be specified more than once; if so, Git will reportcommits reachable from any of the given commits.
The argument to this option may be a glob on ref names, a ref, or the (possiblyabbreviated) SHA-1 of a commit. Specifying a glob is equivalent to specifyingthis option multiple times, one for each matching ref name.
See also the
fetch.negotiationAlgorithm
andpush.negotiate
configuration variables documented in git-config[1], and the--negotiate-only
option below.- --negotiate-only
Do not fetch anything from the server, and instead print theancestors of the provided
--negotiation-tip=*
arguments,which we have in common with the server.This is incompatible with
--recurse-submodules=[yes|on-demand]
.Internally this is used to implement thepush.negotiate
option, seegit-config[1].- --dry-run
Show what would be done, without making any changes.
- --porcelain
Print the output to standard output in an easy-to-parse format forscripts. See section OUTPUT in git-fetch[1] for details.
This is incompatible with
--recurse-submodules=[yes|on-demand]
and takesprecedence over thefetch.output
config option.- -f
- --force
When git fetch is used with
<src>:<dst>
refspec, it mayrefuse to update the local branch as discussedin the<refspec>
part of the git-fetch[1]documentation.This option overrides that check.- -k
- --keep
Keep downloaded pack.
- --prefetch
Modify the configured refspec to place all refs into the
refs/prefetch/
namespace. See theprefetch
task ingit-maintenance[1].- -p
- --prune
Before fetching, remove any remote-tracking references that nolonger exist on the remote. Tags are not subject to pruningif they are fetched only because of the default tagauto-following or due to a --tags option. However, if tagsare fetched due to an explicit refspec (either on the commandline or in the remote configuration, for example if the remotewas cloned with the --mirror option), then they are alsosubject to pruning. Supplying
--prune-tags
is a shorthand forproviding the tag refspec.- --no-tags
By default, tags that point at objects that are downloadedfrom the remote repository are fetched and stored locally.This option disables this automatic tag following. The defaultbehavior for a remote may be specified with the remote.<name>.tagOptsetting. See git-config[1].
- --refmap=<refspec>
When fetching refs listed on the command line, use thespecified refspec (can be given more than once) to map therefs to remote-tracking branches, instead of the values of
remote.*.fetch
configuration variables for the remoterepository. Providing an empty<refspec>
to the--refmap
option causes Git to ignore the configuredrefspecs and rely entirely on the refspecs supplied ascommand-line arguments. See section on "Configured Remote-trackingBranches" for details.- -t
- --tags
Fetch all tags from the remote (i.e., fetch remote tags
refs/tags/*
into local tags with the same name), in additionto whatever else would otherwise be fetched. Using thisoption alone does not subject tags to pruning, even if --pruneis used (though tags may be pruned anyway if they are also thedestination of an explicit refspec; see--prune
).- -j
- --jobs=<n>
Number of parallel children to be used for all forms of fetching.
If the
--multiple
option was specified, the different remotes will be fetchedin parallel. If multiple submodules are fetched, they will be fetched inparallel. To control them independently, use the config settingsfetch.parallel
andsubmodule.fetchJobs
(see git-config[1]).Typically, parallel recursive and multi-remote fetches will be faster. Bydefault fetches are performed sequentially, not in parallel.
- --set-upstream
If the remote is fetched successfully, add upstream(tracking) reference, used by argument-lessgit-pull[1] and other commands. For more information,see
branch.<name>.merge
andbranch.<name>.remote
ingit-config[1].- --upload-pack <upload-pack>
When given, and the repository to fetch from is handledby git fetch-pack,
--exec=<upload-pack>
is passed tothe command to specify non-default path for the commandrun on the other end.- --progress
Progress status is reported on the standard error streamby default when it is attached to a terminal, unless -qis specified. This flag forces progress status even if thestandard error stream is not directed to a terminal.
- -o <option>
- --server-option=<option>
Transmit the given string to the server when communicating usingprotocol version 2. The given string must not contain a NUL or LFcharacter. The server’s handling of server options, includingunknown ones, is server-specific.When multiple
--server-option=<option>
are given, they are allsent to the other side in the order listed on the command line.- --show-forced-updates
By default, git checks if a branch is force-updated duringfetch. This can be disabled through fetch.showForcedUpdates, butthe --show-forced-updates option guarantees this check occurs.See git-config[1].
- --no-show-forced-updates
By default, git checks if a branch is force-updated duringfetch. Pass --no-show-forced-updates or set fetch.showForcedUpdatesto false to skip this check for performance reasons. If used duringgit-pull the --ff-only option will still check for forced updatesbefore attempting a fast-forward update. See git-config[1].
- -4
- --ipv4
Use IPv4 addresses only, ignoring IPv6 addresses.
- -6
- --ipv6
Use IPv6 addresses only, ignoring IPv4 addresses.
- <repository>
The "remote" repository that is the source of a fetchor pull operation. This parameter can be either a URL(see the section GIT URLS below) or the nameof a remote (see the section REMOTES below).
- <refspec>
Specifies which refs to fetch and which local refs to update.When no <refspec>s appear on the command line, the refs to fetchare read from
remote.<repository>.fetch
variables instead(see the section "CONFIGURED REMOTE-TRACKING BRANCHES"in git-fetch[1]).The format of a <refspec> parameter is an optional plus
+
, followed by the source <src>, followedby a colon:
, followed by the destination ref <dst>.The colon can be omitted when <dst> is empty. <src> istypically a ref, but it can also be a fully spelled hex objectname.A <refspec> may contain a
*
in its <src> to indicate a simple patternmatch. Such a refspec functions like a glob that matches any ref with thesame prefix. A pattern <refspec> must have a*
in both the <src> and<dst>. It will map refs to the destination by replacing the*
with thecontents matched from the source.If a refspec is prefixed by
^
, it will be interpreted as a negativerefspec. Rather than specifying which refs to fetch or which local refs toupdate, such a refspec will instead specify refs to exclude. A ref will beconsidered to match if it matches at least one positive refspec, and doesnot match any negative refspec. Negative refspecs can be useful to restrictthe scope of a pattern refspec so that it will not include specific refs.Negative refspecs can themselves be pattern refspecs. However, they may onlycontain a <src> and do not specify a <dst>. Fully spelled out hex objectnames are also not supported.tag <tag>
means the same asrefs/tags/<tag>:refs/tags/<tag>
;it requests fetching everything up to the given tag.The remote ref that matches <src>is fetched, and if <dst> is not an empty string, an attemptis made to update the local ref that matches it.
Whether that update is allowed without
--force
depends on the refnamespace it’s being fetched to, the type of object being fetched, andwhether the update is considered to be a fast-forward. Generally, thesame rules apply for fetching as when pushing, see the<refspec>...
section of git-push[1] for what those are. Exceptions to thoserules particular to git fetch are noted below.Until Git version 2.20, and unlike when pushing withgit-push[1], any updates to
refs/tags/*
would be acceptedwithout+
in the refspec (or--force
). When fetching, we promiscuouslyconsidered all tag updates from a remote to be forced fetches. SinceGit version 2.20, fetching to updaterefs/tags/*
works the same wayas when pushing. I.e. any updates will be rejected without+
in therefspec (or--force
).Unlike when pushing with git-push[1], any updates outside of
refs/{tags,heads}/*
will be accepted without+
in the refspec (or--force
), whether that’s swapping e.g. a tree object for a blob, ora commit for another commit that doesn’t have the previous commit asan ancestor etc.Unlike when pushing with git-push[1], there is noconfiguration which’ll amend these rules, and nothing like a
pre-fetch
hook analogous to thepre-receive
hook.As with pushing with git-push[1], all of the rules describedabove about what’s not allowed as an update can be overridden byadding an optional leading
+
to a refspec (or using the--force
command line option). The only exception to this is that no amount offorcing will make therefs/heads/*
namespace accept a non-commitobject.Note
When the remote branch you want to fetch is known tobe rewound and rebased regularly, it is expected thatit* new tip will not be a descendant of its previous tip(as stored in your remote-tracking branch the last timeyou fetched). You would wantto use the +
sign to indicate non-fast-forward updateswill be needed for such branches. There is no way todetermine or declare that a branch will be made availablein a repository with this behavior; the pulling user simplymust know this is the expected usage pattern for a branch.Note
There is a difference between listing multiple <refspec>directly on git pull command line and having multiple remote.<repository>.fetch
entries in your configurationfor a <repository> and running agit pull command without any explicit <refspec> parameters.<refspec>s listed explicitly on the command line are alwaysmerged into the current branch after fetching. In other words,if you list more than one remote ref, git pull will createan Octopus merge. On the other hand, if you do not list anyexplicit <refspec> parameter on the command line, git pullwill fetch all the <refspec>s it finds in theremote.<repository>.fetch
configuration and mergeonly the first <refspec> found into the current branch.This is because making anOctopus from remote refs is rarely done, while keeping trackof multiple remote heads in one-go by fetching more than oneis often useful.
FAQs
How to use git for documentation? ›
- About Git.
- Pushing commits to a remote repository.
- Getting changes from a remote repository.
- Dealing with non-fast-forward errors.
- Splitting a subfolder out into a new repository.
- About Git subtree merges.
- About Git rebase.
- Using Git rebase on the command line.
The git pull command is used to fetch and download content from a remote repository and immediately update the local repository to match that content. Merging remote upstream changes into your local repository is a common task in Git-based collaboration work flows.
How to pull files from git? ›It is used to acknowledge the change that you've made to the repository that you're working on. Or also called a target repository. The simple command to PULL from a branch is: git pull 'remote_name' 'branch_name' .
What is the standard git pull? ›- Updates the current local working branch (currently checked out branch)
- Updates the remote tracking branches for all other branches.
Every repository on GitHub.com comes equipped with a section for hosting documentation, called a wiki. You can use your repository's wiki to share long-form content about your project, such as how to use it, how you designed it, or its core principles.
How to create a document repository? ›- Collect your documents. Start by gathering all your documents, whether they exist in a digital or physical format. ...
- Scan your paper documents. ...
- Decide on a naming system. ...
- Index and sort your files. ...
- Integrate your paper and digital systems. ...
- Get your team on board.
Difference between Git fetch and pull. The key difference between git fetch and pull is that git pull copies changes from a remote repository directly into your working directory, while git fetch does not. The git fetch command only copies changes into your local Git repo. The git pull command does both.
Why is it called git pull? ›Pull requests are a GitHub and Bitbucket-specific feature that offers an easy, web-based way to submit your work, alternately called “patches,” to the project. The name “pull request” comes from the idea that you're requesting the project to “pull” changes from your fork.
How to take a pull request from git? ›- Click Preview Pull Request. ...
- Confirm that the branch in the base: dropdown menu is the branch where you want to merge your changes. ...
- Click Create Pull Request. ...
- Type a title and description for your pull request.
- To create a pull request that is ready for review, click Create Pull Request.
- Switch to the branch where you want to checkout the file. git switch feature/A.
- Get the file from the other branch. git restore --source feature/B -- utils.js.
- Commit and push the changes.
How to retrieve data from git? ›
Use git fetch to retrieve new work done by other people. Fetching from a repository grabs all the new remote-tracking branches and tags without merging those changes into your own branches. Otherwise, you can always add a new remote and then fetch. For more information, see "Managing remote repositories."
Can you pull specific files from git? ›Sparse checkout is a feature in Git that allows you to selectively check out only specific subdirectories or files from a repository, rather than the entire repository. This is useful in large repositories where you only need access to a subset of the content.
What is the pull command for git? ›The "git pull" command. The pull command is used to access the changes (commits)from a remote repository to the local repository. It updates the local branches with the remote-tracking branches. Remote tracking branches are branches that have been set up to push and pull from the remote repository.
What protocol does git pull use? ›Git can use four distinct protocols to transfer data: Local, HTTP, Secure Shell (SSH) and Git.
What is the easiest git tool? ›- QGit. QGit is a free Git GUI for Linux that shows different branches visually and allows you to see patch content and file changes. ...
- Gitg. The user interface of Gitg is straightforward to use. ...
- Git Force. ...
- Sourcetree. ...
- GitHub Desktop. ...
- TortoiseGit. ...
- GitUp. ...
- Fork.
Using Git as a version control method for document control and collaboration in the legal industry makes a ton of sense.
How to use Git professionally? ›- Create a "repository" (project) with a git hosting tool (like Bitbucket)
- Copy (or clone) the repository to your local machine.
- Add a file to your local repo and "commit" (save) the changes.
- "Push" your changes to your main branch.
- Make a change to your file with a git hosting tool and commit.
With Word Diff you can use Git's native cryptographic diff functionality - which ensures the authenticity and integrity of a document - to quickly verify what's changed in a given iteration, or compare different versions of the document over time, all with a single click.
Can we store documents in Git? ›Git LFS handles large files by storing references to the file in the repository, but not the actual file itself. To work around Git's architecture, Git LFS creates a pointer file which acts as a reference to the actual file (which is stored somewhere else).