learngit/glossary/index.html

309 lines
20 KiB
HTML
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link rel="shortcut icon" href="../img/favicon.ico">
<title>glossary - learngit</title>
<link href="../css/bootstrap.min.css" rel="stylesheet">
<link href="../css/font-awesome.min.css" rel="stylesheet">
<link href="../css/base.css" rel="stylesheet">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/darcula.min.css">
<script src="../js/jquery-1.10.2.min.js" defer></script>
<script src="../js/bootstrap.min.js" defer></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>
</head>
<body>
<div class="navbar fixed-top navbar-expand-lg navbar-dark bg-primary">
<div class="container">
<a class="navbar-brand" href="..">learngit</a>
<!-- Expander button -->
<button type="button" class="navbar-toggler" data-toggle="collapse" data-target="#navbar-collapse">
<span class="navbar-toggler-icon"></span>
</button>
<!-- Expanded navigation -->
<div id="navbar-collapse" class="navbar-collapse collapse">
<!-- Main navigation -->
<ul class="nav navbar-nav">
<li class="navitem">
<a href=".." class="nav-link">learngit</a>
</li>
<li class="navitem">
<a href="../branching_strategies/" class="nav-link">branching</a>
</li>
<li class="navitem">
<a href="../common_commands/" class="nav-link">common commands</a>
</li>
<li class="navitem active">
<a href="./" class="nav-link">glossary</a>
</li>
<li class="navitem">
<a href="../ssh_setup/" class="nav-link">ssh key setup</a>
</li>
</ul>
<ul class="nav navbar-nav ml-auto">
<li class="nav-item">
<a href="#" class="nav-link" data-toggle="modal" data-target="#mkdocs_search_modal">
<i class="fa fa-search"></i> Search
</a>
</li>
<li class="nav-item">
<a rel="prev" href="../common_commands/" class="nav-link">
<i class="fa fa-arrow-left"></i> Previous
</a>
</li>
<li class="nav-item">
<a rel="next" href="../ssh_setup/" class="nav-link">
Next <i class="fa fa-arrow-right"></i>
</a>
</li>
<li class="nav-item">
<a href="https://github.com/benharri/learngit/blob/master/docs/glossary.md" class="nav-link"><i class="fa fa-github"></i> Edit on GitHub</a>
</li>
</ul>
</div>
</div>
</div>
<div class="container">
<div class="row">
<div class="col-md-3"><div class="navbar-light navbar-expand-md bs-sidebar hidden-print affix" role="complementary">
<div class="navbar-header">
<button type="button" class="navbar-toggler collapsed" data-toggle="collapse" data-target="#toc-collapse" title="Table of Contents">
<span class="fa fa-angle-down"></span>
</button>
</div>
<div id="toc-collapse" class="navbar-collapse collapse card bg-light">
<ul class="nav flex-column">
<li class="nav-item" data-level="1"><a href="#glossary" class="nav-link">glossary</a>
<ul class="nav flex-column">
<li class="nav-item" data-level="2"><a href="#branch" class="nav-link">branch</a>
<ul class="nav flex-column">
</ul>
</li>
<li class="nav-item" data-level="2"><a href="#checkout" class="nav-link">checkout</a>
<ul class="nav flex-column">
</ul>
</li>
<li class="nav-item" data-level="2"><a href="#commit" class="nav-link">commit</a>
<ul class="nav flex-column">
</ul>
</li>
<li class="nav-item" data-level="2"><a href="#directory" class="nav-link">directory</a>
<ul class="nav flex-column">
</ul>
</li>
<li class="nav-item" data-level="2"><a href="#dirty" class="nav-link">dirty</a>
<ul class="nav flex-column">
</ul>
</li>
<li class="nav-item" data-level="2"><a href="#distributed-version-control-system" class="nav-link">distributed version control system</a>
<ul class="nav flex-column">
</ul>
</li>
<li class="nav-item" data-level="2"><a href="#gitignore" class="nav-link">gitignore</a>
<ul class="nav flex-column">
</ul>
</li>
<li class="nav-item" data-level="2"><a href="#hash" class="nav-link">hash</a>
<ul class="nav flex-column">
</ul>
</li>
<li class="nav-item" data-level="2"><a href="#master" class="nav-link">master</a>
<ul class="nav flex-column">
</ul>
</li>
<li class="nav-item" data-level="2"><a href="#origin" class="nav-link">origin</a>
<ul class="nav flex-column">
</ul>
</li>
<li class="nav-item" data-level="2"><a href="#pathspec" class="nav-link">pathspec</a>
<ul class="nav flex-column">
</ul>
</li>
<li class="nav-item" data-level="2"><a href="#refspec" class="nav-link">refspec</a>
<ul class="nav flex-column">
</ul>
</li>
<li class="nav-item" data-level="2"><a href="#remote" class="nav-link">remote</a>
<ul class="nav flex-column">
</ul>
</li>
<li class="nav-item" data-level="2"><a href="#repository" class="nav-link">repository</a>
<ul class="nav flex-column">
</ul>
</li>
<li class="nav-item" data-level="2"><a href="#staging-area" class="nav-link">staging area</a>
<ul class="nav flex-column">
</ul>
</li>
<li class="nav-item" data-level="2"><a href="#working-tree" class="nav-link">working tree</a>
<ul class="nav flex-column">
</ul>
</li>
</ul>
</li>
</ul>
</div>
</div></div>
<div class="col-md-9" role="main">
<h1 id="glossary">glossary<a class="headerlink" href="#glossary" title="Permanent link">&para;</a></h1>
<blockquote>
<p><a href="https://git-scm.com/book/en/v2">source (git-scm.com)</a> (unless otherwise noted)</p>
</blockquote>
<hr />
<h2 id="branch"><a href="https://git-scm.com/book/en/v1/Git-Branching-What-a-Branch-Is">branch</a><a class="headerlink" href="#branch" title="Permanent link">&para;</a></h2>
<p>To really understand the way Git does branching, we need to take a step back and examine how Git stores its data. As you may remember from Chapter 1, Git doesnt store data as a series of changesets or deltas, but instead as a series of snapshots.</p>
<p>Running <a href="../common_commands/#commit"><code>git commit</code></a> checksums all project directories and stores them as tree objects in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree object so it can re-create that snapshot when needed.</p>
<p>A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you initially make commits, youre given a master branch that points to the last commit you made. Every time you commit, it moves forward automatically.</p>
<h2 id="checkout"><a href="../common_commands/#checkout">checkout</a><a class="headerlink" href="#checkout" title="Permanent link">&para;</a></h2>
<p>Checking out is the operation of switching the working tree to the state at a given snapshot, which is usually the HEAD of another branch.</p>
<h2 id="commit">commit<a class="headerlink" href="#commit" title="Permanent link">&para;</a></h2>
<p>A commit is a snapshot of all tracked files in the repo.</p>
<h2 id="directory">directory<a class="headerlink" href="#directory" title="Permanent link">&para;</a></h2>
<p>Also known as a folder.</p>
<h2 id="dirty">dirty<a class="headerlink" href="#dirty" title="Permanent link">&para;</a></h2>
<blockquote>
<p><a href="https://stackoverflow.com/questions/20642980/does-git-dirty-mean-files-not-staged-or-not-committed-glossary-conflict">source</a></p>
</blockquote>
<p>The "right" definition is, I think, that your tree is "clean" if there are no changes to commit and no changes between "tree staged for commit" (contents of index) and "work directory". However, it's reasonable to ask separately whether the index is clean (i.e., there is nothing staged for commit) and/or the work-tree is clean (unchanged) with respect to "the staging area" or "the HEAD commit".</p>
<h2 id="distributed-version-control-system">distributed version control system<a class="headerlink" href="#distributed-version-control-system" title="Permanent link">&para;</a></h2>
<p>A Distributed Version Control System (DVCS) differs from traditional VCS systems in that every user has a copy of the entire repo, including the history and all branches.</p>
<p>A connection to a central server is not required to work on a project. Changes and conflicts can be resolved later when the diverging histories are <a href="../common_commands/#merge"><code>merge</code></a>d later on.</p>
<h2 id="gitignore"><a href="https://git-scm.com/docs/gitignore">gitignore</a><a class="headerlink" href="#gitignore" title="Permanent link">&para;</a></h2>
<p>Specifies intentionally untracked files to ignore.</p>
<p>A <code>.gitignore</code> file in the root of the repository contains a list of patterns that should not be tracked.</p>
<p>See the documentation for more information on ignore patterns.</p>
<p>Tracked files that you would like to ignore can be deleted with <code>git rm --cached .</code> and then re-added with <code>git add .</code></p>
<h2 id="hash"><a href="https://git-scm.com/docs/gitglossary#def_SHA1">hash</a><a class="headerlink" href="#hash" title="Permanent link">&para;</a></h2>
<p>The unique identifier of an object. The object name is usually represented by a 40 character hexadecimal string. Also colloquially called SHA-1.</p>
<h2 id="master">master<a class="headerlink" href="#master" title="Permanent link">&para;</a></h2>
<p>Master is the name given to the default branch of a repository.</p>
<p>Whenever you create a Git repository, a branch named "master" is created, and becomes the active branch. In most cases, this contains the local development, though that is purely by convention and is not required.</p>
<h2 id="origin">origin<a class="headerlink" href="#origin" title="Permanent link">&para;</a></h2>
<p>Origin is the name given to the default remote. It is set automatically when using <a href="../common_commands/#clone"><code>git clone</code></a>, and recommended when setting up the remote for an existing repo.</p>
<h2 id="pathspec"><a href="https://git-scm.com/docs/gitglossary#gitglossary-aiddefpathspecapathspec">pathspec</a><a class="headerlink" href="#pathspec" title="Permanent link">&para;</a></h2>
<p>Pattern used to limit paths in Git commands.</p>
<p>Pathspecs are used on the command line of <code>git ls-files</code>, <code>git ls-tree</code>, <code>git add</code>, <code>git grep</code>, <code>git diff</code>, <code>git checkout</code>, and many other commands to limit the scope of operations to some subset of the tree or worktree. See the documentation of each command for whether paths are relative to the current directory or toplevel. The pathspec syntax is as follows:</p>
<ul>
<li>
<p>any path matches itself</p>
</li>
<li>
<p>the pathspec up to the last slash represents a directory prefix. The scope of that pathspec is limited to that subtree.</p>
</li>
<li>
<p>the rest of the pathspec is a pattern for the remainder of the pathname. Paths relative to the directory prefix will be matched against that pattern using fnmatch(3); in particular, * and ? can match directory separators.</p>
</li>
</ul>
<p>For example, Documentation/*.jpg will match all .jpg files in the Documentation subtree, including Documentation/chapter_1/figure_1.jpg.</p>
<p>A pathspec that begins with a colon : has special meaning. In the short form, the leading colon : is followed by zero or more "magic signature" letters (which optionally is terminated by another colon :), and the remainder is the pattern to match against the path. The "magic signature" consists of ASCII symbols that are neither alphanumeric, glob, regex special characters nor colon. The optional colon that terminates the "magic signature" can be omitted if the pattern begins with a character that does not belong to "magic signature" symbol set and is not a colon.</p>
<p>In the long form, the leading colon : is followed by a open parenthesis (, a comma-separated list of zero or more "magic words", and a close parentheses ), and the remainder is the pattern to match against the path.</p>
<p>A pathspec with only a colon means "there is no pathspec". This form should not be combined with other pathspec.</p>
<h2 id="refspec"><a href="https://git-scm.com/docs/gitglossary#gitglossary-aiddefrefaref">refspec</a><a class="headerlink" href="#refspec" title="Permanent link">&para;</a></h2>
<p>A name that begins with refs/ (e.g. refs/heads/master) that points to an object name or another ref (the latter is called a symbolic ref). For convenience, a ref can sometimes be abbreviated when used as an argument to a Git command; see gitrevisions[7] for details. Refs are stored in the repository.</p>
<p>The ref namespace is hierarchical. Different subhierarchies are used for different purposes (e.g. the refs/heads/ hierarchy is used to represent local branches).</p>
<p>There are a few special-purpose refs that do not begin with refs/. The most notable example is HEAD.</p>
<h2 id="remote"><a href="https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes">remote</a><a class="headerlink" href="#remote" title="Permanent link">&para;</a></h2>
<p>Remote repositories are versions of your project that are hosted on the Internet or network somewhere. You can have several of them, each of which generally is either read-only or read/write for you. Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work.</p>
<h2 id="repository"><a href="https://git-scm.com/docs/gitglossary#def_repository">repository</a><a class="headerlink" href="#repository" title="Permanent link">&para;</a></h2>
<p>A collection of refs together with an object database containing all objects which are reachable from the refs, possibly accompanied by meta data from one or more porcelains. A repository can share an object database with other repositories via alternates mechanism.</p>
<h2 id="staging-area"><a href="https://softwareengineering.stackexchange.com/questions/119782/what-does-stage-mean-in-git">staging area</a><a class="headerlink" href="#staging-area" title="Permanent link">&para;</a></h2>
<p>source: <a href="https://softwareengineering.stackexchange.com/questions/119782/what-does-stage-mean-in-git">stack exchange</a></p>
<p>To stage a file is simply to prepare it finely for a commit. Git, with its index allows you to commit only certain parts of the changes you've done since the last commit. Say you're working on two features - one is finished, and one still needs some work done. You'd like to make a commit and go home (5 o'clock, finally!) but wouldn't like to commit the parts of the second feature, which is not done yet. You stage the parts you know belong to the first feature, and commit. Now your commit is your project with the first feature done, while the second is still in work-in-progress in your working directory.</p>
<h2 id="working-tree"><a href="https://git-scm.com/docs/gitglossary#gitglossary-aiddefworkingtreeaworkingtree">working tree</a><a class="headerlink" href="#working-tree" title="Permanent link">&para;</a></h2>
<p>The tree of actual checked out files. The working tree normally contains the contents of the HEAD commits tree, plus any local changes that you have made but not yet committed.</p></div>
</div>
</div>
<footer class="col-md-12">
<hr>
<p>Documentation built with <a href="https://www.mkdocs.org/">MkDocs</a>.</p>
</footer>
<script>
var base_url = "..",
shortcuts = {"help": 191, "next": 78, "previous": 80, "search": 83};
</script>
<script src="../js/base.js" defer></script>
<script src="../search/main.js" defer></script>
<div class="modal" id="mkdocs_search_modal" tabindex="-1" role="dialog" aria-labelledby="searchModalLabel" aria-hidden="true">
<div class="modal-dialog modal-lg">
<div class="modal-content">
<div class="modal-header">
<h4 class="modal-title" id="searchModalLabel">Search</h4>
<button type="button" class="close" data-dismiss="modal"><span aria-hidden="true">&times;</span><span class="sr-only">Close</span></button>
</div>
<div class="modal-body">
<p>
From here you can search these documents. Enter
your search terms below.
</p>
<form>
<div class="form-group">
<input type="search" class="form-control" placeholder="Search..." id="mkdocs-search-query" title="Type search term here">
</div>
</form>
<div id="mkdocs-search-results"></div>
</div>
<div class="modal-footer">
</div>
</div>
</div>
</div><div class="modal" id="mkdocs_keyboard_modal" tabindex="-1" role="dialog" aria-labelledby="keyboardModalLabel" aria-hidden="true">
<div class="modal-dialog">
<div class="modal-content">
<div class="modal-header">
<h4 class="modal-title" id="keyboardModalLabel">Keyboard Shortcuts</h4>
<button type="button" class="close" data-dismiss="modal"><span aria-hidden="true">&times;</span><span class="sr-only">Close</span></button>
</div>
<div class="modal-body">
<table class="table">
<thead>
<tr>
<th style="width: 20%;">Keys</th>
<th>Action</th>
</tr>
</thead>
<tbody>
<tr>
<td class="help shortcut"><kbd>?</kbd></td>
<td>Open this help</td>
</tr>
<tr>
<td class="next shortcut"><kbd>n</kbd></td>
<td>Next page</td>
</tr>
<tr>
<td class="prev shortcut"><kbd>p</kbd></td>
<td>Previous page</td>
</tr>
<tr>
<td class="search shortcut"><kbd>s</kbd></td>
<td>Search</td>
</tr>
</tbody>
</table>
</div>
<div class="modal-footer">
</div>
</div>
</div>
</div>
</body>
</html>