Introduction
My typical git use consists in archiving file modifications for personal projects. Sometimes I share these projects with a few colleagues. We are then 2, 3 or a handful of persons working concurrently on the same project, pushing and pulling changes several times per week or even per day.
Simple workflow for one user
We suppose someone has helped you initialise a git repository. Before you modify files, get the latest version of files from the remote repository:
Work and modify files in the folder. At some point, when your work has reached a certain status, you might want to archive it before you move on to something else. The few commands below tell git to archive the work.
Show which files have been modified in the folder under git control:
Add a file to be committed
Or add all files:
Commit and describe changes
Now you can continue working and changing files. Repeat the git add —all or git add filename followed by git commit -m «describe changes» each time your reach a point where you think it’s a good idea to archive your work (when a fix is implemented, or at the end of the morning). Before you leave your computer, push the content to the remote repository with:
In case you work with other people on this remote repository, Before you push, you might want to integrate work done by others in your repository. If any new work has been added by others on the remote repository, git will ask you to first do:
This simple work flow works well for one user pulling from- and pushing to- a master branch on a remote repository.
Sometimes the vi editor starts. To exit the vi editor:
Note: you might use a graphical git client with check boxes to add the files to be committed.
Workflow with branches
Initialise a new repository
Change to the development branch
Work and modify files in the folder. At some point, when your work has reached a certain status, you might want to archive it before you move on to something else. The few commands below tell git to archive the work. All file modifications will be archived with a commit hash which is a unique key describing your changes. The most important part is entering a commit message, it should be sufficiently general to describe your changes with a high level of abstraction and sufficiently specific to be understood amoung all other changes later.
First show which files have been modified in the folder under git control:
Add a file to be committed
Commit and describe changes
Now you can continue working and changing files. Repeat the git add —all and git commit -m «describe changes» each time your reach a consistant change status.
At some point you will be ready to upload your content to a remote archive. Merge to the master branch
Push contents to the remote repository
See below how to set-up the remote repository with git remote add origin ssh:repositoryurl and pushing content for the first time with git push -u origin master .
Check status again
Go back to the development branch
Continue to modify files in the repository.
Add and commit
Add patterns
Add modified markdown files to the next git commit
The star * is a file glob pattern that matches all other path components in between.
Commit messages
Commit messages descripe at a high level what has been changed in the code.
On the linux kernel repository commit messages start with a capital letter and do not have a dot at the end. This style is also what is written in the tidyverse style guide.
Example of a long commit message (like a letter) torvalds/uemacs Stop using ‘short’ for line and allocation sizes.
“I really should just learn another editor, rather than continue to polish this turd.”
Add minor changes to the previous commit (git commit –amend):
Autocompletion
git has an auto complete feature available in a script: git-completion.bash .
That script can be loaded in bashrc at the start of the shell. A debian package was made to simply load git-completion.bash for you:
Branching
To start work in a new branch:
To compare a file between 2 branches:
To compare the tip of 2 branches
To merge changes back to the main branch:
If there were conflicts, they will be presented in this way:
If I am on a detached head, it is recommended to create a temporary branch (stackoverflow).
Delete uncommitted changes in current working directory:
See also below git clean.
Branching strategy
For solo projects, I use to have this branching strategy:
I never work in the master branch, always in a development branch called develop . I merge develop in master , only before pushing modifications back to my remote archive. This simple branching strategy makes it much easier to deal with potential changes in the remote master branch.
But I have now changed to a simpler strategy where I work only on the master branch.
For collaborative projects, we use feature branches or also a dev and a main branch.
Delete a branch
I might need to delete a branch at some point:
Delete a remote branch
Check if a branch has been merged before deleting it
git merge-base main compare
Will return the latest common commit between the 2 branches.
Merge branches
To merge branch1 changes to the main branch:
In case of conflict, you can edit the corresponding file(s) manually in a text editor, or you can decide to keep one of the 2 versions by checking out. For example if you are in the main branch
will get the file as it is in the main branch, while
will get the file as it is in branch1 . And vice-versa if you are currently in a feature branch git checkout —ours <filename> will get the file as it is in the feature branch.
Unmerged paths
When a file in a status Unmerged paths
Either edit the file, looking for ===== to find the zones of conflict. Or revert to the latest tracked version of that file with
Checkout a remote branch
When you fetch a remote repository, you get all its branches. The remote branches can be viewed with:
If there is only one branch with that name, you can simply do (without the remote prefix, only the branch name):
To create a local branch that tracks the remote branch. You’ll be able to make changes to that local branch and push them to the remote branch later.
Branch naming convention
“If your branch name is more than one words you should use underscore _ rather than hyphen — because — here separates the two different branch.”
Configuring git
Configuring user name and email
Display your user name, email and remote repositories
To change username and email globally
Stackoverflow git multiple user names for different projects explains how to change the email for the current repository only
Other config –global options
Edit the global configuration file
Remembering passwords
Alternativelly, it’s better to use ssh keys to connect to git repositories.
Debug git with trace
To see more output when a git command is not working as you would expect you can prefix it with GIT_TRACE=1 :
Display changes
To view modified files that have not been committed and to view commit history you can use:
Show when the tip of branches have been updated
Alternatively, call the repository browser with:
To view a shorter version of the log file, and get an idea at where I am in the history:
You can define an alias for git log as explained be Fred here:
The new alias can then be used with
Use tags to specify important points in history, such as software versions.
Diff the working directory
Shows the changes between the working directory and the index.
Shows the changes between the index and the HEAD
Shows all the changes between the working directory and HEAD
Compare between 2 commits
Useful to track different versions of CSV files headers.
Diff csv files
To consider commas a separator when using word diff in csv file, you can use
Show changes in previous commits
Show which change happened in a particular commit
Show only word changes
Blame
To see the commit number and author of each line in a file use
Illustrations
.gitignore
To ignore all files in a folder but not the folder itself. Put this .gitignore into the folder, then git add .gitignore
To exclude everything except a specific directory foo/bar (note the /* — without the slash, the wildcard would also exclude everything within foo/bar):
.gitkeep
some answers suggest using .gitkeep or simply .keep because files starting with “.git” should be reserved for git usage.
Git run to automate many repositories
Git run enables to pull from many repositories with a single command
configuration was a bit complicated on debian
Install nodejs and npm from the backports
in your home directory, create a directory for global installations:
Configure npm to use the new directory path:
Install Git run:
Edit your bash profile:
and add this line:
Then the configuration file is a .json file on the home folder. Edit it:
Show the status and pull from many repos:
Going back in time
Display the modification log
In the log, you can copy the beginning of a commit hash for use as commit_sha in the reset commands below.
Display the log of a particular branch (after a fetch for example)
Display the log of a particular file
Display a compact log for one file or one directory only
/.gitconfig to define an alias that shows the last 10 log entries in a compact way:
This alias also works with the log of one file only
Commit statistics
Show the number of lines modified in each files for each commit:
A one liner version showing the number of files changes, number of lines inserted and deleted how to get log with short stat in one line:
Export the log to csv
/.gitconfig to define it as an alias:
Another version adding stats on the number of files changes, number of lines inserted and deleted based on how to get log with short stat in one line:
Simpler solution using paste to glue lines together (there is an issue with extra spaces at the beginning and in the middle of some lines):
Find last commit where a file was still present in the repository
Show commits where a particular file was modified
The tig utility is a repository browser for git log and git diff.
Rewriting history
Amend to the previous commit
In case you entered a wrong commit message, you can edit the last commit message with:
In case you forgot a file, you can add a file to the last commit with:
A comment in How to change past commit to include a missed file? specifies that commits before and after —amend have different hashes, even if only the commit message is changed. The use of —amend is only for private commits, which have not yet been shared with others.
Rewriting commits older than the previous one is much harder. It requires the use of git rebase. I regularly want to fix typo in the git log, but it is not possible it was made unflexible on purpose. Explained in this Stackoverflow Answer
“The real reason git doesn’t allow you to change the commit message ends up being very simple: that way, you can trust the messages. If you allowed people to change them afterwards, the messages are inherently not very trustworthy.”
Rebase your changes on top of the remote head commit
It is safe to use rebase as long as the commits have not been pushed to another repository. To rename older commits, simply run:
Rebase will show the last 3 commits by default in the vim editor. Each line starts with “pick” followed by the commit hash and commit message. You can then replace the “pick” word in the vim editor by the command you want to achieve, press “escape”, “:wq” and peform the git command on the selected commit.
Answers to a StackOverflow question How to modify a specified commit?.
10 things I hate about git Translation of the man page which he considers hard to understand: “git-rebase – Sequentially regenerate a series of commits so they can be applied directly to the head node”
Rebase when a remote branch has diverged and there is a merge conflict
You can either go through with the rebase and resolve the conflict. In case you just want to get to the status of the remote branch
Abort the Rebase:
Reset the local branch
Merge conflict
To keep only the version of their changes
Git history when changing a licence
SO question in a case where the project was not made available publicly yet.
- Use rebase -i
- or use git filter-branch
Clean
Remove all files also those not tracked by git because they are in .gitignore. For example output pdf files and auxiliary files generated from latex or from pandoc.
Remove all files including directories
Remove local (untracked) files from my current Git branch
Show what will be deleted with the -n option:
Then — beware: this will delete files — run:
Alternatively clean in interactive mode:
Reset whole folder
Identify the commit identity in the log and copy its sha number. Then to go back to this state for the whole folder:
Do this before pushing only!
Once you have pushed the changes, you need to revert the commit and commit those changes as well:
Use the begining of a commit_sha copied from the log.
To remove a commit where I accidentaly commited a very large file. I used how to remove a too large file in a commit:
Then added the large file to .gitignore and committed again.
Reset only one file
To go back to this state for only one file, see git checkout
No need to enter the commit hash to get to get the file from the latest commit
Checkout the older revision of a file under a new name
See also alias and git grep below.
Revert
Revert an unwanted commit with a new commit doing exactly the reverse operation
“When you have a problem you are chasing down, and you hit a”revert this merge”, what you’re hitting is essentially a single commit that contains all the changes (but obviously in reverse) of all the commits that got merged. So it’s debugging hell, because now you don’t have lots of small changes that you can try to pinpoint which part of it changes.
But does it all work? Sure it does. You can revert a merge, and from a purely technical angle, Git did it very naturally and had no real troubles. It just considered it a change from “state before merge” to “state after merge”, and that was it. Nothing complicated, nothing odd, nothing really dangerous. Git will do it without even thinking about it.
So from a technical angle, there’s nothing wrong with reverting a merge, but from a workflow angle it’s something that you generally should try to avoid.
If at all possible, for example, if you find a problem that got merged into the main tree, rather than revert the merge, try really hard to bisect the problem down into the branch you merged, and just fix it, or try to revert the individual commit that caused it.
Yes, it’s more complex, and no, it’s not always going to work (sometimes the answer is: “oops, I really shouldn’t have merged it, because it wasn’t ready yet, and I really need to undo all of the merge”). So then you really should revert the merge, but when you want to re-do the merge, you now need to do it by reverting the revert.”
Dangling blobs and trees
Show dangling blobs and trees with the git file system check command:
“Dangling blob = A change that made it to the staging area/index, but never got committed. One thing that is amazing with Git is that once it gets added to the staging area, you can always get it back because these blobs behave like commits in that they have a hash too!!”
git fsck shows dangling blobs and dangling trees. Running git cat-file -p blob_sha > /path/to/the/file followed by git diff shows me a lot of line deletions. I have to explore around to find which blob is adding content back.
To retrieve a single file from a dangling blob
To retrieve many files from a dangling tree SO recover dangling blobs in git
Going forward in time
Cherry pick one commit
I was on a dev branch and committed a change to the README file. But in fact I wanted this change — related to installations instructions — to be visible by all users immediately. So that commit should have been on the main branch. The problem is that I had other commit in the dev branch that were not ready yet to be shared on the main branch. In order to pick just the commit that changed the README file and put it in the main branch I did:
GUI Graphical User Interface
For colleagues who need a GUI:
-
recommended on this SO answer
A section of the git book on Graphical User Interfaces describes the default git-gui and gitk graphical user interfaces to prepare commits and view the git log history. It also describes the github desktop client and in particular it’s “sync” feature:
“The main way you interact with other repositories over the network is through the “Sync” feature. Git internally has separate operations for pushing, fetching, merging, and rebasing, but the GitHub clients collapse all of these into one multi-step feature. Here’s what happens when you click the Sync button:
This is the most common sequence of network commands when working in this style, so squashing them into one command saves a lot of time. ”
Каково назначение ключа `-u` при git push?
И чем отличает отправка без ключа git push origin master .
С ключом -u (полный вариант —set-upstream ) вы создаёте (если ещё не существует) в удалённом репозитории ветку, соответствующую вашей локальной и связываете их:
- В remote/branchname будет производиться push в локальную ветку branchname
- Из remote/branchname будет производиться pull в локальную ветку branchname
Для master это актуально, только если вы пушите в пустой репозиторий. Если клонировали — то соответствие ветвей уже настроено. А вот как только вы создадите новую локальную ветвь и захотите её запушить на remote, вам понадобится ключ -u .
Если сделать git push ветки без ключа -u , Git не свяжет локальную ветку с веткой удалённого репозитория. Последующая операция git pull в этой ветке будет неудачной, так как Git не будет знать, из какой удалённой ветки подтягивать изменения, это придётся указать явно при помощи команды git branch —set-upstream-to=origin/master . Смысл использовать ключ -u есть только при пуше новых веток, для существующих (связанных с удалёнными) веток каждый раз перезаписывать связку необязательно.
Дизайн сайта / логотип © 2023 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2023.8.2.43556
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.
Git push u что это
- 2.41.0 06/01/23
- 2.40.1 no changes
- 2.40.0 03/12/23
- 2.39.1 → 2.39.3 no changes
- 2.39.0 12/12/22
- 2.38.1 → 2.38.5 no changes
- 2.38.0 10/02/22
- 2.35.1 → 2.37.7 no changes
- 2.35.0 01/24/22
- 2.33.1 → 2.34.8 no changes
- 2.33.0 08/16/21
- 2.32.1 → 2.32.7 no changes
- 2.32.0 06/06/21
- 2.30.1 → 2.31.8 no changes
- 2.30.0 12/27/20
Check your version of git by running
git-push — Update remote refs along with associated objects
SYNOPSIS
DESCRIPTION
Updates remote refs using local refs, while sending objects necessary to complete the given refs.
You can make interesting things happen to a repository every time you push into it, by setting up hooks there. See documentation for git-receive-pack[1].
When the command line does not specify where to push with the <repository> argument, branch.*.remote configuration for the current branch is consulted to determine where to push. If the configuration is missing, it defaults to origin.
When the command line does not specify what to push with <refspec>. arguments or —all , —mirror , —tags options, the command finds the default <refspec> by consulting remote.*.push configuration, and if it is not found, honors push.default configuration to decide what to push (See git-config[1] for the meaning of push.default ).
When neither the command-line nor the configuration specify what to push, the default behavior is used, which corresponds to the simple value for push.default : the current branch is pushed to the corresponding upstream branch, but as a safety measure, the push is aborted if the upstream branch does not have the same name as the local one.
OPTIONS
The «remote» repository that is destination of a push operation. This parameter can be either a URL (see the section GIT URLS below) or the name of a remote (see the section REMOTES below).
Specify what destination ref to update with what source object. The format of a <refspec> parameter is an optional plus + , followed by the source object <src>, followed by a colon : , followed by the destination ref <dst>.
The <src> is often the name of the branch you would want to push, but it can be any arbitrary «SHA-1 expression», such as master
The <dst> tells which ref on the remote side is updated with this push. Arbitrary expressions cannot be used here, an actual ref must be named. If git push [<repository>] without any <refspec> argument is set to update some ref at the destination with <src> with remote.<repository>.push configuration variable, :<dst> part can be omitted—such a push will update a ref that <src> normally updates without any <refspec> on the command line. Otherwise, missing :<dst> means to update the same ref as the <src> .
If <dst> doesn’t start with refs/ (e.g. refs/heads/master ) we will try to infer where in refs/* on the destination <repository> it belongs based on the type of <src> being pushed and whether <dst> is ambiguous.
If <dst> unambiguously refers to a ref on the <repository> remote, then push to that ref.
If <src> resolves to a ref starting with refs/heads/ or refs/tags/, then prepend that to <dst>.
Other ambiguity resolutions might be added in the future, but for now any other cases will error out with an error indicating what we tried, and depending on the advice.pushUnqualifiedRefname configuration (see git-config[1]) suggest what refs/ namespace you may have wanted to push to.
The object referenced by <src> is used to update the <dst> reference on the remote side. Whether this is allowed depends on where in refs/* the <dst> reference lives as described in detail below, in those sections «update» means any modifications except deletes, which as noted after the next few sections are treated differently.
The refs/heads/* namespace will only accept commit objects, and updates only if they can be fast-forwarded.
The refs/tags/* namespace will accept any kind of object (as commits, trees and blobs can be tagged), and any updates to them will be rejected.
It’s possible to push any type of object to any namespace outside of refs/
I.e. a fast-forward of commits and tags outside refs/
Tree and blob objects outside of refs/
All of the rules described above about what’s not allowed as an update can be overridden by adding an the optional leading + to a refspec (or using —force command line option). The only exception to this is that no amount of forcing will make the refs/heads/* namespace accept a non-commit object. Hooks and configuration can also override or amend these rules, see e.g. receive.denyNonFastForwards in git-config[1] and pre-receive and update in githooks[5].
Pushing an empty <src> allows you to delete the <dst> ref from the remote repository. Deletions are always accepted without a leading + in the refspec (or —force ), except when forbidden by configuration or hooks. See receive.denyDeletes in git-config[1] and pre-receive and update in githooks[5].
The special refspec : (or +: to allow non-fast-forward updates) directs Git to push «matching» branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name already exists on the remote side.
tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag> .
Push all branches (i.e. refs under refs/heads/ ); cannot be used with other <refspec>.
Remove remote branches that don’t have a local counterpart. For example a remote branch tmp will be removed if a local branch with the same name doesn’t exist any more. This also respects refspecs, e.g. git push —prune remote refs/heads/*:refs/tmp/* would make sure that remote refs/tmp/foo will be removed if refs/heads/foo doesn’t exist.
Instead of naming each ref to push, specifies that all refs under refs/ (which includes but is not limited to refs/heads/ , refs/remotes/ , and refs/tags/ ) be mirrored to the remote repository. Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end. This is the default if the configuration option remote.<remote>.mirror is set.
Do everything except actually send the updates.
Produce machine-readable output. The output status line for each ref will be tab-separated and sent to stdout instead of stderr. The full symbolic names of the refs will be given.
All listed refs are deleted from the remote repository. This is the same as prefixing all refs with a colon.
All refs under refs/tags are pushed, in addition to refspecs explicitly listed on the command line.
Push all the refs that would be pushed without this option, and also push annotated tags in refs/tags that are missing from the remote but are pointing at commit-ish that are reachable from the refs being pushed. This can also be specified with configuration variable push.followTags . For more information, see push.followTags in git-config[1].
GPG-sign the push request to update refs on the receiving side, to allow it to be checked by the hooks and/or be logged. If false or —no-signed , no signing will be attempted. If true or —signed , the push will fail if the server does not support signed pushes. If set to if-asked , sign if and only if the server supports signed pushes. The push will also fail if the actual call to gpg —sign fails. See git-receive-pack[1] for the details on the receiving end.
Use an atomic transaction on the remote side if available. Either all refs are updated, or on error, no refs are updated. If the server does not support atomic pushes the push will fail.
Transmit the given string to the server, which passes them to the pre-receive as well as the post-receive hook. The given string must not contain a NUL or LF character. When multiple —push-option=<option> are given, they are all sent to the other side in the order listed on the command line. When no —push-option=<option> is given from the command line, the values of configuration variable push.pushOption are used instead.
Path to the git-receive-pack program on the remote end. Sometimes useful when pushing to a remote repository over ssh, and you do not have the program in a directory on the default $PATH.
—[no-]force-with-lease —force-with-lease=<refname> —force-with-lease=<refname>:<expect>
Usually, «git push» refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it.
This option overrides this restriction if the current value of the remote ref is the expected value. «git push» fails otherwise.
Imagine that you have to rebase what you have already published. You will have to bypass the «must fast-forward» rule in order to replace the history you originally published with the rebased history. If somebody else built on top of your original history while you are rebasing, the tip of the branch at the remote may advance with their commit, and blindly pushing with —force will lose their work.
This option allows you to say that you expect the history you are updating is what you rebased and want to replace. If the remote ref still points at the commit you specified, you can be sure that no other people did anything to the ref. It is like taking a «lease» on the ref without explicitly locking it, and the remote ref is updated only if the «lease» is still valid.
—force-with-lease alone, without specifying the details, will protect all remote refs that are going to be updated by requiring their current value to be the same as the remote-tracking branch we have for them.
—force-with-lease=<refname> , without specifying the expected value, will protect the named ref (alone), if it is going to be updated, by requiring its current value to be the same as the remote-tracking branch we have for it.
—force-with-lease=<refname>:<expect> will protect the named ref (alone), if it is going to be updated, by requiring its current value to be the same as the specified value <expect> (which is allowed to be different from the remote-tracking branch we have for the refname, or we do not even have to have such a remote-tracking branch when this form is used). If <expect> is the empty string, then the named ref must not already exist.
Note that all forms other than —force-with-lease=<refname>:<expect> that specifies the expected current value of the ref explicitly are still experimental and their semantics may change as we gain experience with this feature.
«—no-force-with-lease» will cancel all the previous —force-with-lease on the command line.
A general note on safety: supplying this option without an expected value, i.e. as —force-with-lease or —force-with-lease=<refname> interacts very badly with anything that implicitly runs git fetch on the remote to be pushed to in the background, e.g. git fetch origin on your repository in a cronjob.
The protection it offers over —force is ensuring that subsequent changes your work wasn’t based on aren’t clobbered, but this is trivially defeated if some background process is updating refs in the background. We don’t have anything except the remote tracking info to go by as a heuristic for refs you’re expected to have seen & are willing to clobber.
If your editor or some other system is running git fetch in the background for you a way to mitigate this is to simply set up another remote:
Now when the background process runs git fetch origin the references on origin-push won’t be updated, and thus commands like:
Will fail unless you manually run git fetch origin-push . This method is of course entirely defeated by something that runs git fetch —all , in that case you’d need to either disable it or do something more tedious like:
I.e. create a base tag for versions of the upstream code that you’ve seen and are willing to overwrite, then rewrite history, and finally force push changes to master if the remote version is still at base , regardless of what your local remotes/origin/master has been updated to in the background.
Alternatively, specifying —force-if-includes as an ancillary option along with —force-with-lease[=<refname>] (i.e., without saying what exact commit the ref on the remote side must be pointing at, or which refs on the remote side are being protected) at the time of «push» will verify if updates from the remote-tracking refs that may have been implicitly updated in the background are integrated locally before allowing a forced update.
Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. Also, when —force-with-lease option is used, the command refuses to update a remote ref whose current value does not match what is expected.
This flag disables these checks, and can cause the remote repository to lose commits; use it with care.
Note that —force applies to all the refs that are pushed, hence using it with push.default set to matching or with multiple push destinations configured with remote.*.push may overwrite refs other than the current branch (including local refs that are strictly behind their remote counterpart). To force a push to only one branch, use a + in front of the refspec to push (e.g git push origin +master to force a push to the master branch). See the <refspec>. section above for details.
Force an update only if the tip of the remote-tracking ref has been integrated locally.
This option enables a check that verifies if the tip of the remote-tracking ref is reachable from one of the «reflog» entries of the local branch based in it for a rewrite. The check ensures that any updates from the remote have been incorporated locally by rejecting the forced update if that is not the case.
If the option is passed without specifying —force-with-lease , or specified along with —force-with-lease=<refname>:<expect> , it is a «no-op».
Specifying —no-force-if-includes disables this behavior.
This option is equivalent to the <repository> argument. If both are specified, the command-line argument takes precedence.
For every branch that is up to date or successfully pushed, add upstream (tracking) reference, used by argument-less git-pull[1] and other commands. For more information, see branch.<name>.merge in git-config[1].
These options are passed to git-send-pack[1]. A thin transfer significantly reduces the amount of sent data when the sender and receiver share many of the same objects in common. The default is —thin .
Suppress all output, including the listing of updated refs, unless an error occurs. Progress is not reported to the standard error stream.
Progress status is reported on the standard error stream by default when it is attached to a terminal, unless -q is specified. This flag forces progress status even if the standard error stream is not directed to a terminal.
May be used to make sure all submodule commits used by the revisions to be pushed are available on a remote-tracking branch. If check is used Git will verify that all submodule commits that changed in the revisions to be pushed are available on at least one remote of the submodule. If any commits are missing the push will be aborted and exit with non-zero status. If on-demand is used all submodules that changed in the revisions to be pushed will be pushed. If on-demand was not able to push all necessary revisions it will also be aborted and exit with non-zero status. If only is used all submodules will be pushed while the superproject is left unpushed. A value of no or using —no-recurse-submodules can be used to override the push.recurseSubmodules configuration variable when no submodule recursion is required.
When using on-demand or only, if a submodule has a «push.recurseSubmodules=
Toggle the pre-push hook (see githooks[5]). The default is —verify, giving the hook a chance to prevent the push. With —no-verify, the hook is bypassed completely.
Use IPv4 addresses only, ignoring IPv6 addresses.
Use IPv6 addresses only, ignoring IPv4 addresses.
GIT URLS
In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent.
Git supports ssh, git, http, and https protocols (in addition, ftp, and ftps can be used for fetching, but this is inefficient and deprecated; do not use it).
What does the -u parameter mean in git push -u origin master?
I’ve been using Bitbucket from Atlassian and when I need to push some data into my repository I have to type the following command:
In git documentation it’s:
Why do we need that special -u parameter? What does it do?
1 Answer 1
The git manual for push (which can be viewed in the terminal with man git-push ):
-u
—set-upstreamFor every branch that is up to date or successfully pushed, add upstream (tracking) reference, used by argument-less git-pull[1] and other commands. For more information, see branch.<name>.merge in git-config[1].
Simply put, it sets the push target as current branch’s upstream.
Once you’ve issued git push -u origin master on branch master , you can simply git push without extra arguments on that branch and it will be equivalent to git push origin master .
Note that branch names don’t have to match. You can set your local master to push to origin/foo , although it will be confusing. You can also still push to branches other than upstream explicitly, it won’t overwrite the upstream setting.
The upstream branch can be set without pushing using git branch -u origin/master . Note that origin/master is an argument for the -u option, not for the git branch command in general, hence it must be specified in the remoteName/branchName format rather than two separate arguments: remoteName branchName .