1 <?xml version=
"1.0" encoding=
"UTF-8"?>
2 <!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.1//EN"
3 "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
4 <html xmlns=
"http://www.w3.org/1999/xhtml" xml:
lang=
"en">
6 <meta http-equiv=
"Content-Type" content=
"application/xhtml+xml; charset=UTF-8" />
7 <meta name=
"generator" content=
"AsciiDoc 10.2.0" />
8 <title>gitglossary(
7)
</title>
9 <style type=
"text/css">
10 /* Shared CSS for AsciiDoc xhtml11 and html5 backends */
14 font-family: Georgia,serif;
18 h1, h2, h3, h4, h5, h6,
19 div.title, caption.title,
20 thead, p.table.header,
22 #author, #revnumber, #revdate, #revremark,
24 font-family: Arial,Helvetica,sans-serif;
28 margin:
1em
5%
1em
5%;
33 text-decoration: underline;
49 h1, h2, h3, h4, h5, h6 {
57 border-bottom:
2px solid silver;
77 border:
1px solid silver;
88 ul
> li { color: #aaa; }
89 ul
> li
> * { color: black; }
91 .monospaced, code, pre {
92 font-family:
"Courier New", Courier, monospace;
99 white-space: pre-wrap;
109 #revnumber, #revdate, #revremark {
114 border-top:
2px solid silver;
120 padding-bottom:
0.5em;
124 padding-bottom:
0.5em;
129 margin-bottom:
1.5em;
131 div.imageblock, div.exampleblock, div.verseblock,
132 div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
133 div.admonitionblock {
135 margin-bottom:
1.5em;
137 div.admonitionblock {
139 margin-bottom:
2.0em;
144 div.content { /* Block element content. */
148 /* Block element titles. */
149 div.title, caption.title {
154 margin-bottom:
0.5em;
160 td div.title:first-child {
163 div.content div.title:first-child {
166 div.content + div.title {
170 div.sidebarblock
> div.content {
172 border:
1px solid #dddddd;
173 border-left:
4px solid #f0f0f0;
177 div.listingblock
> div.content {
178 border:
1px solid #dddddd;
179 border-left:
5px solid #f0f0f0;
184 div.quoteblock, div.verseblock {
188 border-left:
5px solid #f0f0f0;
192 div.quoteblock
> div.attribution {
197 div.verseblock
> pre.content {
198 font-family: inherit;
201 div.verseblock
> div.attribution {
205 /* DEPRECATED: Pre version
8.2.7 verse style literal block. */
206 div.verseblock + div.attribution {
210 div.admonitionblock .icon {
214 text-decoration: underline;
216 padding-right:
0.5em;
218 div.admonitionblock td.content {
220 border-left:
3px solid #dddddd;
223 div.exampleblock
> div.content {
224 border-left:
3px solid #dddddd;
228 div.imageblock div.content { padding-left:
0; }
229 span.image img { border-style: none; vertical-align: text-bottom; }
230 a.image:visited { color: white; }
234 margin-bottom:
0.8em;
247 list-style-position: outside;
250 list-style-type: decimal;
253 list-style-type: lower-alpha;
256 list-style-type: upper-alpha;
259 list-style-type: lower-roman;
262 list-style-type: upper-roman;
265 div.compact ul, div.compact ol,
266 div.compact p, div.compact p,
267 div.compact div, div.compact div {
269 margin-bottom:
0.1em;
281 margin-bottom:
0.8em;
284 padding-bottom:
15px;
286 dt.hdlist1.strong, td.hdlist1.strong {
292 padding-right:
0.8em;
298 div.hdlist.compact tr {
307 .footnote, .footnoteref {
311 span.footnote, span.footnoteref {
312 vertical-align: super;
316 margin:
20px
0 20px
0;
320 #footnotes div.footnote {
326 border-top:
1px solid silver;
335 padding-right:
0.5em;
336 padding-bottom:
0.3em;
344 #footer-badges { display: none; }
348 margin-bottom:
2.5em;
356 margin-bottom:
0.1em;
359 div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
376 span.aqua { color: aqua; }
377 span.black { color: black; }
378 span.blue { color: blue; }
379 span.fuchsia { color: fuchsia; }
380 span.gray { color: gray; }
381 span.green { color: green; }
382 span.lime { color: lime; }
383 span.maroon { color: maroon; }
384 span.navy { color: navy; }
385 span.olive { color: olive; }
386 span.purple { color: purple; }
387 span.red { color: red; }
388 span.silver { color: silver; }
389 span.teal { color: teal; }
390 span.white { color: white; }
391 span.yellow { color: yellow; }
393 span.aqua-background { background: aqua; }
394 span.black-background { background: black; }
395 span.blue-background { background: blue; }
396 span.fuchsia-background { background: fuchsia; }
397 span.gray-background { background: gray; }
398 span.green-background { background: green; }
399 span.lime-background { background: lime; }
400 span.maroon-background { background: maroon; }
401 span.navy-background { background: navy; }
402 span.olive-background { background: olive; }
403 span.purple-background { background: purple; }
404 span.red-background { background: red; }
405 span.silver-background { background: silver; }
406 span.teal-background { background: teal; }
407 span.white-background { background: white; }
408 span.yellow-background { background: yellow; }
410 span.big { font-size:
2em; }
411 span.small { font-size:
0.6em; }
413 span.underline { text-decoration: underline; }
414 span.overline { text-decoration: overline; }
415 span.line-through { text-decoration: line-through; }
417 div.unbreakable { page-break-inside: avoid; }
427 margin-bottom:
1.5em;
429 div.tableblock
> table {
430 border:
3px solid #
527bbd;
432 thead, p.table.header {
439 /* Because the table frame attribute is overridden by CSS in most browsers. */
440 div.tableblock
> table[
frame=
"void"] {
443 div.tableblock
> table[
frame=
"hsides"] {
444 border-left-style: none;
445 border-right-style: none;
447 div.tableblock
> table[
frame=
"vsides"] {
448 border-top-style: none;
449 border-bottom-style: none;
460 margin-bottom:
1.5em;
462 thead, p.tableblock.header {
473 border-color: #
527bbd;
474 border-collapse: collapse;
476 th.tableblock, td.tableblock {
480 border-color: #
527bbd;
483 table.tableblock.frame-topbot {
484 border-left-style: hidden;
485 border-right-style: hidden;
487 table.tableblock.frame-sides {
488 border-top-style: hidden;
489 border-bottom-style: hidden;
491 table.tableblock.frame-none {
492 border-style: hidden;
495 th.tableblock.halign-left, td.tableblock.halign-left {
498 th.tableblock.halign-center, td.tableblock.halign-center {
501 th.tableblock.halign-right, td.tableblock.halign-right {
505 th.tableblock.valign-top, td.tableblock.valign-top {
508 th.tableblock.valign-middle, td.tableblock.valign-middle {
509 vertical-align: middle;
511 th.tableblock.valign-bottom, td.tableblock.valign-bottom {
512 vertical-align: bottom;
523 padding-bottom:
0.5em;
524 border-top:
2px solid silver;
525 border-bottom:
2px solid silver;
530 body.manpage div.sectionbody {
535 body.manpage div#toc { display: none; }
540 <script type=
"text/javascript">
542 var asciidoc = { // Namespace.
544 /////////////////////////////////////////////////////////////////////
545 // Table Of Contents generator
546 /////////////////////////////////////////////////////////////////////
548 /* Author: Mihai Bazon, September
2002
549 * http://students.infoiasi.ro/~mishoo
551 * Table Of Content generator
554 * Feel free to use this script under the terms of the GNU General Public
555 * License, as long as you do not remove or alter this notice.
558 /* modified by Troy D. Hanson, September
2006. License: GPL */
559 /* modified by Stuart Rackham,
2006,
2009. License: GPL */
562 toc: function (toclevels) {
564 function getText(el) {
566 for (var i = el.firstChild; i != null; i = i.nextSibling) {
567 if (i.nodeType ==
3 /* Node.TEXT_NODE */) // IE doesn't speak constants.
569 else if (i.firstChild != null)
575 function TocEntry(el, text, toclevel) {
578 this.toclevel = toclevel;
581 function tocEntries(el, toclevels) {
582 var result = new Array;
583 var re = new RegExp('[hH]([
1-'+(toclevels+
1)+'])');
584 // Function that scans the DOM tree for header elements (the DOM2
585 // nodeIterator API would be a better technique but not supported by all
587 var iterate = function (el) {
588 for (var i = el.firstChild; i != null; i = i.nextSibling) {
589 if (i.nodeType ==
1 /* Node.ELEMENT_NODE */) {
590 var mo = re.exec(i.tagName);
591 if (mo && (i.getAttribute(
"class") || i.getAttribute(
"className")) !=
"float") {
592 result[result.length] = new TocEntry(i, getText(i), mo[
1]-
1);
602 var toc = document.getElementById(
"toc");
607 // Delete existing TOC entries in case we're reloading the TOC.
608 var tocEntriesToRemove = [];
610 for (i =
0; i < toc.childNodes.length; i++) {
611 var entry = toc.childNodes[i];
612 if (entry.nodeName.toLowerCase() == 'div'
613 && entry.getAttribute(
"class")
614 && entry.getAttribute(
"class").match(/^toclevel/))
615 tocEntriesToRemove.push(entry);
617 for (i =
0; i < tocEntriesToRemove.length; i++) {
618 toc.removeChild(tocEntriesToRemove[i]);
621 // Rebuild TOC entries.
622 var entries = tocEntries(document.getElementById(
"content"), toclevels);
623 for (var i =
0; i < entries.length; ++i) {
624 var entry = entries[i];
625 if (entry.element.id ==
"")
626 entry.element.id =
"_toc_" + i;
627 var a = document.createElement(
"a");
628 a.href =
"#" + entry.element.id;
629 a.appendChild(document.createTextNode(entry.text));
630 var div = document.createElement(
"div");
632 div.className =
"toclevel" + entry.toclevel;
633 toc.appendChild(div);
635 if (entries.length ==
0)
636 toc.parentNode.removeChild(toc);
640 /////////////////////////////////////////////////////////////////////
641 // Footnotes generator
642 /////////////////////////////////////////////////////////////////////
644 /* Based on footnote generation code from:
645 * http://www.brandspankingnew.net/archive/
2005/
07/format_footnote.html
648 footnotes: function () {
649 // Delete existing footnote entries in case we're reloading the footnodes.
651 var noteholder = document.getElementById(
"footnotes");
655 var entriesToRemove = [];
656 for (i =
0; i < noteholder.childNodes.length; i++) {
657 var entry = noteholder.childNodes[i];
658 if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute(
"class") ==
"footnote")
659 entriesToRemove.push(entry);
661 for (i =
0; i < entriesToRemove.length; i++) {
662 noteholder.removeChild(entriesToRemove[i]);
665 // Rebuild footnote entries.
666 var cont = document.getElementById(
"content");
667 var spans = cont.getElementsByTagName(
"span");
670 for (i=
0; i
<spans.length; i++) {
671 if (spans[i].className ==
"footnote") {
673 var note = spans[i].getAttribute(
"data-note");
675 // Use [\s\S] in place of . so multi-line matches work.
676 // Because JavaScript has no s (dotall) regex flag.
677 note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[
1];
679 "[<a id='_footnoteref_" + n +
"' href='#_footnote_" + n +
680 "' title='View footnote' class='footnote'>" + n +
"</a>]";
681 spans[i].setAttribute(
"data-note", note);
683 noteholder.innerHTML +=
684 "<div class='footnote' id='_footnote_" + n +
"'>" +
685 "<a href='#_footnoteref_" + n +
"' title='Return to text'>" +
686 n +
"</a>. " + note +
"</div>";
687 var id =spans[i].getAttribute(
"id");
688 if (id != null) refs[
"#"+id] = n;
692 noteholder.parentNode.removeChild(noteholder);
694 // Process footnoterefs.
695 for (i=
0; i
<spans.length; i++) {
696 if (spans[i].className ==
"footnoteref") {
697 var href = spans[i].getElementsByTagName(
"a")[
0].getAttribute(
"href");
698 href = href.match(/#.*/)[
0]; // Because IE return full URL.
701 "[<a href='#_footnote_" + n +
702 "' title='View footnote' class='footnote'>" + n +
"</a>]";
708 install: function(toclevels) {
711 function reinstall() {
712 asciidoc.footnotes();
714 asciidoc.toc(toclevels);
718 function reinstallAndRemoveTimer() {
719 clearInterval(timerId);
723 timerId = setInterval(reinstall,
500);
724 if (document.addEventListener)
725 document.addEventListener(
"DOMContentLoaded", reinstallAndRemoveTimer, false);
727 window.onload = reinstallAndRemoveTimer;
735 <body class=
"manpage">
738 gitglossary(
7) Manual Page
741 <div class=
"sectionbody">
749 <h2 id=
"_synopsis">SYNOPSIS
</h2>
750 <div class=
"sectionbody">
751 <div class=
"paragraph"><p>*
</p></div>
755 <h2 id=
"_description">DESCRIPTION
</h2>
756 <div class=
"sectionbody">
757 <div class=
"dlist"><dl>
759 <a id=
"def_alternate_object_database"></a>alternate object database
763 Via the alternates mechanism, a
<a href=
"#def_repository">repository
</a>
764 can inherit part of its
<a href=
"#def_object_database">object database
</a>
765 from another object database, which is called an
"alternate".
769 <a id=
"def_bare_repository"></a>bare repository
773 A bare repository is normally an appropriately
774 named
<a href=
"#def_directory">directory
</a> with a
<code>.git
</code> suffix that does not
775 have a locally checked-out copy of any of the files under
776 revision control. That is, all of the Git
777 administrative and control files that would normally be present in the
778 hidden
<code>.git
</code> sub-directory are directly present in the
779 <code>repository.git
</code> directory instead,
780 and no other files are present and checked out. Usually publishers of
781 public repositories make bare repositories available.
785 <a id=
"def_blob_object"></a>blob object
789 Untyped
<a href=
"#def_object">object
</a>, e.g. the contents of a file.
793 <a id=
"def_branch"></a>branch
797 A
"branch" is a line of development. The most recent
798 <a href=
"#def_commit">commit
</a> on a branch is referred to as the tip of
799 that branch. The tip of the branch is
<a href=
"#def_ref">referenced
</a> by a branch
800 <a href=
"#def_head">head
</a>, which moves forward as additional development
801 is done on the branch. A single Git
802 <a href=
"#def_repository">repository
</a> can track an arbitrary number of
803 branches, but your
<a href=
"#def_working_tree">working tree
</a> is
804 associated with just one of them (the
"current" or
"checked out"
805 branch), and
<a href=
"#def_HEAD">HEAD
</a> points to that branch.
809 <a id=
"def_cache"></a>cache
813 Obsolete for:
<a href=
"#def_index">index
</a>.
817 <a id=
"def_chain"></a>chain
821 A list of objects, where each
<a href=
"#def_object">object
</a> in the list contains
822 a reference to its successor (for example, the successor of a
823 <a href=
"#def_commit">commit
</a> could be one of its
<a href=
"#def_parent">parents
</a>).
827 <a id=
"def_changeset"></a>changeset
831 BitKeeper/cvsps speak for
"<a href="#def_commit
">commit</a>". Since Git does not
832 store changes, but states, it really does not make sense to use the term
833 "changesets" with Git.
837 <a id=
"def_checkout"></a>checkout
841 The action of updating all or part of the
842 <a href=
"#def_working_tree">working tree
</a> with a
<a href=
"#def_tree_object">tree object
</a>
843 or
<a href=
"#def_blob_object">blob
</a> from the
844 <a href=
"#def_object_database">object database
</a>, and updating the
845 <a href=
"#def_index">index
</a> and
<a href=
"#def_HEAD">HEAD
</a> if the whole working tree has
846 been pointed at a new
<a href=
"#def_branch">branch
</a>.
850 <a id=
"def_cherry-picking"></a>cherry-picking
854 In
<a href=
"#def_SCM">SCM
</a> jargon,
"cherry pick" means to choose a subset of
855 changes out of a series of changes (typically commits) and record them
856 as a new series of changes on top of a different codebase. In Git, this is
857 performed by the
"git cherry-pick" command to extract the change introduced
858 by an existing
<a href=
"#def_commit">commit
</a> and to record it based on the tip
859 of the current
<a href=
"#def_branch">branch
</a> as a new commit.
863 <a id=
"def_clean"></a>clean
867 A
<a href=
"#def_working_tree">working tree
</a> is clean, if it
868 corresponds to the
<a href=
"#def_revision">revision
</a> referenced by the current
869 <a href=
"#def_head">head
</a>. Also see
"<a href="#def_dirty
">dirty</a>".
873 <a id=
"def_commit"></a>commit
877 As a noun: A single point in the
878 Git history; the entire history of a project is represented as a
879 set of interrelated commits. The word
"commit" is often
880 used by Git in the same places other revision control systems
881 use the words
"revision" or
"version". Also used as a short
882 hand for
<a href=
"#def_commit_object">commit object
</a>.
884 <div class=
"paragraph"><p>As a verb: The action of storing a new snapshot of the project
’s
885 state in the Git history, by creating a new commit representing the current
886 state of the
<a href=
"#def_index">index
</a> and advancing
<a href=
"#def_HEAD">HEAD
</a>
887 to point at the new commit.
</p></div>
890 <a id=
"def_commit_graph_general"></a>commit graph concept, representations and usage
894 A synonym for the
<a href=
"#def_DAG">DAG
</a> structure formed by the commits
895 in the object database,
<a href=
"#def_ref">referenced
</a> by branch tips,
896 using their
<a href=
"#def_chain">chain
</a> of linked commits.
897 This structure is the definitive commit graph. The
898 graph can be represented in other ways, e.g. the
899 <a href=
"#def_commit_graph_file">"commit-graph" file
</a>.
903 <a id=
"def_commit_graph_file"></a>commit-graph file
907 The
"commit-graph" (normally hyphenated) file is a supplemental
908 representation of the
<a href=
"#def_commit_graph_general">commit graph
</a>
909 which accelerates commit graph walks. The
"commit-graph" file is
910 stored either in the .git/objects/info directory or in the info
911 directory of an alternate object database.
915 <a id=
"def_commit_object"></a>commit object
919 An
<a href=
"#def_object">object
</a> which contains the information about a
920 particular
<a href=
"#def_revision">revision
</a>, such as
<a href=
"#def_parent">parents
</a>, committer,
921 author, date and the
<a href=
"#def_tree_object">tree object
</a> which corresponds
922 to the top
<a href=
"#def_directory">directory
</a> of the stored
927 <a id=
"def_commit-ish"></a>commit-ish (also committish)
931 A
<a href=
"#def_commit_object">commit object
</a> or an
932 <a href=
"#def_object">object
</a> that can be recursively dereferenced to
934 The following are all commit-ishes:
936 a
<a href=
"#def_tag_object">tag object
</a> that points to a commit
938 a tag object that points to a tag object that points to a
944 <a id=
"def_core_git"></a>core Git
948 Fundamental data structures and utilities of Git. Exposes only limited
949 source code management tools.
953 <a id=
"def_DAG"></a>DAG
957 Directed acyclic graph. The
<a href=
"#def_commit_object">commit objects
</a> form a
958 directed acyclic graph, because they have parents (directed), and the
959 graph of commit objects is acyclic (there is no
<a href=
"#def_chain">chain
</a>
960 which begins and ends with the same
<a href=
"#def_object">object
</a>).
964 <a id=
"def_dangling_object"></a>dangling object
968 An
<a href=
"#def_unreachable_object">unreachable object
</a> which is not
969 <a href=
"#def_reachable">reachable
</a> even from other unreachable objects; a
970 dangling object has no references to it from any
971 reference or
<a href=
"#def_object">object
</a> in the
<a href=
"#def_repository">repository
</a>.
975 <a id=
"def_detached_HEAD"></a>detached HEAD
979 Normally the
<a href=
"#def_HEAD">HEAD
</a> stores the name of a
980 <a href=
"#def_branch">branch
</a>, and commands that operate on the
981 history HEAD represents operate on the history leading to the
982 tip of the branch the HEAD points at. However, Git also
983 allows you to
<a href=
"#def_checkout">check out
</a> an arbitrary
984 <a href=
"#def_commit">commit
</a> that isn
’t necessarily the tip of any
985 particular branch. The HEAD in such a state is called
988 <div class=
"paragraph"><p>Note that commands that operate on the history of the current branch
989 (e.g.
<code>git commit
</code> to build a new history on top of it) still work
990 while the HEAD is detached. They update the HEAD to point at the tip
991 of the updated history without affecting any branch. Commands that
992 update or inquire information
<em>about
</em> the current branch (e.g.
<code>git
993 branch --set-upstream-to
</code> that sets what remote-tracking branch the
994 current branch integrates with) obviously do not work, as there is no
995 (real) current branch to ask about in this state.
</p></div>
998 <a id=
"def_directory"></a>directory
1002 The list you get with
"ls" :-)
1005 <dt class=
"hdlist1">
1006 <a id=
"def_dirty"></a>dirty
1010 A
<a href=
"#def_working_tree">working tree
</a> is said to be
"dirty" if
1011 it contains modifications which have not been
<a href=
"#def_commit">committed
</a> to the current
1012 <a href=
"#def_branch">branch
</a>.
1015 <dt class=
"hdlist1">
1016 <a id=
"def_evil_merge"></a>evil merge
1020 An evil merge is a
<a href=
"#def_merge">merge
</a> that introduces changes that
1021 do not appear in any
<a href=
"#def_parent">parent
</a>.
1024 <dt class=
"hdlist1">
1025 <a id=
"def_fast_forward"></a>fast-forward
1029 A fast-forward is a special type of
<a href=
"#def_merge">merge
</a> where you have a
1030 <a href=
"#def_revision">revision
</a> and you are
"merging" another
1031 <a href=
"#def_branch">branch
</a>'s changes that happen to be a descendant of what
1032 you have. In such a case, you do not make a new
<a href=
"#def_merge">merge
</a>
1033 <a href=
"#def_commit">commit
</a> but instead just update your branch to point at the same
1034 revision as the branch you are merging. This will happen frequently on a
1035 <a href=
"#def_remote_tracking_branch">remote-tracking branch
</a> of a remote
1036 <a href=
"#def_repository">repository
</a>.
1039 <dt class=
"hdlist1">
1040 <a id=
"def_fetch"></a>fetch
1044 Fetching a
<a href=
"#def_branch">branch
</a> means to get the
1045 branch
’s
<a href=
"#def_head_ref">head ref
</a> from a remote
1046 <a href=
"#def_repository">repository
</a>, to find out which objects are
1047 missing from the local
<a href=
"#def_object_database">object database
</a>,
1048 and to get them, too. See also
<a href=
"git-fetch.html">git-fetch(
1)
</a>.
1051 <dt class=
"hdlist1">
1052 <a id=
"def_file_system"></a>file system
1056 Linus Torvalds originally designed Git to be a user space file system,
1057 i.e. the infrastructure to hold files and directories. That ensured the
1058 efficiency and speed of Git.
1061 <dt class=
"hdlist1">
1062 <a id=
"def_git_archive"></a>Git archive
1066 Synonym for
<a href=
"#def_repository">repository
</a> (for arch people).
1069 <dt class=
"hdlist1">
1070 <a id=
"def_gitfile"></a>gitfile
1074 A plain file
<code>.git
</code> at the root of a working tree that
1075 points at the directory that is the real repository.
1078 <dt class=
"hdlist1">
1079 <a id=
"def_grafts"></a>grafts
1083 Grafts enables two otherwise different lines of development to be joined
1084 together by recording fake ancestry information for commits. This way
1085 you can make Git pretend the set of
<a href=
"#def_parent">parents
</a> a
<a href=
"#def_commit">commit
</a> has
1086 is different from what was recorded when the commit was
1087 created. Configured via the
<code>.git/info/grafts
</code> file.
1089 <div class=
"paragraph"><p>Note that the grafts mechanism is outdated and can lead to problems
1090 transferring objects between repositories; see
<a href=
"git-replace.html">git-replace(
1)
</a>
1091 for a more flexible and robust system to do the same thing.
</p></div>
1093 <dt class=
"hdlist1">
1094 <a id=
"def_hash"></a>hash
1098 In Git
’s context, synonym for
<a href=
"#def_object_name">object name
</a>.
1101 <dt class=
"hdlist1">
1102 <a id=
"def_head"></a>head
1106 A
<a href=
"#def_ref">named reference
</a> to the
<a href=
"#def_commit">commit
</a> at the tip of a
1107 <a href=
"#def_branch">branch
</a>. Heads are stored in a file in
1108 <code>$GIT_DIR/refs/heads/
</code> directory, except when using packed refs. (See
1109 <a href=
"git-pack-refs.html">git-pack-refs(
1)
</a>.)
1112 <dt class=
"hdlist1">
1113 <a id=
"def_HEAD"></a>HEAD
1117 The current
<a href=
"#def_branch">branch
</a>. In more detail: Your
<a href=
"#def_working_tree">working tree
</a> is normally derived from the state of the tree
1118 referred to by HEAD. HEAD is a reference to one of the
1119 <a href=
"#def_head">heads
</a> in your repository, except when using a
1120 <a href=
"#def_detached_HEAD">detached HEAD
</a>, in which case it directly
1121 references an arbitrary commit.
1124 <dt class=
"hdlist1">
1125 <a id=
"def_head_ref"></a>head ref
1129 A synonym for
<a href=
"#def_head">head
</a>.
1132 <dt class=
"hdlist1">
1133 <a id=
"def_hook"></a>hook
1137 During the normal execution of several Git commands, call-outs are made
1138 to optional scripts that allow a developer to add functionality or
1139 checking. Typically, the hooks allow for a command to be pre-verified
1140 and potentially aborted, and allow for a post-notification after the
1141 operation is done. The hook scripts are found in the
1142 <code>$GIT_DIR/hooks/
</code> directory, and are enabled by simply
1143 removing the
<code>.sample
</code> suffix from the filename. In earlier versions
1144 of Git you had to make them executable.
1147 <dt class=
"hdlist1">
1148 <a id=
"def_index"></a>index
1152 A collection of files with stat information, whose contents are stored
1153 as objects. The index is a stored version of your
1154 <a href=
"#def_working_tree">working tree
</a>. Truth be told, it can also contain a second, and even
1155 a third version of a working tree, which are used
1156 when
<a href=
"#def_merge">merging
</a>.
1159 <dt class=
"hdlist1">
1160 <a id=
"def_index_entry"></a>index entry
1164 The information regarding a particular file, stored in the
1165 <a href=
"#def_index">index
</a>. An index entry can be unmerged, if a
1166 <a href=
"#def_merge">merge
</a> was started, but not yet finished (i.e. if
1167 the index contains multiple versions of that file).
1170 <dt class=
"hdlist1">
1171 <a id=
"def_master"></a>master
1175 The default development
<a href=
"#def_branch">branch
</a>. Whenever you
1176 create a Git
<a href=
"#def_repository">repository
</a>, a branch named
1177 "master" is created, and becomes the active branch. In most
1178 cases, this contains the local development, though that is
1179 purely by convention and is not required.
1182 <dt class=
"hdlist1">
1183 <a id=
"def_merge"></a>merge
1187 As a verb: To bring the contents of another
1188 <a href=
"#def_branch">branch
</a> (possibly from an external
1189 <a href=
"#def_repository">repository
</a>) into the current branch. In the
1190 case where the merged-in branch is from a different repository,
1191 this is done by first
<a href=
"#def_fetch">fetching
</a> the remote branch
1192 and then merging the result into the current branch. This
1193 combination of fetch and merge operations is called a
1194 <a href=
"#def_pull">pull
</a>. Merging is performed by an automatic process
1195 that identifies changes made since the branches diverged, and
1196 then applies all those changes together. In cases where changes
1197 conflict, manual intervention may be required to complete the
1200 <div class=
"paragraph"><p>As a noun: unless it is a
<a href=
"#def_fast_forward">fast-forward
</a>, a
1201 successful merge results in the creation of a new
<a href=
"#def_commit">commit
</a>
1202 representing the result of the merge, and having as
1203 <a href=
"#def_parent">parents
</a> the tips of the merged
<a href=
"#def_branch">branches
</a>.
1204 This commit is referred to as a
"merge commit", or sometimes just a
1207 <dt class=
"hdlist1">
1208 <a id=
"def_object"></a>object
1212 The unit of storage in Git. It is uniquely identified by the
1213 <a href=
"#def_SHA1">SHA-
1</a> of its contents. Consequently, an
1214 object cannot be changed.
1217 <dt class=
"hdlist1">
1218 <a id=
"def_object_database"></a>object database
1222 Stores a set of
"objects", and an individual
<a href=
"#def_object">object
</a> is
1223 identified by its
<a href=
"#def_object_name">object name
</a>. The objects usually
1224 live in
<code>$GIT_DIR/objects/
</code>.
1227 <dt class=
"hdlist1">
1228 <a id=
"def_object_identifier"></a>object identifier (oid)
1232 Synonym for
<a href=
"#def_object_name">object name
</a>.
1235 <dt class=
"hdlist1">
1236 <a id=
"def_object_name"></a>object name
1240 The unique identifier of an
<a href=
"#def_object">object
</a>. The
1241 object name is usually represented by a
40 character
1242 hexadecimal string. Also colloquially called
<a href=
"#def_SHA1">SHA-
1</a>.
1245 <dt class=
"hdlist1">
1246 <a id=
"def_object_type"></a>object type
1250 One of the identifiers
"<a href="#def_commit_object
">commit</a>",
1251 "<a href="#def_tree_object
">tree</a>",
"<a href="#def_tag_object
">tag</a>" or
1252 "<a href="#def_blob_object
">blob</a>" describing the type of an
1253 <a href=
"#def_object">object
</a>.
1256 <dt class=
"hdlist1">
1257 <a id=
"def_octopus"></a>octopus
1261 To
<a href=
"#def_merge">merge
</a> more than two
<a href=
"#def_branch">branches
</a>.
1264 <dt class=
"hdlist1">
1265 <a id=
"def_origin"></a>origin
1269 The default upstream
<a href=
"#def_repository">repository
</a>. Most projects have
1270 at least one upstream project which they track. By default
1271 <em>origin
</em> is used for that purpose. New upstream updates
1272 will be fetched into
<a href=
"#def_remote_tracking_branch">remote-tracking branches
</a> named
1273 origin/name-of-upstream-branch, which you can see using
1274 <code>git branch -r
</code>.
1277 <dt class=
"hdlist1">
1278 <a id=
"def_overlay"></a>overlay
1282 Only update and add files to the working directory, but don
’t
1283 delete them, similar to how
<em>cp -R
</em> would update the contents
1284 in the destination directory. This is the default mode in a
1285 <a href=
"#def_checkout">checkout
</a> when checking out files from the
1286 <a href=
"#def_index">index
</a> or a
<a href=
"#def_tree-ish">tree-ish
</a>. In
1287 contrast, no-overlay mode also deletes tracked files not
1288 present in the source, similar to
<em>rsync --delete
</em>.
1291 <dt class=
"hdlist1">
1292 <a id=
"def_pack"></a>pack
1296 A set of objects which have been compressed into one file (to save space
1297 or to transmit them efficiently).
1300 <dt class=
"hdlist1">
1301 <a id=
"def_pack_index"></a>pack index
1305 The list of identifiers, and other information, of the objects in a
1306 <a href=
"#def_pack">pack
</a>, to assist in efficiently accessing the contents of a
1310 <dt class=
"hdlist1">
1311 <a id=
"def_pathspec"></a>pathspec
1315 Pattern used to limit paths in Git commands.
1317 <div class=
"paragraph"><p>Pathspecs are used on the command line of
"git ls-files",
"git
1318 ls-tree",
"git add",
"git grep",
"git diff",
"git checkout",
1319 and many other commands to
1320 limit the scope of operations to some subset of the tree or
1321 working tree. See the documentation of each command for whether
1322 paths are relative to the current directory or toplevel. The
1323 pathspec syntax is as follows:
</p></div>
1324 <div class=
"openblock">
1325 <div class=
"content">
1326 <div class=
"ulist"><ul>
1329 any path matches itself
1334 the pathspec up to the last slash represents a
1335 directory prefix. The scope of that pathspec is
1336 limited to that subtree.
1341 the rest of the pathspec is a pattern for the remainder
1342 of the pathname. Paths relative to the directory
1343 prefix will be matched against that pattern using fnmatch(
3);
1344 in particular,
<em>*
</em> and
<em>?
</em> <em>can
</em> match directory separators.
1349 <div class=
"paragraph"><p>For example, Documentation/*.jpg will match all .jpg files
1350 in the Documentation subtree,
1351 including Documentation/chapter_1/figure_1.jpg.
</p></div>
1352 <div class=
"paragraph"><p>A pathspec that begins with a colon
<code>:
</code> has special meaning. In the
1353 short form, the leading colon
<code>:
</code> is followed by zero or more
"magic
1354 signature" letters (which optionally is terminated by another colon
<code>:
</code>),
1355 and the remainder is the pattern to match against the path.
1356 The
"magic signature" consists of ASCII symbols that are neither
1357 alphanumeric, glob, regex special characters nor colon.
1358 The optional colon that terminates the
"magic signature" can be
1359 omitted if the pattern begins with a character that does not belong to
1360 "magic signature" symbol set and is not a colon.
</p></div>
1361 <div class=
"paragraph"><p>In the long form, the leading colon
<code>:
</code> is followed by an open
1362 parenthesis
<code>(
</code>, a comma-separated list of zero or more
"magic words",
1363 and a close parentheses
<code>)
</code>, and the remainder is the pattern to match
1364 against the path.
</p></div>
1365 <div class=
"paragraph"><p>A pathspec with only a colon means
"there is no pathspec". This form
1366 should not be combined with other pathspec.
</p></div>
1367 <div class=
"openblock">
1368 <div class=
"content">
1369 <div class=
"dlist"><dl>
1370 <dt class=
"hdlist1">
1375 The magic word
<code>top
</code> (magic signature:
<code>/
</code>) makes the pattern
1376 match from the root of the working tree, even when you are
1377 running the command from inside a subdirectory.
1380 <dt class=
"hdlist1">
1385 Wildcards in the pattern such as
<code>*
</code> or
<code>?
</code> are treated
1386 as literal characters.
1389 <dt class=
"hdlist1">
1394 Case insensitive match.
1397 <dt class=
"hdlist1">
1402 Git treats the pattern as a shell glob suitable for
1403 consumption by fnmatch(
3) with the FNM_PATHNAME flag:
1404 wildcards in the pattern will not match a / in the pathname.
1405 For example,
"Documentation/*.html" matches
1406 "Documentation/git.html" but not
"Documentation/ppc/ppc.html"
1407 or
"tools/perf/Documentation/perf.html".
1409 <div class=
"paragraph"><p>Two consecutive asterisks (
"<code>**</code>") in patterns matched against
1410 full pathname may have special meaning:
</p></div>
1411 <div class=
"ulist"><ul>
1414 A leading
"<code>**</code>" followed by a slash means match in all
1415 directories. For example,
"<code>**/foo</code>" matches file or directory
1416 "<code>foo</code>" anywhere, the same as pattern
"<code>foo</code>".
"<code>**/foo/bar</code>"
1417 matches file or directory
"<code>bar</code>" anywhere that is directly
1418 under directory
"<code>foo</code>".
1423 A trailing
"<code>/**</code>" matches everything inside. For example,
1424 "<code>abc/**</code>" matches all files inside directory
"abc", relative
1425 to the location of the
<code>.gitignore
</code> file, with infinite depth.
1430 A slash followed by two consecutive asterisks then a slash
1431 matches zero or more directories. For example,
"<code>a/**/b</code>"
1432 matches
"<code>a/b</code>",
"<code>a/x/b</code>",
"<code>a/x/y/b</code>" and so on.
1437 Other consecutive asterisks are considered invalid.
1439 <div class=
"paragraph"><p>Glob magic is incompatible with literal magic.
</p></div>
1443 <dt class=
"hdlist1">
1448 After
<code>attr:
</code> comes a space separated list of
"attribute
1449 requirements", all of which must be met in order for the
1450 path to be considered a match; this is in addition to the
1451 usual non-magic pathspec pattern matching.
1452 See
<a href=
"gitattributes.html">gitattributes(
5)
</a>.
1454 <div class=
"paragraph"><p>Each of the attribute requirements for the path takes one of
1455 these forms:
</p></div>
1456 <div class=
"ulist"><ul>
1459 "<code>ATTR</code>" requires that the attribute
<code>ATTR
</code> be set.
1464 "<code>-ATTR</code>" requires that the attribute
<code>ATTR
</code> be unset.
1469 "<code>ATTR=VALUE</code>" requires that the attribute
<code>ATTR
</code> be
1470 set to the string
<code>VALUE
</code>.
1475 "<code>!ATTR</code>" requires that the attribute
<code>ATTR
</code> be
1478 <div class=
"paragraph"><p>Note that when matching against a tree object, attributes are still
1479 obtained from working tree, not from the given tree object.
</p></div>
1483 <dt class=
"hdlist1">
1488 After a path matches any non-exclude pathspec, it will be run
1489 through all exclude pathspecs (magic signature:
<code>!
</code> or its
1490 synonym
<code>^
</code>). If it matches, the path is ignored. When there
1491 is no non-exclude pathspec, the exclusion is applied to the
1492 result set as if invoked without any pathspec.
1498 <dt class=
"hdlist1">
1499 <a id=
"def_parent"></a>parent
1503 A
<a href=
"#def_commit_object">commit object
</a> contains a (possibly empty) list
1504 of the logical predecessor(s) in the line of development, i.e. its
1508 <dt class=
"hdlist1">
1509 <a id=
"def_pickaxe"></a>pickaxe
1513 The term
<a href=
"#def_pickaxe">pickaxe
</a> refers to an option to the diffcore
1514 routines that help select changes that add or delete a given text
1515 string. With the
<code>--pickaxe-all
</code> option, it can be used to view the full
1516 <a href=
"#def_changeset">changeset
</a> that introduced or removed, say, a
1517 particular line of text. See
<a href=
"git-diff.html">git-diff(
1)
</a>.
1520 <dt class=
"hdlist1">
1521 <a id=
"def_plumbing"></a>plumbing
1525 Cute name for
<a href=
"#def_core_git">core Git
</a>.
1528 <dt class=
"hdlist1">
1529 <a id=
"def_porcelain"></a>porcelain
1533 Cute name for programs and program suites depending on
1534 <a href=
"#def_core_git">core Git
</a>, presenting a high level access to
1535 core Git. Porcelains expose more of a
<a href=
"#def_SCM">SCM
</a>
1536 interface than the
<a href=
"#def_plumbing">plumbing
</a>.
1539 <dt class=
"hdlist1">
1540 <a id=
"def_per_worktree_ref"></a>per-worktree ref
1544 Refs that are per-
<a href=
"#def_worktree">worktree
</a>, rather than
1545 global. This is presently only
<a href=
"#def_HEAD">HEAD
</a> and any refs
1546 that start with
<code>refs/bisect/
</code>, but might later include other
1550 <dt class=
"hdlist1">
1551 <a id=
"def_pseudoref"></a>pseudoref
1555 Pseudorefs are a class of files under
<code>$GIT_DIR
</code> which behave
1556 like refs for the purposes of rev-parse, but which are treated
1557 specially by git. Pseudorefs both have names that are all-caps,
1558 and always start with a line consisting of a
1559 <a href=
"#def_SHA1">SHA-
1</a> followed by whitespace. So, HEAD is not a
1560 pseudoref, because it is sometimes a symbolic ref. They might
1561 optionally contain some additional data.
<code>MERGE_HEAD
</code> and
1562 <code>CHERRY_PICK_HEAD
</code> are examples. Unlike
1563 <a href=
"#def_per_worktree_ref">per-worktree refs
</a>, these files cannot
1564 be symbolic refs, and never have reflogs. They also cannot be
1565 updated through the normal ref update machinery. Instead,
1566 they are updated by directly writing to the files. However,
1567 they can be read as if they were refs, so
<code>git rev-parse
1568 MERGE_HEAD
</code> will work.
1571 <dt class=
"hdlist1">
1572 <a id=
"def_pull"></a>pull
1576 Pulling a
<a href=
"#def_branch">branch
</a> means to
<a href=
"#def_fetch">fetch
</a> it and
1577 <a href=
"#def_merge">merge
</a> it. See also
<a href=
"git-pull.html">git-pull(
1)
</a>.
1580 <dt class=
"hdlist1">
1581 <a id=
"def_push"></a>push
1585 Pushing a
<a href=
"#def_branch">branch
</a> means to get the branch
’s
1586 <a href=
"#def_head_ref">head ref
</a> from a remote
<a href=
"#def_repository">repository
</a>,
1587 find out if it is an ancestor to the branch
’s local
1588 head ref, and in that case, putting all
1589 objects, which are
<a href=
"#def_reachable">reachable
</a> from the local
1590 head ref, and which are missing from the remote
1591 repository, into the remote
1592 <a href=
"#def_object_database">object database
</a>, and updating the remote
1593 head ref. If the remote
<a href=
"#def_head">head
</a> is not an
1594 ancestor to the local head, the push fails.
1597 <dt class=
"hdlist1">
1598 <a id=
"def_reachable"></a>reachable
1602 All of the ancestors of a given
<a href=
"#def_commit">commit
</a> are said to be
1603 "reachable" from that commit. More
1604 generally, one
<a href=
"#def_object">object
</a> is reachable from
1605 another if we can reach the one from the other by a
<a href=
"#def_chain">chain
</a>
1606 that follows
<a href=
"#def_tag">tags
</a> to whatever they tag,
1607 <a href=
"#def_commit_object">commits
</a> to their parents or trees, and
1608 <a href=
"#def_tree_object">trees
</a> to the trees or
<a href=
"#def_blob_object">blobs
</a>
1612 <dt class=
"hdlist1">
1613 <a id=
"def_reachability_bitmap"></a>reachability bitmaps
1617 Reachability bitmaps store information about the
1618 <a href=
"#def_reachable">reachability
</a> of a selected set of commits in
1619 a packfile, or a multi-pack index (MIDX), to speed up object search.
1620 The bitmaps are stored in a
".bitmap" file. A repository may have at
1621 most one bitmap file in use. The bitmap file may belong to either one
1622 pack, or the repository
’s multi-pack index (if it exists).
1625 <dt class=
"hdlist1">
1626 <a id=
"def_rebase"></a>rebase
1630 To reapply a series of changes from a
<a href=
"#def_branch">branch
</a> to a
1631 different base, and reset the
<a href=
"#def_head">head
</a> of that branch
1635 <dt class=
"hdlist1">
1636 <a id=
"def_ref"></a>ref
1640 A name that begins with
<code>refs/
</code> (e.g.
<code>refs/heads/master
</code>)
1641 that points to an
<a href=
"#def_object_name">object name
</a> or another
1642 ref (the latter is called a
<a href=
"#def_symref">symbolic ref
</a>).
1643 For convenience, a ref can sometimes be abbreviated when used
1644 as an argument to a Git command; see
<a href=
"gitrevisions.html">gitrevisions(
7)
</a>
1646 Refs are stored in the
<a href=
"#def_repository">repository
</a>.
1648 <div class=
"paragraph"><p>The ref namespace is hierarchical.
1649 Different subhierarchies are used for different purposes (e.g. the
1650 <code>refs/heads/
</code> hierarchy is used to represent local branches).
</p></div>
1651 <div class=
"paragraph"><p>There are a few special-purpose refs that do not begin with
<code>refs/
</code>.
1652 The most notable example is
<code>HEAD
</code>.
</p></div>
1654 <dt class=
"hdlist1">
1655 <a id=
"def_reflog"></a>reflog
1659 A reflog shows the local
"history" of a ref. In other words,
1660 it can tell you what the
3rd last revision in
<em>this
</em> repository
1661 was, and what was the current state in
<em>this
</em> repository,
1662 yesterday
9:
14pm. See
<a href=
"git-reflog.html">git-reflog(
1)
</a> for details.
1665 <dt class=
"hdlist1">
1666 <a id=
"def_refspec"></a>refspec
1670 A
"refspec" is used by
<a href=
"#def_fetch">fetch
</a> and
1671 <a href=
"#def_push">push
</a> to describe the mapping between remote
1672 <a href=
"#def_ref">ref
</a> and local ref.
1675 <dt class=
"hdlist1">
1676 <a id=
"def_remote"></a>remote repository
1680 A
<a href=
"#def_repository">repository
</a> which is used to track the same
1681 project but resides somewhere else. To communicate with remotes,
1682 see
<a href=
"#def_fetch">fetch
</a> or
<a href=
"#def_push">push
</a>.
1685 <dt class=
"hdlist1">
1686 <a id=
"def_remote_tracking_branch"></a>remote-tracking branch
1690 A
<a href=
"#def_ref">ref
</a> that is used to follow changes from another
1691 <a href=
"#def_repository">repository
</a>. It typically looks like
1692 <em>refs/remotes/foo/bar
</em> (indicating that it tracks a branch named
1693 <em>bar
</em> in a remote named
<em>foo
</em>), and matches the right-hand-side of
1694 a configured fetch
<a href=
"#def_refspec">refspec
</a>. A remote-tracking
1695 branch should not contain direct modifications or have local
1699 <dt class=
"hdlist1">
1700 <a id=
"def_repository"></a>repository
1704 A collection of
<a href=
"#def_ref">refs
</a> together with an
1705 <a href=
"#def_object_database">object database
</a> containing all objects
1706 which are
<a href=
"#def_reachable">reachable
</a> from the refs, possibly
1707 accompanied by meta data from one or more
<a href=
"#def_porcelain">porcelains
</a>. A
1708 repository can share an object database with other repositories
1709 via
<a href=
"#def_alternate_object_database">alternates mechanism
</a>.
1712 <dt class=
"hdlist1">
1713 <a id=
"def_resolve"></a>resolve
1717 The action of fixing up manually what a failed automatic
1718 <a href=
"#def_merge">merge
</a> left behind.
1721 <dt class=
"hdlist1">
1722 <a id=
"def_revision"></a>revision
1726 Synonym for
<a href=
"#def_commit">commit
</a> (the noun).
1729 <dt class=
"hdlist1">
1730 <a id=
"def_rewind"></a>rewind
1734 To throw away part of the development, i.e. to assign the
1735 <a href=
"#def_head">head
</a> to an earlier
<a href=
"#def_revision">revision
</a>.
1738 <dt class=
"hdlist1">
1739 <a id=
"def_SCM"></a>SCM
1743 Source code management (tool).
1746 <dt class=
"hdlist1">
1747 <a id=
"def_SHA1"></a>SHA-
1
1751 "Secure Hash Algorithm 1"; a cryptographic hash function.
1752 In the context of Git used as a synonym for
<a href=
"#def_object_name">object name
</a>.
1755 <dt class=
"hdlist1">
1756 <a id=
"def_shallow_clone"></a>shallow clone
1760 Mostly a synonym to
<a href=
"#def_shallow_repository">shallow repository
</a>
1761 but the phrase makes it more explicit that it was created by
1762 running
<code>git clone --depth=...
</code> command.
1765 <dt class=
"hdlist1">
1766 <a id=
"def_shallow_repository"></a>shallow repository
1770 A shallow
<a href=
"#def_repository">repository
</a> has an incomplete
1771 history some of whose
<a href=
"#def_commit">commits
</a> have
<a href=
"#def_parent">parents
</a> cauterized away (in other
1772 words, Git is told to pretend that these commits do not have the
1773 parents, even though they are recorded in the
<a href=
"#def_commit_object">commit object
</a>). This is sometimes useful when you are interested only in the
1774 recent history of a project even though the real history recorded in the
1775 upstream is much larger. A shallow repository
1776 is created by giving the
<code>--depth
</code> option to
<a href=
"git-clone.html">git-clone(
1)
</a>, and
1777 its history can be later deepened with
<a href=
"git-fetch.html">git-fetch(
1)
</a>.
1780 <dt class=
"hdlist1">
1781 <a id=
"def_stash"></a>stash entry
1785 An
<a href=
"#def_object">object
</a> used to temporarily store the contents of a
1786 <a href=
"#def_dirty">dirty
</a> working directory and the index for future reuse.
1789 <dt class=
"hdlist1">
1790 <a id=
"def_submodule"></a>submodule
1794 A
<a href=
"#def_repository">repository
</a> that holds the history of a
1795 separate project inside another repository (the latter of
1796 which is called
<a href=
"#def_superproject">superproject
</a>).
1799 <dt class=
"hdlist1">
1800 <a id=
"def_superproject"></a>superproject
1804 A
<a href=
"#def_repository">repository
</a> that references repositories
1805 of other projects in its working tree as
<a href=
"#def_submodule">submodules
</a>.
1806 The superproject knows about the names of (but does not hold
1807 copies of) commit objects of the contained submodules.
1810 <dt class=
"hdlist1">
1811 <a id=
"def_symref"></a>symref
1815 Symbolic reference: instead of containing the
<a href=
"#def_SHA1">SHA-
1</a>
1816 id itself, it is of the format
<em>ref: refs/some/thing
</em> and when
1817 referenced, it recursively dereferences to this reference.
1818 <em><a href=
"#def_HEAD">HEAD
</a></em> is a prime example of a symref. Symbolic
1819 references are manipulated with the
<a href=
"git-symbolic-ref.html">git-symbolic-ref(
1)
</a>
1823 <dt class=
"hdlist1">
1824 <a id=
"def_tag"></a>tag
1828 A
<a href=
"#def_ref">ref
</a> under
<code>refs/tags/
</code> namespace that points to an
1829 object of an arbitrary type (typically a tag points to either a
1830 <a href=
"#def_tag_object">tag
</a> or a
<a href=
"#def_commit_object">commit object
</a>).
1831 In contrast to a
<a href=
"#def_head">head
</a>, a tag is not updated by
1832 the
<code>commit
</code> command. A Git tag has nothing to do with a Lisp
1833 tag (which would be called an
<a href=
"#def_object_type">object type
</a>
1834 in Git
’s context). A tag is most typically used to mark a particular
1835 point in the commit ancestry
<a href=
"#def_chain">chain
</a>.
1838 <dt class=
"hdlist1">
1839 <a id=
"def_tag_object"></a>tag object
1843 An
<a href=
"#def_object">object
</a> containing a
<a href=
"#def_ref">ref
</a> pointing to
1844 another object, which can contain a message just like a
1845 <a href=
"#def_commit_object">commit object
</a>. It can also contain a (PGP)
1846 signature, in which case it is called a
"signed tag object".
1849 <dt class=
"hdlist1">
1850 <a id=
"def_topic_branch"></a>topic branch
1854 A regular Git
<a href=
"#def_branch">branch
</a> that is used by a developer to
1855 identify a conceptual line of development. Since branches are very easy
1856 and inexpensive, it is often desirable to have several small branches
1857 that each contain very well defined concepts or small incremental yet
1861 <dt class=
"hdlist1">
1862 <a id=
"def_tree"></a>tree
1866 Either a
<a href=
"#def_working_tree">working tree
</a>, or a
<a href=
"#def_tree_object">tree object
</a> together with the dependent
<a href=
"#def_blob_object">blob
</a> and tree objects
1867 (i.e. a stored representation of a working tree).
1870 <dt class=
"hdlist1">
1871 <a id=
"def_tree_object"></a>tree object
1875 An
<a href=
"#def_object">object
</a> containing a list of file names and modes along
1876 with refs to the associated blob and/or tree objects. A
1877 <a href=
"#def_tree">tree
</a> is equivalent to a
<a href=
"#def_directory">directory
</a>.
1880 <dt class=
"hdlist1">
1881 <a id=
"def_tree-ish"></a>tree-ish (also treeish)
1885 A
<a href=
"#def_tree_object">tree object
</a> or an
<a href=
"#def_object">object
</a>
1886 that can be recursively dereferenced to a tree object.
1887 Dereferencing a
<a href=
"#def_commit_object">commit object
</a> yields the
1888 tree object corresponding to the
<a href=
"#def_revision">revision
</a>'s
1889 top
<a href=
"#def_directory">directory
</a>.
1890 The following are all tree-ishes:
1891 a
<a href=
"#def_commit-ish">commit-ish
</a>,
1893 a
<a href=
"#def_tag_object">tag object
</a> that points to a tree object,
1894 a tag object that points to a tag object that points to a tree
1899 <dt class=
"hdlist1">
1900 <a id=
"def_unmerged_index"></a>unmerged index
1904 An
<a href=
"#def_index">index
</a> which contains unmerged
1905 <a href=
"#def_index_entry">index entries
</a>.
1908 <dt class=
"hdlist1">
1909 <a id=
"def_unreachable_object"></a>unreachable object
1913 An
<a href=
"#def_object">object
</a> which is not
<a href=
"#def_reachable">reachable
</a> from a
1914 <a href=
"#def_branch">branch
</a>,
<a href=
"#def_tag">tag
</a>, or any other reference.
1917 <dt class=
"hdlist1">
1918 <a id=
"def_upstream_branch"></a>upstream branch
1922 The default
<a href=
"#def_branch">branch
</a> that is merged into the branch in
1923 question (or the branch in question is rebased onto). It is configured
1924 via branch.
<name
>.remote and branch.
<name
>.merge. If the upstream branch
1925 of
<em>A
</em> is
<em>origin/B
</em> sometimes we say
"<em>A</em> is tracking <em>origin/B</em>".
1928 <dt class=
"hdlist1">
1929 <a id=
"def_working_tree"></a>working tree
1933 The tree of actual checked out files. The working tree normally
1934 contains the contents of the
<a href=
"#def_HEAD">HEAD
</a> commit
’s tree,
1935 plus any local changes that you have made but not yet committed.
1938 <dt class=
"hdlist1">
1939 <a id=
"def_worktree"></a>worktree
1943 A repository can have zero (i.e. bare repository) or one or
1944 more worktrees attached to it. One
"worktree" consists of a
1945 "working tree" and repository metadata, most of which are
1946 shared among other worktrees of a single repository, and
1947 some of which are maintained separately per worktree
1948 (e.g. the index, HEAD and pseudorefs like MERGE_HEAD,
1949 per-worktree refs and per-worktree configuration file).
1956 <h2 id=
"_see_also">SEE ALSO
</h2>
1957 <div class=
"sectionbody">
1958 <div class=
"paragraph"><p><a href=
"gittutorial.html">gittutorial(
7)
</a>,
1959 <a href=
"gittutorial-2.html">gittutorial-
2(
7)
</a>,
1960 <a href=
"gitcvs-migration.html">gitcvs-migration(
7)
</a>,
1961 <a href=
"giteveryday.html">giteveryday(
7)
</a>,
1962 <a href=
"user-manual.html">The Git User
’s Manual
</a></p></div>
1966 <h2 id=
"_git">GIT
</h2>
1967 <div class=
"sectionbody">
1968 <div class=
"paragraph"><p>Part of the
<a href=
"git.html">git(
1)
</a> suite
</p></div>
1972 <div id=
"footnotes"><hr /></div>
1974 <div id=
"footer-text">
1976 2020-
03-
10 15:
02:
33 PDT