{"id":629,"date":"2021-07-23T12:34:21","date_gmt":"2021-07-23T12:34:21","guid":{"rendered":"https:\/\/ssdsunucum.com\/blog\/guide-to-git-git-terms\/"},"modified":"2021-07-23T12:34:21","modified_gmt":"2021-07-23T12:34:21","slug":"guide-to-git-git-terms","status":"publish","type":"post","link":"https:\/\/ssdsunucum.com\/blog\/guide-to-git-git-terms\/","title":{"rendered":"Guide to Git\u2122 &#8211; Git Terms"},"content":{"rendered":"<\/p>\n<div class=\"col-md-9\">\n<div class=\"flex-column flex-md-row article-header\"><\/div>\n<hr>\n<h2 id=\"overview\">Overview<\/h2>\n<p>Git\u2122 is a system that tracks and manages changes to files (a version control system). Whenever content changes, Git records it and stores the history of every change. Because of Git\u2019s complex functionality, it uses many terms that novice users may not immediately understand.<\/p>\n<h2 id=\"common-git-terms\">Common Git terms<\/h2>\n<div class=\"callout callout-info\">\n<div class=\"callout-heading\">Note:<\/div>\n<div class=\"callout-content\">\n<p>Click a term to navigate to the official Git documentation for that concept or feature.<\/p>\n<\/p><\/div>\n<\/div>\n<h3 id=\"archive\">Archive<\/h3>\n<p>Archives store the contents of the current working tree (but not the <code>.git<\/code> directory or uncommitted changes) in a <code>.zip<\/code> or <code>.tar<\/code> file. You may wish to create an archive if, for example, you wish to provide a source download file.<\/p>\n<h3 id=\"branch\">Branch<\/h3>\n<p>Each branch in a repository represents a separate line of development, and all branches retain their own project history, working directory, and staging area.<\/p>\n<ul>\n<li>Each repository can contain as many branches as you wish to create.<\/li>\n<li>You can only work in one branch (the checked-out branch) at any given time.<\/li>\n<li>Generally, branches diverge from the original line of development with the intent to merge the branch\u2019s changes at a later time.<\/li>\n<\/ul>\n<h3 id=\"check-out\">Check out<\/h3>\n<p>Git uses this term in two contexts:<\/p>\n<ul>\n<li>When you check out a branch or commit via the <code>git checkout<\/code> command, Git points <code>HEAD<\/code> to the specified branch or commit. This allows you to switch between multiple branches from the command line.<\/li>\n<li>When you check out files via the <code>git checkout<\/code> command, Git copies the version of that file from the specified commit or from the index. This allows you to revert committed or uncommitted changes.<\/li>\n<\/ul>\n<h3 id=\"cherry-pick\">Cherry-pick<\/h3>\n<p>When you cherry-pick changes via the <code>git cherry-pick<\/code> command, Git applies the specified changes from a commit and branch to a different branch\u2019s <code>HEAD<\/code>.<\/p>\n<h3 id=\"clone\">Clone<\/h3>\n<p>When you clone a repository via the <code>git clone<\/code> command, Git performs the following actions:<\/p>\n<ol>\n<li>\n<p>Git creates a new repository (the local repository) in the directory in which you ran the command.<\/p>\n<div class=\"callout callout-info\">\n<div class=\"callout-heading\">Note:<\/div>\n<div class=\"callout-content\">\n<ul>\n<li>When you clone a repository in cPanel\u2019s <em>Git Version Control<\/em> interface (<em>cPanel &gt;&gt; Home &gt;&gt; Files &gt;&gt; Git Version Control<\/em>), the system creates the repository in the <em>Repository Path<\/em> directory that you specify.<\/li>\n<li>To clone private repositories, you must perform additional steps. For more information, read our Guide to Git &#8211; Set Up Access to Private Repositories documentation.<br \/>\n<\/li>\n<\/ul><\/div>\n<\/div>\n<\/li>\n<li>\n<p>Git sets the repository that you wish to clone (the remote repository) as the <code>origin<\/code> remote repository.<\/p>\n<\/li>\n<li>\n<p>Git fetches all of the commits and branches from the remote repository.<\/p>\n<\/li>\n<li>\n<p>Git checks out the default branch (generally, the <code>master<\/code> branch).<\/p>\n<\/li>\n<\/ol>\n<p>Effectively, this copies the remote repository. You can then make changes to the local repository and push them to the remote repository.<\/p>\n<h3 id=\"commit\">Commit<\/h3>\n<p>Commits represent a point in Git\u2019s history. Git\u2019s entire history for a repository exists as a timeline of individual commits. When you commit changes, you create a new point in the history that represents the current state of the index. <code>HEAD<\/code> then points to the new commit.<\/p>\n<h3 id=\"commit-object\">Commit Object<\/h3>\n<p>Commit objects represent your committed revisions to a branch. Each commit object contains the commit\u2019s files (the tree object), parent commits, commit metadata (for example, the author and date), and a SHA-1 value that identifies the object.<\/p>\n<h3 id=\"deployment\">Deployment<\/h3>\n<p>Deployment sends finished code into production. You can use different configurations to automatically (push deployment) or manually (pull deployment) deploy changes.<\/p>\n<ul>\n<li>\n<p>For example, you can configure cPanel\u2019s <em>Git Version Control<\/em> interface (<em>cPanel &gt;&gt; Home &gt;&gt; Files &gt;&gt; Git Version Control<\/em>) to automatically deploy changes that a cPanel-managed repository receives to the directory for your website.<\/p>\n<\/li>\n<li>\n<p>For more information, read our Guide to Git &#8211; How to Set Up Deployment documentation.<\/p>\n<\/li>\n<\/ul>\n<h3 id=\"fetch\">Fetch<\/h3>\n<p>When you fetch changes via the <code>git fetch<\/code> command, Git automatically downloads new changes from the remote repository. However, it does <strong>not<\/strong> integrate (merge) these changes into the working tree for any local branch.<\/p>\n<h3 id=\"fork\">Fork<\/h3>\n<p>When you fork a repository, you create a new server-side copy of that repository. You can then experiment with changes to that repository without any impact on the original repository.<\/p>\n<h3 id=\"head\">HEAD<\/h3>\n<p>The <code>HEAD<\/code> value represents the SHA-1 identifier for the most-recent commit or active branch. Whenever you commit changes to the active branch, Git automatically updates <code>HEAD<\/code> to that commit\u2019s SHA-1 identifier. If you use the <code>git checkout<\/code> command to check out a specific commit instead of a branch, Git enters the <code>detached HEAD<\/code> state.<\/p>\n<h3 id=\"head-1\">Head<\/h3>\n<p>Heads are the SHA-1 identifiers for the most-recent commits to each branch. While only one HEAD commit exists, a repository generally contains many heads for each branch.<\/p>\n<h3 id=\"hook\">Hook<\/h3>\n<p>Hooks are scripts or other code that you can configure to trigger before or after specific Git actions. You can store these hooks in the hooks directory within the repository directory.<\/p>\n<div class=\"callout callout-info\">\n<div class=\"callout-heading\">Note:<\/div>\n<div class=\"callout-content\">\n<p>cPanel\u2019s <em>Git Version Control<\/em> interface (<em>cPanel &gt;&gt; Home &gt;&gt; Files &gt;&gt; Git Version Control<\/em>) automatically adds a <code>post-receive<\/code> hook to cPanel-managed repositories.<\/p>\n<\/p><\/div>\n<\/div>\n<h3 id=\"index-staging-area-cache\">Index (Staging Area, Cache)<\/h3>\n<p>Indexes contain the files from your working tree that you add to a commit to the Git repository. Git also uses the index to store data during failed merges.<\/p>\n<h3 id=\"log\">Log<\/h3>\n<p>The log contains the commit hash and commit metadata, such as the commit message, for every commit on the current branch. You can access this data via the <code>git log<\/code> command on the command line or via Gitweb in cPanel\u2019s <em>Git Version Control<\/em> interface (<em>cPanel &gt;&gt; Home &gt;&gt; Files &gt;&gt; Git Version Control<\/em>).<\/p>\n<h3 id=\"master\">Master<\/h3>\n<p>Generally, the default branch for a repository is the <code>master<\/code> branch. When you commit changes to it, Git moves the <code>master<\/code> branch\u2019s <code>HEAD<\/code> to the most recent commit\u2019s SHA-1 identifier.<\/p>\n<h3 id=\"merge\">Merge<\/h3>\n<p>When you merge one or more commits, Git adds changes to the current branch. To perform a merge of this type, run the <code>git push<\/code> command.<\/p>\n<p>You may also need to manually merge specific revisions if they conflict with changes that have already merged into the repository.<\/p>\n<ul>\n<li>This type of merge uses the <code>git merge<\/code> command.<\/li>\n<li>The term merge may also refer to the commit that this type of merge creates.<\/li>\n<\/ul>\n<h3 id=\"origin\">Origin<\/h3>\n<p>The origin is Git\u2019s default name for the remote repository from which you cloned a local repository. Most repositories include at least one origin repository. Software development often refers to origin as upstream.<\/p>\n<h3 id=\"pull\">Pull<\/h3>\n<p>When you pull changes from the remote repository via the <code>git pull<\/code> command, Git fetches remote changes and then merges them into the current branch.<\/p>\n<div class=\"callout callout-info\">\n<div class=\"callout-heading\">Note:<\/div>\n<div class=\"callout-content\">\n<p>You can use the <em>Pull from Remote<\/em> feature in cPanel\u2019s <em>Git Version Control<\/em> interface (<em>cPanel &gt;&gt; Home &gt;&gt; Files &gt;&gt; Git Version Control<\/em>) to automatically pull changes for a repository\u2019s active branch.<\/p>\n<\/p><\/div>\n<\/div>\n<h3 id=\"push\">Push<\/h3>\n<p>When you push changes via the <code>git push<\/code> command, Git sends commits from your local branch to the remote repository.<\/p>\n<h3 id=\"rebase\">Rebase<\/h3>\n<p>Rebases via the <code>git rebase<\/code> command reapply changes to the history of the active branch. To do this, rebases eliminate merge commits and create a new commit for each commit in the original branch.<\/p>\n<h3 id=\"remote-remote-repository\">Remote (Remote Repository)<\/h3>\n<p>The remote repository exists on a remote filesystem. When you fetch, pull, or push code, Git sends changes to or receives changes from the remote repository.<\/p>\n<h3 id=\"repository\">Repository<\/h3>\n<p>Repositories store all of the data that Git manages for a specific project. It contains objects and heads as well as the working tree.<\/p>\n<h3 id=\"sha-1-sha-1-sum-hash\">SHA-1 (SHA-1 sum, Hash)<\/h3>\n<p>Technically, the algorithm that generates the names for Git objects. In Git\u2019s vernacular, this term also refers to the 40-character hexidecimal string that the algorithm generates.<\/p>\n<h3 id=\"stash\">Stash<\/h3>\n<p>An object that stores changes to the working tree and index for future reuse. The stash allows you to set aside changes to a branch and return to the HEAD state. You can then reapply the stashed changes or apply them to a different branch.<\/p>\n<h3 id=\"version-control\">Version Control<\/h3>\n<p>Version control systems track changes in files and allow multiple users to coordinate those changes and view and manipulate the project\u2019s history. Git is a version control system.<\/p>\n<h3 id=\"working-tree\">Working Tree<\/h3>\n<p>The working tree contains the checked-out file system for a repository. The working tree includes the files for the <code>HEAD<\/code> commit and any local changes to those files.<\/p>\n<\/p><\/div>\n","protected":false},"excerpt":{"rendered":"<p>Overview Git\u2122 is a system that tracks and manages changes to files (a version control system). Whenever content changes, Git records it and stores the history of every change. Because of Git\u2019s complex functionality, it uses many terms that novice users may not immediately understand. Common Git terms Note: Click a term to navigate to &hellip;<\/p>\n","protected":false},"author":1,"featured_media":630,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/ssdsunucum.com\/blog\/wp-json\/wp\/v2\/posts\/629"}],"collection":[{"href":"https:\/\/ssdsunucum.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ssdsunucum.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ssdsunucum.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ssdsunucum.com\/blog\/wp-json\/wp\/v2\/comments?post=629"}],"version-history":[{"count":0,"href":"https:\/\/ssdsunucum.com\/blog\/wp-json\/wp\/v2\/posts\/629\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ssdsunucum.com\/blog\/wp-json\/wp\/v2\/media\/630"}],"wp:attachment":[{"href":"https:\/\/ssdsunucum.com\/blog\/wp-json\/wp\/v2\/media?parent=629"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ssdsunucum.com\/blog\/wp-json\/wp\/v2\/categories?post=629"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ssdsunucum.com\/blog\/wp-json\/wp\/v2\/tags?post=629"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}