1[[def_alternate_object_database]]alternate object database:: 2 Via the alternates mechanism, a <<def_repository,repository>> 3 can inherit part of its <<def_object_database,object database>> 4 from another object database, which is called "alternate". 5 6[[def_bare_repository]]bare repository:: 7 A bare repository is normally an appropriately 8 named <<def_directory,directory>> with a `.git` suffix that does not 9 have a locally checked-out copy of any of the files under 10 revision control. That is, all of the Git 11 administrative and control files that would normally be present in the 12 hidden `.git` sub-directory are directly present in the 13 `repository.git` directory instead, 14 and no other files are present and checked out. Usually publishers of 15 public repositories make bare repositories available. 16 17[[def_blob_object]]blob object:: 18 Untyped <<def_object,object>>, e.g. the contents of a file. 19 20[[def_branch]]branch:: 21 A "branch" is an active line of development. The most recent 22 <<def_commit,commit>> on a branch is referred to as the tip of 23 that branch. The tip of the branch is referenced by a branch 24 <<def_head,head>>, which moves forward as additional development 25 is done on the branch. A single Git 26 <<def_repository,repository>> can track an arbitrary number of 27 branches, but your <<def_working_tree,working tree>> is 28 associated with just one of them (the "current" or "checked out" 29 branch), and <<def_HEAD,HEAD>> points to that branch. 30 31[[def_cache]]cache:: 32 Obsolete for: <<def_index,index>>. 33 34[[def_chain]]chain:: 35 A list of objects, where each <<def_object,object>> in the list contains 36 a reference to its successor (for example, the successor of a 37 <<def_commit,commit>> could be one of its <<def_parent,parents>>). 38 39[[def_changeset]]changeset:: 40 BitKeeper/cvsps speak for "<<def_commit,commit>>". Since Git does not 41 store changes, but states, it really does not make sense to use the term 42 "changesets" with Git. 43 44[[def_checkout]]checkout:: 45 The action of updating all or part of the 46 <<def_working_tree,working tree>> with a <<def_tree_object,tree object>> 47 or <<def_blob_object,blob>> from the 48 <<def_object_database,object database>>, and updating the 49 <<def_index,index>> and <<def_HEAD,HEAD>> if the whole working tree has 50 been pointed at a new <<def_branch,branch>>. 51 52[[def_cherry-picking]]cherry-picking:: 53 In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of 54 changes out of a series of changes (typically commits) and record them 55 as a new series of changes on top of a different codebase. In Git, this is 56 performed by the "git cherry-pick" command to extract the change introduced 57 by an existing <<def_commit,commit>> and to record it based on the tip 58 of the current <<def_branch,branch>> as a new commit. 59 60[[def_clean]]clean:: 61 A <<def_working_tree,working tree>> is clean, if it 62 corresponds to the <<def_revision,revision>> referenced by the current 63 <<def_head,head>>. Also see "<<def_dirty,dirty>>". 64 65[[def_commit]]commit:: 66 As a noun: A single point in the 67 Git history; the entire history of a project is represented as a 68 set of interrelated commits. The word "commit" is often 69 used by Git in the same places other revision control systems 70 use the words "revision" or "version". Also used as a short 71 hand for <<def_commit_object,commit object>>. 72+ 73As a verb: The action of storing a new snapshot of the project's 74state in the Git history, by creating a new commit representing the current 75state of the <<def_index,index>> and advancing <<def_HEAD,HEAD>> 76to point at the new commit. 77 78[[def_commit_object]]commit object:: 79 An <<def_object,object>> which contains the information about a 80 particular <<def_revision,revision>>, such as <<def_parent,parents>>, committer, 81 author, date and the <<def_tree_object,tree object>> which corresponds 82 to the top <<def_directory,directory>> of the stored 83 revision. 84 85[[def_core_git]]core Git:: 86 Fundamental data structures and utilities of Git. Exposes only limited 87 source code management tools. 88 89[[def_DAG]]DAG:: 90 Directed acyclic graph. The <<def_commit_object,commit objects>> form a 91 directed acyclic graph, because they have parents (directed), and the 92 graph of commit objects is acyclic (there is no <<def_chain,chain>> 93 which begins and ends with the same <<def_object,object>>). 94 95[[def_dangling_object]]dangling object:: 96 An <<def_unreachable_object,unreachable object>> which is not 97 <<def_reachable,reachable>> even from other unreachable objects; a 98 dangling object has no references to it from any 99 reference or <<def_object,object>> in the <<def_repository,repository>>. 100 101[[def_detached_HEAD]]detached HEAD:: 102 Normally the <<def_HEAD,HEAD>> stores the name of a 103 <<def_branch,branch>>, and commands that operate on the 104 history HEAD represents operate on the history leading to the 105 tip of the branch the HEAD points at. However, Git also 106 allows you to <<def_checkout,check out>> an arbitrary 107 <<def_commit,commit>> that isn't necessarily the tip of any 108 particular branch. The HEAD in such a state is called 109 "detached". 110+ 111Note that commands that operate on the history of the current branch 112(e.g. `git commit` to build a new history on top of it) still work 113while the HEAD is detached. They update the HEAD to point at the tip 114of the updated history without affecting any branch. Commands that 115update or inquire information _about_ the current branch (e.g. `git 116branch --set-upstream-to` that sets what remote-tracking branch the 117current branch integrates with) obviously do not work, as there is no 118(real) current branch to ask about in this state. 119 120[[def_directory]]directory:: 121 The list you get with "ls" :-) 122 123[[def_dirty]]dirty:: 124 A <<def_working_tree,working tree>> is said to be "dirty" if 125 it contains modifications which have not been <<def_commit,committed>> to the current 126 <<def_branch,branch>>. 127 128[[def_evil_merge]]evil merge:: 129 An evil merge is a <<def_merge,merge>> that introduces changes that 130 do not appear in any <<def_parent,parent>>. 131 132[[def_fast_forward]]fast-forward:: 133 A fast-forward is a special type of <<def_merge,merge>> where you have a 134 <<def_revision,revision>> and you are "merging" another 135 <<def_branch,branch>>'s changes that happen to be a descendant of what 136 you have. In such these cases, you do not make a new <<def_merge,merge>> 137 <<def_commit,commit>> but instead just update to his 138 revision. This will happen frequently on a 139 <<def_remote_tracking_branch,remote-tracking branch>> of a remote 140 <<def_repository,repository>>. 141 142[[def_fetch]]fetch:: 143 Fetching a <<def_branch,branch>> means to get the 144 branch's <<def_head_ref,head ref>> from a remote 145 <<def_repository,repository>>, to find out which objects are 146 missing from the local <<def_object_database,object database>>, 147 and to get them, too. See also linkgit:git-fetch[1]. 148 149[[def_file_system]]file system:: 150 Linus Torvalds originally designed Git to be a user space file system, 151 i.e. the infrastructure to hold files and directories. That ensured the 152 efficiency and speed of Git. 153 154[[def_git_archive]]Git archive:: 155 Synonym for <<def_repository,repository>> (for arch people). 156 157[[def_gitfile]]gitfile:: 158 A plain file `.git` at the root of a working tree that 159 points at the directory that is the real repository. 160 161[[def_grafts]]grafts:: 162 Grafts enables two otherwise different lines of development to be joined 163 together by recording fake ancestry information for commits. This way 164 you can make Git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has 165 is different from what was recorded when the commit was 166 created. Configured via the `.git/info/grafts` file. 167 168[[def_hash]]hash:: 169 In Git's context, synonym for <<def_object_name,object name>>. 170 171[[def_head]]head:: 172 A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a 173 <<def_branch,branch>>. Heads are stored in a file in 174 `$GIT_DIR/refs/heads/` directory, except when using packed refs. (See 175 linkgit:git-pack-refs[1].) 176 177[[def_HEAD]]HEAD:: 178 The current <<def_branch,branch>>. In more detail: Your <<def_working_tree, 179 working tree>> is normally derived from the state of the tree 180 referred to by HEAD. HEAD is a reference to one of the 181 <<def_head,heads>> in your repository, except when using a 182 <<def_detached_HEAD,detached HEAD>>, in which case it directly 183 references an arbitrary commit. 184 185[[def_head_ref]]head ref:: 186 A synonym for <<def_head,head>>. 187 188[[def_hook]]hook:: 189 During the normal execution of several Git commands, call-outs are made 190 to optional scripts that allow a developer to add functionality or 191 checking. Typically, the hooks allow for a command to be pre-verified 192 and potentially aborted, and allow for a post-notification after the 193 operation is done. The hook scripts are found in the 194 `$GIT_DIR/hooks/` directory, and are enabled by simply 195 removing the `.sample` suffix from the filename. In earlier versions 196 of Git you had to make them executable. 197 198[[def_index]]index:: 199 A collection of files with stat information, whose contents are stored 200 as objects. The index is a stored version of your 201 <<def_working_tree,working tree>>. Truth be told, it can also contain a second, and even 202 a third version of a working tree, which are used 203 when <<def_merge,merging>>. 204 205[[def_index_entry]]index entry:: 206 The information regarding a particular file, stored in the 207 <<def_index,index>>. An index entry can be unmerged, if a 208 <<def_merge,merge>> was started, but not yet finished (i.e. if 209 the index contains multiple versions of that file). 210 211[[def_master]]master:: 212 The default development <<def_branch,branch>>. Whenever you 213 create a Git <<def_repository,repository>>, a branch named 214 "master" is created, and becomes the active branch. In most 215 cases, this contains the local development, though that is 216 purely by convention and is not required. 217 218[[def_merge]]merge:: 219 As a verb: To bring the contents of another 220 <<def_branch,branch>> (possibly from an external 221 <<def_repository,repository>>) into the current branch. In the 222 case where the merged-in branch is from a different repository, 223 this is done by first <<def_fetch,fetching>> the remote branch 224 and then merging the result into the current branch. This 225 combination of fetch and merge operations is called a 226 <<def_pull,pull>>. Merging is performed by an automatic process 227 that identifies changes made since the branches diverged, and 228 then applies all those changes together. In cases where changes 229 conflict, manual intervention may be required to complete the 230 merge. 231+ 232As a noun: unless it is a <<def_fast_forward,fast-forward>>, a 233successful merge results in the creation of a new <<def_commit,commit>> 234representing the result of the merge, and having as 235<<def_parent,parents>> the tips of the merged <<def_branch,branches>>. 236This commit is referred to as a "merge commit", or sometimes just a 237"merge". 238 239[[def_object]]object:: 240 The unit of storage in Git. It is uniquely identified by the 241 <<def_SHA1,SHA-1>> of its contents. Consequently, an 242 object can not be changed. 243 244[[def_object_database]]object database:: 245 Stores a set of "objects", and an individual <<def_object,object>> is 246 identified by its <<def_object_name,object name>>. The objects usually 247 live in `$GIT_DIR/objects/`. 248 249[[def_object_identifier]]object identifier:: 250 Synonym for <<def_object_name,object name>>. 251 252[[def_object_name]]object name:: 253 The unique identifier of an <<def_object,object>>. The 254 object name is usually represented by a 40 character 255 hexadecimal string. Also colloquially called <<def_SHA1,SHA-1>>. 256 257[[def_object_type]]object type:: 258 One of the identifiers "<<def_commit_object,commit>>", 259 "<<def_tree_object,tree>>", "<<def_tag_object,tag>>" or 260 "<<def_blob_object,blob>>" describing the type of an 261 <<def_object,object>>. 262 263[[def_octopus]]octopus:: 264 To <<def_merge,merge>> more than two <<def_branch,branches>>. 265 266[[def_origin]]origin:: 267 The default upstream <<def_repository,repository>>. Most projects have 268 at least one upstream project which they track. By default 269 'origin' is used for that purpose. New upstream updates 270 will be fetched into <<def_remote_tracking_branch,remote-tracking branches>> named 271 origin/name-of-upstream-branch, which you can see using 272 `git branch -r`. 273 274[[def_pack]]pack:: 275 A set of objects which have been compressed into one file (to save space 276 or to transmit them efficiently). 277 278[[def_pack_index]]pack index:: 279 The list of identifiers, and other information, of the objects in a 280 <<def_pack,pack>>, to assist in efficiently accessing the contents of a 281 pack. 282 283[[def_pathspec]]pathspec:: 284 Pattern used to limit paths in Git commands. 285+ 286Pathspecs are used on the command line of "git ls-files", "git 287ls-tree", "git add", "git grep", "git diff", "git checkout", 288and many other commands to 289limit the scope of operations to some subset of the tree or 290worktree. See the documentation of each command for whether 291paths are relative to the current directory or toplevel. The 292pathspec syntax is as follows: 293+ 294-- 295 296* any path matches itself 297* the pathspec up to the last slash represents a 298 directory prefix. The scope of that pathspec is 299 limited to that subtree. 300* the rest of the pathspec is a pattern for the remainder 301 of the pathname. Paths relative to the directory 302 prefix will be matched against that pattern using fnmatch(3); 303 in particular, '*' and '?' _can_ match directory separators. 304 305-- 306+ 307For example, Documentation/*.jpg will match all .jpg files 308in the Documentation subtree, 309including Documentation/chapter_1/figure_1.jpg. 310+ 311A pathspec that begins with a colon `:` has special meaning. In the 312short form, the leading colon `:` is followed by zero or more "magic 313signature" letters (which optionally is terminated by another colon `:`), 314and the remainder is the pattern to match against the path. The optional 315colon that terminates the "magic signature" can be omitted if the pattern 316begins with a character that cannot be a "magic signature" and is not a 317colon. 318+ 319In the long form, the leading colon `:` is followed by a open 320parenthesis `(`, a comma-separated list of zero or more "magic words", 321and a close parentheses `)`, and the remainder is the pattern to match 322against the path. 323+ 324The "magic signature" consists of an ASCII symbol that is not 325alphanumeric. 326+ 327-- 328top `/`;; 329 The magic word `top` (mnemonic: `/`) makes the pattern match 330 from the root of the working tree, even when you are running 331 the command from inside a subdirectory. 332 333literal;; 334 Wildcards in the pattern such as `*` or `?` are treated 335 as literal characters. 336 337glob;; 338 Git treats the pattern as a shell glob suitable for 339 consumption by fnmatch(3) with the FNM_PATHNAME flag: 340 wildcards in the pattern will not match a / in the pathname. 341 For example, "Documentation/{asterisk}.html" matches 342 "Documentation/git.html" but not "Documentation/ppc/ppc.html" 343 or "tools/perf/Documentation/perf.html". 344+ 345Two consecutive asterisks ("`**`") in patterns matched against 346full pathname may have special meaning: 347 348 - A leading "`**`" followed by a slash means match in all 349 directories. For example, "`**/foo`" matches file or directory 350 "`foo`" anywhere, the same as pattern "`foo`". "**/foo/bar" 351 matches file or directory "`bar`" anywhere that is directly 352 under directory "`foo`". 353 354 - A trailing "/**" matches everything inside. For example, 355 "abc/**" matches all files inside directory "abc", relative 356 to the location of the `.gitignore` file, with infinite depth. 357 358 - A slash followed by two consecutive asterisks then a slash 359 matches zero or more directories. For example, "`a/**/b`" 360 matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on. 361 362 - Other consecutive asterisks are considered invalid. 363+ 364Glob magic is incompatible with literal magic. 365-- 366+ 367Currently only the slash `/` is recognized as the "magic signature", 368but it is envisioned that we will support more types of magic in later 369versions of Git. 370+ 371A pathspec with only a colon means "there is no pathspec". This form 372should not be combined with other pathspec. 373 374[[def_parent]]parent:: 375 A <<def_commit_object,commit object>> contains a (possibly empty) list 376 of the logical predecessor(s) in the line of development, i.e. its 377 parents. 378 379[[def_pickaxe]]pickaxe:: 380 The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore 381 routines that help select changes that add or delete a given text 382 string. With the `--pickaxe-all` option, it can be used to view the full 383 <<def_changeset,changeset>> that introduced or removed, say, a 384 particular line of text. See linkgit:git-diff[1]. 385 386[[def_plumbing]]plumbing:: 387 Cute name for <<def_core_git,core Git>>. 388 389[[def_porcelain]]porcelain:: 390 Cute name for programs and program suites depending on 391 <<def_core_git,core Git>>, presenting a high level access to 392 core Git. Porcelains expose more of a <<def_SCM,SCM>> 393 interface than the <<def_plumbing,plumbing>>. 394 395[[def_pull]]pull:: 396 Pulling a <<def_branch,branch>> means to <<def_fetch,fetch>> it and 397 <<def_merge,merge>> it. See also linkgit:git-pull[1]. 398 399[[def_push]]push:: 400 Pushing a <<def_branch,branch>> means to get the branch's 401 <<def_head_ref,head ref>> from a remote <<def_repository,repository>>, 402 find out if it is a direct ancestor to the branch's local 403 head ref, and in that case, putting all 404 objects, which are <<def_reachable,reachable>> from the local 405 head ref, and which are missing from the remote 406 repository, into the remote 407 <<def_object_database,object database>>, and updating the remote 408 head ref. If the remote <<def_head,head>> is not an 409 ancestor to the local head, the push fails. 410 411[[def_reachable]]reachable:: 412 All of the ancestors of a given <<def_commit,commit>> are said to be 413 "reachable" from that commit. More 414 generally, one <<def_object,object>> is reachable from 415 another if we can reach the one from the other by a <<def_chain,chain>> 416 that follows <<def_tag,tags>> to whatever they tag, 417 <<def_commit_object,commits>> to their parents or trees, and 418 <<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>> 419 that they contain. 420 421[[def_rebase]]rebase:: 422 To reapply a series of changes from a <<def_branch,branch>> to a 423 different base, and reset the <<def_head,head>> of that branch 424 to the result. 425 426[[def_ref]]ref:: 427 A 40-byte hex representation of a <<def_SHA1,SHA-1>> or a name that 428 denotes a particular <<def_object,object>>. They may be stored in 429 a file under `$GIT_DIR/refs/` directory, or 430 in the `$GIT_DIR/packed-refs` file. 431 432[[def_reflog]]reflog:: 433 A reflog shows the local "history" of a ref. In other words, 434 it can tell you what the 3rd last revision in _this_ repository 435 was, and what was the current state in _this_ repository, 436 yesterday 9:14pm. See linkgit:git-reflog[1] for details. 437 438[[def_refspec]]refspec:: 439 A "refspec" is used by <<def_fetch,fetch>> and 440 <<def_push,push>> to describe the mapping between remote 441 <<def_ref,ref>> and local ref. 442 443[[def_remote_tracking_branch]]remote-tracking branch:: 444 A <<def_ref,ref>> that is used to follow changes from another 445 <<def_repository,repository>>. It typically looks like 446 'refs/remotes/foo/bar' (indicating that it tracks a branch named 447 'bar' in a remote named 'foo'), and matches the right-hand-side of 448 a configured fetch <<def_refspec,refspec>>. A remote-tracking 449 branch should not contain direct modifications or have local 450 commits made to it. 451 452[[def_repository]]repository:: 453 A collection of <<def_ref,refs>> together with an 454 <<def_object_database,object database>> containing all objects 455 which are <<def_reachable,reachable>> from the refs, possibly 456 accompanied by meta data from one or more <<def_porcelain,porcelains>>. A 457 repository can share an object database with other repositories 458 via <<def_alternate_object_database,alternates mechanism>>. 459 460[[def_resolve]]resolve:: 461 The action of fixing up manually what a failed automatic 462 <<def_merge,merge>> left behind. 463 464[[def_revision]]revision:: 465 Synonym for <<def_commit,commit>> (the noun). 466 467[[def_rewind]]rewind:: 468 To throw away part of the development, i.e. to assign the 469 <<def_head,head>> to an earlier <<def_revision,revision>>. 470 471[[def_SCM]]SCM:: 472 Source code management (tool). 473 474[[def_SHA1]]SHA-1:: 475 "Secure Hash Algorithm 1"; a cryptographic hash function. 476 In the context of Git used as a synonym for <<def_object_name,object name>>. 477 478[[def_shallow_repository]]shallow repository:: 479 A shallow <<def_repository,repository>> has an incomplete 480 history some of whose <<def_commit,commits>> have <<def_parent,parents>> cauterized away (in other 481 words, Git is told to pretend that these commits do not have the 482 parents, even though they are recorded in the <<def_commit_object,commit 483 object>>). This is sometimes useful when you are interested only in the 484 recent history of a project even though the real history recorded in the 485 upstream is much larger. A shallow repository 486 is created by giving the `--depth` option to linkgit:git-clone[1], and 487 its history can be later deepened with linkgit:git-fetch[1]. 488 489[[def_symref]]symref:: 490 Symbolic reference: instead of containing the <<def_SHA1,SHA-1>> 491 id itself, it is of the format 'ref: refs/some/thing' and when 492 referenced, it recursively dereferences to this reference. 493 '<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic 494 references are manipulated with the linkgit:git-symbolic-ref[1] 495 command. 496 497[[def_tag]]tag:: 498 A <<def_ref,ref>> under `refs/tags/` namespace that points to an 499 object of an arbitrary type (typically a tag points to either a 500 <<def_tag_object,tag>> or a <<def_commit_object,commit object>>). 501 In contrast to a <<def_head,head>>, a tag is not updated by 502 the `commit` command. A Git tag has nothing to do with a Lisp 503 tag (which would be called an <<def_object_type,object type>> 504 in Git's context). A tag is most typically used to mark a particular 505 point in the commit ancestry <<def_chain,chain>>. 506 507[[def_tag_object]]tag object:: 508 An <<def_object,object>> containing a <<def_ref,ref>> pointing to 509 another object, which can contain a message just like a 510 <<def_commit_object,commit object>>. It can also contain a (PGP) 511 signature, in which case it is called a "signed tag object". 512 513[[def_topic_branch]]topic branch:: 514 A regular Git <<def_branch,branch>> that is used by a developer to 515 identify a conceptual line of development. Since branches are very easy 516 and inexpensive, it is often desirable to have several small branches 517 that each contain very well defined concepts or small incremental yet 518 related changes. 519 520[[def_tree]]tree:: 521 Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree 522 object>> together with the dependent <<def_blob_object,blob>> and tree objects 523 (i.e. a stored representation of a working tree). 524 525[[def_tree_object]]tree object:: 526 An <<def_object,object>> containing a list of file names and modes along 527 with refs to the associated blob and/or tree objects. A 528 <<def_tree,tree>> is equivalent to a <<def_directory,directory>>. 529 530[[def_tree-ish]]tree-ish:: 531 A <<def_ref,ref>> pointing to either a <<def_commit_object,commit 532 object>>, a <<def_tree_object,tree object>>, or a <<def_tag_object,tag 533 object>> pointing to a tag or commit or tree object. 534 535[[def_unmerged_index]]unmerged index:: 536 An <<def_index,index>> which contains unmerged 537 <<def_index_entry,index entries>>. 538 539[[def_unreachable_object]]unreachable object:: 540 An <<def_object,object>> which is not <<def_reachable,reachable>> from a 541 <<def_branch,branch>>, <<def_tag,tag>>, or any other reference. 542 543[[def_upstream_branch]]upstream branch:: 544 The default <<def_branch,branch>> that is merged into the branch in 545 question (or the branch in question is rebased onto). It is configured 546 via branch.<name>.remote and branch.<name>.merge. If the upstream branch 547 of 'A' is 'origin/B' sometimes we say "'A' is tracking 'origin/B'". 548 549[[def_working_tree]]working tree:: 550 The tree of actual checked out files. The working tree normally 551 contains the contents of the <<def_HEAD,HEAD>> commit's tree, 552 plus any local changes that you have made but not yet committed.