| blob | e457994458ec890cf9ccf337d90e73e64df70fcb |
4 <head>
8 /* Debug borders */
10 /*
11 border: 1px solid red;
12 */
13 }
15 body {
17 }
19 a {
22 }
25 }
27 em {
29 }
31 strong {
33 }
35 tt {
37 }
45 }
49 }
50 h2 {
52 }
53 h3 {
55 }
56 h3 + * {
58 }
63 }
65 hr {
67 }
69 p {
72 }
74 pre {
77 }
79 span#author {
84 }
85 span#email {
86 }
87 span#revision {
89 }
91 div#footer {
97 }
98 div#footer-text {
101 }
102 div#footer-badges {
105 }
107 div#preamble,
114 }
118 }
122 }
124 /* Block element titles. */
131 }
134 }
138 }
141 }
144 }
150 }
154 }
159 }
163 }
167 }
170 }
179 }
183 }
188 }
192 }
198 dl {
201 }
202 dt {
206 }
209 }
213 }
216 }
220 }
221 thead {
224 }
225 tfoot {
227 }
232 }
235 }
240 }
243 }
247 }
249 div#toctitle {
256 }
261 }
265 }
269 }
273 }
275 /* Workarounds for IE6's broken and incomplete CSS2. */
281 }
287 }
293 }
297 }
302 }
304 /* IE6 sets dynamically generated links as visited. */
306 </style>
308 </head>
309 <body>
311 <h1>
312 git-push(1) Manual Page
313 </h1>
316 <p>git-push -
317 Update remote refs along with associated objects
318 </p>
319 </div>
320 </div>
324 <div class="content"><em>git push</em> [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
327 </div>
331 necessary to complete the given refs.</p></div>
335 </div>
339 <dt>
341 </dt>
342 <dd>
343 <p>
344 The "remote" repository that is destination of a push
345 operation. This parameter can be either a URL
348 </p>
349 </dd>
350 <dt>
352 </dt>
353 <dd>
354 <p>
359 in the remote repository is to be updated.
360 </p>
361 <div class="para"><p>The <src> is often the name of the branch you would want to push, but
365 push. Arbitrary expressions cannot be used here, an actual ref must
367 updated.</p></div>
368 <div class="para"><p>The object referenced by <src> is used to update the <dst> reference
369 on the remote side, but by default this is only allowed if the
373 EXAMPLES below for details.</p></div>
374 <div class="para"><p><tt>tag <tag></tt> means the same as <tt>refs/tags/<tag>:refs/tags/<tag></tt>.</p></div>
376 the remote repository.</p></div>
377 <div class="para"><p>The special refspec <tt>:</tt> (or <tt>+:</tt> to allow non-fast forward updates)
378 directs git to push "matching" branches: for every branch that exists on
379 the local side, the remote side is updated if a branch of the same name
380 already exists on the remote side. This is the default operation mode
381 if no explicit refspec is found (that is neither on the command line
382 nor in any Push line of the corresponding remotes file---see below).</p></div>
383 </dd>
384 <dt>
385 --all
386 </dt>
387 <dd>
388 <p>
389 Instead of naming each ref to push, specifies that all
391 </p>
392 </dd>
393 <dt>
394 --mirror
395 </dt>
396 <dd>
397 <p>
398 Instead of naming each ref to push, specifies that all
401 be mirrored to the remote repository. Newly created local
402 refs will be pushed to the remote end, locally updated refs
403 will be force updated on the remote end, and deleted refs
404 will be removed from the remote end. This is the default
406 set.
407 </p>
408 </dd>
409 <dt>
410 -n
411 </dt>
412 <dt>
413 --dry-run
414 </dt>
415 <dd>
416 <p>
417 Do everything except actually send the updates.
418 </p>
419 </dd>
420 <dt>
421 --porcelain
422 </dt>
423 <dd>
424 <p>
425 Produce machine-readable output. The output status line for each ref
426 will be tab-separated and sent to stdout instead of stderr. The full
427 symbolic names of the refs will be given.
428 </p>
429 </dd>
430 <dt>
431 --tags
432 </dt>
433 <dd>
434 <p>
436 addition to refspecs explicitly listed on the command
437 line.
438 </p>
439 </dd>
440 <dt>
442 </dt>
443 <dt>
445 </dt>
446 <dd>
447 <p>
449 end. Sometimes useful when pushing to a remote
450 repository over ssh, and you do not have the program in
451 a directory on the default $PATH.
452 </p>
453 </dd>
454 <dt>
455 -f
456 </dt>
457 <dt>
458 --force
459 </dt>
460 <dd>
461 <p>
462 Usually, the command refuses to update a remote ref that is
463 not an ancestor of the local ref used to overwrite it.
464 This flag disables the check. This can cause the
465 remote repository to lose commits; use it with care.
466 </p>
467 </dd>
468 <dt>
470 </dt>
471 <dd>
472 <p>
475 remote name from the current branch: If it tracks a remote
476 branch, then that remote repository is pushed to. Otherwise,
477 the name "origin" is used. For this latter case, this option
478 can be used to override the name "origin". In other words,
479 the difference between these two commands
480 </p>
485 </div></div>
487 only if the current branch does not track a remote branch. This is
489 </dd>
490 <dt>
491 --thin
492 </dt>
493 <dt>
494 --no-thin
495 </dt>
496 <dd>
497 <p>
499 transfer spends extra cycles to minimize the number of
500 objects to be sent and meant to be used on slower connection.
501 </p>
502 </dd>
503 <dt>
504 -v
505 </dt>
506 <dt>
507 --verbose
508 </dt>
509 <dd>
510 <p>
511 Run verbosely.
512 </p>
513 </dd>
514 <dt>
515 -q
516 </dt>
517 <dt>
518 --quiet
519 </dt>
520 <dd>
521 <p>
522 Suppress all output, including the listing of updated refs,
523 unless an error occurs.
524 </p>
525 </dd>
526 </dl></div>
527 </div>
531 to name the remote repository:</p></div>
535 <li>
536 <p>
537 rsync://host.xz/path/to/repo.git/
538 </p>
539 </li>
540 <li>
541 <p>
543 </p>
544 </li>
545 <li>
546 <p>
548 </p>
549 </li>
550 <li>
551 <p>
553 </p>
554 </li>
555 <li>
556 <p>
558 </p>
559 </li>
560 <li>
561 <p>
563 </p>
564 </li>
565 <li>
566 <p>
568 </p>
569 </li>
570 <li>
571 <p>
573 </p>
574 </li>
575 <li>
576 <p>
578 </p>
579 </li>
580 </ul></div>
581 </div></div>
583 optionally specify which user to log-in as, and an alternate,
584 scp-like syntax is also supported. Both syntaxes support
585 username expansion, as does the native git protocol, but
586 only the former supports port specification. The following
587 three are identical to the last three above, respectively:</p></div>
591 <li>
592 <p>
594 </p>
595 </li>
596 <li>
597 <p>
599 </p>
600 </li>
601 <li>
602 <p>
604 </p>
605 </li>
606 </ul></div>
607 </div></div>
612 <li>
613 <p>
614 /path/to/repo.git/
615 </p>
616 </li>
617 <li>
618 <p>
619 file:///path/to/repo.git/
620 </p>
621 </li>
622 </ul></div>
623 </div></div>
627 you want to use a different format for them (such that the URLs you
628 use will be rewritten into URLs that work), you can create a
629 configuration section of the form:</p></div>
634 </div></div>
639 insteadOf = host.xz:/path/to/
640 insteadOf = work:</tt></pre>
641 </div></div>
645 configuration section of the form:</p></div>
650 </div></div>
655 pushInsteadOf = git://example.org/</tt></pre>
656 </div></div>
658 "ssh://example.org/path/to/repo.git" for pushes, but pulls will still
659 use the original URL.</p></div>
660 </div>
666 <li>
667 <p>
669 </p>
670 </li>
671 <li>
672 <p>
674 </p>
675 </li>
676 <li>
677 <p>
679 </p>
680 </li>
681 </ul></div>
683 because they each contain a refspec which git will use by default.</p></div>
684 <h3 id="_named_remote_in_configuration_file">Named remote in configuration file</h3><div style="clear:left"></div>
686 configured using <a href="git-remote.html">git-remote(1)</a>, <a href="git-config.html">git-config(1)</a>
688 this remote will be used to access the repository. The refspec
689 of this remote will be used by default when you do
690 not provide a refspec on the command line. The entry in the
691 config file would appear like this:</p></div>
699 </div></div>
700 <div class="para"><p>The <tt><pushurl></tt> is used for pushes only. It is optional and defaults
702 <h3 id="_named_file_in_tt_git_dir_remotes_tt">Named file in <tt>$GIT_DIR/remotes</tt></h3><div style="clear:left"></div>
705 in this file will be used to access the repository. The refspec
706 in this file will be used as default when you do not
707 provide a refspec on the command line. This file should have the
708 following format:</p></div>
711 <pre><tt> URL: one of the above URL format
714 </tt></pre>
715 </div></div>
719 be specified for additional branch mappings.</p></div>
720 <h3 id="_named_file_in_tt_git_dir_branches_tt">Named file in <tt>$GIT_DIR/branches</tt></h3><div style="clear:left"></div>
723 The URL in this file will be used to access the repository.
724 This file should have the following format:</p></div>
728 </div></div>
729 <div class="para"><p><tt><url></tt> is required; <tt>#<head></tt> is optional.</p></div>
731 refspecs, if you don't provide one on the command line.
738 </div></div>
743 </div></div>
744 </div>
748 section describes the output when pushing over the git protocol (either
749 locally or via ssh).</p></div>
751 representing the status of a single ref. Each line is of the form:</p></div>
754 <pre><tt> <flag> <summary> <from> -> <to> (<reason>)</tt></pre>
755 </div></div>
756 <div class="para"><p>If --porcelain is used, then each line of the output is of the form:</p></div>
759 <pre><tt> <flag> \t <from>:<to> \t <summary> (<reason>)</tt></pre>
760 </div></div>
762 <dt>
763 flag
764 </dt>
765 <dd>
766 <p>
767 A single character indicating the status of the ref. This is
770 date and did not need pushing (note that the status of up to
772 </p>
773 </dd>
774 <dt>
775 summary
776 </dt>
777 <dd>
778 <p>
779 For a successfully pushed ref, the summary shows the old and new
780 values of the ref in a form suitable for using as an argument to
783 failed update, more details are given for the failure.
785 ref at all (typically because it is not a fast forward). The
787 the update; this rejection is typically caused by a hook on the
789 remote end did not report the successful update of the ref
790 (perhaps because of a temporary error on the remote side, a
791 break in the network connection, or other transient error).
792 </p>
793 </dd>
794 <dt>
795 from
796 </dt>
797 <dd>
798 <p>
799 The name of the local ref being pushed, minus its
801 name of the local ref is omitted.
802 </p>
803 </dd>
804 <dt>
805 to
806 </dt>
807 <dd>
808 <p>
809 The name of the remote ref being updated, minus its
811 </p>
812 </dd>
813 <dt>
814 reason
815 </dt>
816 <dd>
817 <p>
818 A human-readable explanation. In the case of successfully pushed
819 refs, no explanation is needed. For a failed ref, the reason for
820 failure is described.
821 </p>
822 </dd>
823 </dl></div>
824 </div>
828 point at commit A to point at another commit B, it is called a
829 fast-forward update if and only if B is a descendant of A.</p></div>
831 commit A built on top of is a subset of the commits the new commit B
832 builds on top of. Hence, it does not lose any history.</p></div>
834 suppose you and somebody else started at the same commit X, and you built
835 a history leading to commit B while the other person built a history
836 leading to commit A. The history looks like this:</p></div>
839 <pre><tt>
840 B
841 /
842 ---X---A
843 </tt></pre>
844 </div></div>
846 back to the original repository you two obtained the original commit X.</p></div>
848 commit X to point at commit A. It is a fast-forward.</p></div>
850 now points at A) with commit B. This does _not_ fast-forward. If you did
851 so, the changes introduced by commit A will be lost, because everybody
852 will now start building on top of B.</p></div>
854 to prevent such loss of history.</p></div>
856 the other person (history from X to A), you would need to first fetch the
857 history from the repository, create a history that contains changes done
858 by both parties, and push the result back.</p></div>
860 the result. A "git pull" will create a merge commit C between commits A
861 and B.</p></div>
864 <pre><tt>
865 B---C
866 / /
867 ---X---A
868 </tt></pre>
869 </div></div>
871 push will be accepted.</p></div>
873 with "git pull --rebase", and push the result back. The rebase will
874 create a new commit D that builds the change between X and B on top of
875 A.</p></div>
878 <pre><tt>
879 B D
880 / /
881 ---X---A
882 </tt></pre>
883 </div></div>
885 accepted.</p></div>
887 rejection when you try to push, and it is possible even when you are
888 pushing into a repository nobody else pushes into. After you push commit
889 A yourself (in the first picture in this section), replace it with "git
890 commit --amend" to produce commit B, and you try to push it out, because
891 forgot that you have pushed A out already. In such a case, and only if
892 you are certain that nobody in the meantime fetched your earlier commit A
893 (and started building on top of it), you can run "git push --force" to
894 overwrite it. In other words, "git push --force" is a method reserved for
895 a case where you do mean to lose history.</p></div>
896 </div>
900 <dt>
901 git push
902 </dt>
903 <dd>
904 <p>
907 configured for the current branch).
908 </p>
909 </dd>
910 <dt>
911 git push origin
912 </dt>
913 <dd>
914 <p>
915 Without additional configuration, works like
917 </p>
918 <div class="para"><p>The default behavior of this command when no <refspec> is given can be
920 <div class="para"><p>For example, to default to pushing only the current branch to <tt>origin</tt>
922 the ones in the examples below) can be configured as the default for
924 </dd>
925 <dt>
926 git push origin :
927 </dt>
928 <dd>
929 <p>
932 description of "matching" branches.
933 </p>
934 </dd>
935 <dt>
936 git push origin master
937 </dt>
938 <dd>
939 <p>
944 created.
945 </p>
946 </dd>
947 <dt>
948 git push origin HEAD
949 </dt>
950 <dd>
951 <p>
952 A handy way to push the current branch to the same name on the
953 remote.
954 </p>
955 </dd>
956 <dt>
957 git push origin master:satellite/master dev:satellite/dev
958 </dt>
959 <dd>
960 <p>
965 </p>
966 </dd>
967 <dt>
968 git push origin HEAD:master
969 </dt>
970 <dd>
971 <p>
974 branch without thinking about its local name.
975 </p>
976 </dd>
977 <dt>
978 git push origin master:refs/heads/experimental
979 </dt>
980 <dd>
981 <p>
984 needed to create a new branch or tag in the remote repository when
985 the local name and the remote name are different; otherwise,
986 the ref name on its own will work.
987 </p>
988 </dd>
989 <dt>
990 git push origin :experimental
991 </dt>
992 <dd>
993 <p>
996 </p>
997 </dd>
998 <dt>
999 git push origin +dev:master
1000 </dt>
1001 <dd>
1002 <p>
1003 Update the origin repository's master branch with the dev branch,
1004 allowing non-fast forward updates. <strong>This can leave unreferenced
1005 commits dangling in the origin repository.</strong> Consider the
1006 following situation, where a fast forward is not possible:
1007 </p>
1010 <pre><tt> o---o---o---A---B origin/master
1011 \
1012 X---Y---Z dev</tt></pre>
1013 </div></div>
1017 <pre><tt> A---B (unnamed branch)
1018 /
1019 o---o---o---X---Y---Z master</tt></pre>
1020 </div></div>
1022 and so would be unreachable. As such, these commits would be removed by
1024 </dd>
1025 </dl></div>
1026 </div>
1031 </div>
1034 <div class="para"><p>Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.</p></div>
1035 </div>
1039 </div>
1043 </div>
1044 </div>
1045 </body>
1046 </html>