🕷️ Crawler Inspector

URL Lookup

Direct Parameter Lookup

Raw Queries and Responses

1. Shard Calculation

Query:

Response:

Calculated Shard: 54 (from laksa167)

2. Crawled Status Check

Query:

curl -X POST \
  'http://laksa054.int.ahrefs:8124/' \
  -H 'Content-Type: text/plain' \
  -H 'X-ClickHouse-Database: crawler3' \
  -H 'Authorization: Basic YXBpOg==' \
  -d 'SELECT getAhrefsURLFromUnparsed(src_unparsed) AS found_url, ifNull(toUnixTimestamp(download_stamp), 0) AS crawl_time, ifNull(toUnixTimestamp(props_url_first_seen), 0) AS first_indexed_time, download_http_code AS http_code, src_unparsed AS src_unparsed, src_root_hash AS src_root_hash, history_drop_reason AS history_drop_reason, meta_title AS meta_title, meta_descriptions AS meta_descriptions, attrs_boilerpipe_text AS attrs_boilerpipe_text, attrs_markdown AS attrs_markdown, attrs_readable_markdown AS attrs_readable_markdown, meta_canonical AS meta_canonical FROM crawler3.page_info_local FINAL PREWHERE (src_root_hash, src_unparsed) IN ((getAhrefsRootHashFromUnparsed(getAhrefsUnparsedNoserviceFromURL(\'https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell\')), getAhrefsUnparsedNoserviceFromURL(\'https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell\'))) FORMAT JSONEachRow'

Response:

{"found_url":"https:\/\/git-scm.com\/book\/en\/v2\/Git-Branching-Branches-in-a-Nutshell","crawl_time":1775977840,"first_indexed_time":1414411230,"http_code":200,"src_unparsed":"com,git-scm!\/book\/en\/v2\/Git-Branching-Branches-in-a-Nutshell s443","src_root_hash":"7104038400628677254","history_drop_reason":null,"meta_title":"Git - Branches in a Nutshell","meta_descriptions":[],"attrs_boilerpipe_text":"Nearly every VCS has some form of branching support.\nBranching means you diverge from the main line of development and continue to do work without messing with that main line.\nIn many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects.\nSome people refer to Git’s branching model as its “killer feature,” and it certainly sets Git apart in the VCS community.\nWhy is it so special?\nThe way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast.\nUnlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day.\nUnderstanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop.\nTo really understand the way Git does branching, we need to take a step back and examine how Git stores its data.\nAs you may remember from\nWhat is Git?\n, Git doesn’t store data as a series of changesets or differences, but instead as a series of\nsnapshots\n.\nWhen you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged.\nThis object also contains the author’s name and email address, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.\nTo visualize this, let’s assume that you have a directory containing three files, and you stage them all and commit.\nStaging the files computes a checksum for each one (the SHA-1 hash we mentioned in\nWhat is Git?\n), stores that version of the file in the Git repository (Git refers to them as\nblobs\n), and adds that checksum to the staging area:\n$ git add README test.rb LICENSE\n$ git commit -m 'Initial commit'\nWhen you create the commit by running\ngit commit\n, Git checksums each subdirectory (in this case, just the root project directory) and stores them as a tree object in the Git repository.\nGit then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.\nYour Git repository now contains five objects: three\nblobs\n(each representing the contents of one of the three files), one\ntree\nthat lists the contents of the directory and specifies which file names are stored as which blobs, and one\ncommit\nwith the pointer to that root tree and all the commit metadata.\nFigure 9. A commit and its tree\nIf you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it.\nFigure 10. Commits and their parents\nA branch in Git is simply a lightweight movable pointer to one of these commits.\nThe default branch name in Git is\nmaster\n.\nAs you start making commits, you’re given a\nmaster\nbranch that points to the last commit you made.\nEvery time you commit, the\nmaster\nbranch pointer moves forward automatically.\nNote\nThe “master” branch in Git is not a special branch.\nIt is exactly like any other branch.\nThe only reason nearly every repository has one is that the\ngit init\ncommand creates it by default and most people don’t bother to change it.\nFigure 11. A branch and its commit history\nCreating a New Branch\nWhat happens when you create a new branch?\nWell, doing so creates a new pointer for you to move around.\nLet’s say you want to create a new branch called\ntesting\n.\nYou do this with the\ngit branch\ncommand:\n$ git branch testing\nThis creates a new pointer to the same commit you’re currently on.\nFigure 12. Two branches pointing into the same series of commits\nHow does Git know what branch you’re currently on?\nIt keeps a special pointer called\nHEAD\n.\nNote that this is a lot different than the concept of\nHEAD\nin other VCSs you may be used to, such as Subversion or CVS.\nIn Git, this is a pointer to the local branch you’re currently on.\nIn this case, you’re still on\nmaster\n.\nThe\ngit branch\ncommand only\ncreated\na new branch — it didn’t switch to that branch.\nFigure 13. HEAD pointing to a branch\nYou can easily see this by running a simple\ngit log\ncommand that shows you where the branch pointers are pointing.\nThis option is called\n--decorate\n.\n$ git log --oneline --decorate\nf30ab (HEAD -> master, testing) Add feature #32 - ability to add new formats to the central interface\n34ac2 Fix bug #1328 - stack overflow under certain conditions\n98ca9 Initial commit\nYou can see the\nmaster\nand\ntesting\nbranches that are right there next to the\nf30ab\ncommit.\nSwitching Branches\nTo switch to an existing branch, you run the\ngit checkout\ncommand.\nLet’s switch to the new\ntesting\nbranch:\n$ git checkout testing\nThis moves\nHEAD\nto point to the\ntesting\nbranch.\nFigure 14. HEAD points to the current branch\nWhat is the significance of that?\nWell, let’s do another commit:\n$ vim test.rb\n$ git commit -a -m 'Make a change'\nFigure 15. The HEAD branch moves forward when a commit is made\nThis is interesting, because now your\ntesting\nbranch has moved forward, but your\nmaster\nbranch still points to the commit you were on when you ran\ngit checkout\nto switch branches.\nLet’s switch back to the\nmaster\nbranch:\n$ git checkout master\nNote\ngit log\ndoesn’t show\nall\nthe branches\nall\nthe time\nIf you were to run\ngit log\nright now, you might wonder where the \"testing\" branch you just created went, as it would not appear in the output.\nThe branch hasn’t disappeared; Git just doesn’t know that you’re interested in that branch and it is trying to show you what it thinks you’re interested in.\nIn other words, by default,\ngit log\nwill only show commit history below the branch you’ve checked out.\nTo show commit history for the desired branch you have to explicitly specify it:\ngit log testing\n.\nTo show all of the branches, add\n--all\nto your\ngit log\ncommand.\nFigure 16. HEAD moves when you checkout\nThat command did two things.\nIt moved the HEAD pointer back to point to the\nmaster\nbranch, and it reverted the files in your working directory back to the snapshot that\nmaster\npoints to.\nThis also means the changes you make from this point forward will diverge from an older version of the project.\nIt essentially rewinds the work you’ve done in your\ntesting\nbranch so you can go in a different direction.\nNote\nSwitching branches changes files in your working directory\nIt’s important to note that when you switch branches in Git, files in your working directory will change.\nIf you switch to an older branch, your working directory will be reverted to look like it did the last time you committed on that branch.\nIf Git cannot do it cleanly, it will not let you switch at all.\nLet’s make a few changes and commit again:\n$ vim test.rb\n$ git commit -a -m 'Make other changes'\nNow your project history has diverged (see\nDivergent history\n).\nYou created and switched to a branch, did some work on it, and then switched back to your main branch and did other work.\nBoth of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready.\nAnd you did all that with simple\nbranch\n,\ncheckout\n, and\ncommit\ncommands.\nFigure 17. Divergent history\nYou can also see this easily with the\ngit log\ncommand.\nIf you run\ngit log --oneline --decorate --graph --all\nit will print out the history of your commits, showing where your branch pointers are and how your history has diverged.\n$ git log --oneline --decorate --graph --all\n* c2b9e (HEAD, master) Make other changes\n| * 87ab2 (testing) Make a change\n|\/\n* f30ab Add feature #32 - ability to add new formats to the central interface\n* 34ac2 Fix bug #1328 - stack overflow under certain conditions\n* 98ca9 Initial commit of my project\nBecause a branch in Git is actually a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy.\nCreating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).\nThis is in sharp contrast to the way most older VCS tools branch, which involves copying all of the project’s files into a second directory.\nThis can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous.\nAlso, because we’re recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do.\nThese features help encourage developers to create and use branches often.\nLet’s see why you should do so.\nNote\nCreating a new branch and switching to it at the same time\nIt’s typical to create a new branch and want to switch to that new branch at the same time — this can be done in one operation with\ngit checkout -b <newbranchname>\n.\nNote\nFrom Git version 2.23 onwards you can use\ngit switch\ninstead of\ngit checkout\nto:\nSwitch to an existing branch:\ngit switch testing-branch\n.\nCreate a new branch and switch to it:\ngit switch -c new-branch\n.\nThe\n-c\nflag stands for create, you can also use the full flag:\n--create\n.\nReturn to your previously checked out branch:\ngit switch -\n.","attrs_markdown":"[![Git](https:\/\/git-scm.com\/images\/logo@2x.png)](https:\/\/git-scm.com\/) \\--distributed-is-the-new-centralized\n\n![](https:\/\/git-scm.com\/images\/dark-mode.svg)\n\n- [About](https:\/\/git-scm.com\/about)\n  - [Trademark](https:\/\/git-scm.com\/about\/trademark)\n- [Learn](https:\/\/git-scm.com\/learn)\n  - [Book](https:\/\/git-scm.com\/book)\n  - [Cheat Sheet](https:\/\/git-scm.com\/cheat-sheet)\n  - [Videos](https:\/\/git-scm.com\/videos)\n  - [External Links](https:\/\/git-scm.com\/doc\/ext)\n- [Tools](https:\/\/git-scm.com\/tools)\n  - [Command Line](https:\/\/git-scm.com\/tools\/command-line)\n  - [GUIs](https:\/\/git-scm.com\/tools\/guis)\n  - [Hosting](https:\/\/git-scm.com\/tools\/hosting)\n- [Reference](https:\/\/git-scm.com\/docs)\n- [Install](https:\/\/git-scm.com\/install\/linux)\n- [Community](https:\/\/git-scm.com\/community)\n***\nThis book is available in [English](https:\/\/git-scm.com\/book\/en\/v2\/Git-Branching-Branches-in-a-Nutshell).\n\nFull translation available in\n\n|   |\n|---|\n| [azərbaycan dili](https:\/\/git-scm.com\/book\/az\/v2\/Git%E2%80%99d%C9%99-Branch-Nutshell%E2%80%99d%C9%99-Branch%E2%80%99lar), |\n| [български език](https:\/\/git-scm.com\/book\/bg\/v2\/%D0%9A%D0%BB%D0%BE%D0%BD%D0%BE%D0%B2%D0%B5-%D0%B2-Git-%D0%9D%D0%B0%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE-%D0%B7%D0%B0-%D1%80%D0%B0%D0%B7%D0%BA%D0%BB%D0%BE%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F%D1%82%D0%B0), |\n| [Deutsch](https:\/\/git-scm.com\/book\/de\/v2\/Git-Branching-Branches-auf-einen-Blick), |\n| [Español](https:\/\/git-scm.com\/book\/es\/v2\/Ramificaciones-en-Git-%C2%BFQu%C3%A9-es-una-rama), |\n| [فارسی](https:\/\/git-scm.com\/book\/fa\/v2\/%D8%A7%D9%86%D8%B4%D8%B9%D8%A7%D8%A8%E2%80%8C%DA%AF%DB%8C%D8%B1%DB%8C-%D8%AF%D8%B1-%DA%AF%DB%8C%D8%AA-Git-Branching-%D8%B4%D8%A7%D8%AE%D9%87%E2%80%8C%D9%87%D8%A7-%D8%AF%D8%B1-%DB%8C%DA%A9-%D9%86%DA%AF%D8%A7%D9%87-Branches-in-a-Nutshell), |\n| [Français](https:\/\/git-scm.com\/book\/fr\/v2\/Les-branches-avec-Git-Les-branches-en-bref), |\n| [Ελληνικά](https:\/\/git-scm.com\/book\/gr\/v2\/%CE%94%CE%B9%CE%B1%CE%BA%CE%BB%CE%B1%CE%B4%CF%8E%CF%83%CE%B5%CE%B9%CF%82-%CF%83%CF%84%CE%BF-Git-%CE%9F%CE%B9-%CE%BA%CE%BB%CE%AC%CE%B4%CE%BF%CE%B9-%CE%BC%CE%B5-%CE%BB%CE%AF%CE%B3%CE%B1-%CE%BB%CF%8C%CE%B3%CE%B9%CE%B1), |\n| [日本語](https:\/\/git-scm.com\/book\/ja\/v2\/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%81%A8%E3%81%AF), |\n| [한국어](https:\/\/git-scm.com\/book\/ko\/v2\/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%B8%8C%EB%9E%9C%EC%B9%98%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80), |\n| [Nederlands](https:\/\/git-scm.com\/book\/nl\/v2\/Branchen-in-Git-Branches-in-vogelvlucht), |\n| [Русский](https:\/\/git-scm.com\/book\/ru\/v2\/%D0%92%D0%B5%D1%82%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B2-Git-%D0%9E-%D0%B2%D0%B5%D1%82%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B8-%D0%B2-%D0%B4%D0%B2%D1%83%D1%85-%D1%81%D0%BB%D0%BE%D0%B2%D0%B0%D1%85), |\n| [Slovenščina](https:\/\/git-scm.com\/book\/sl\/v2\/Veje-Git-Veje-na-kratko), |\n| [Српски](https:\/\/git-scm.com\/book\/sr\/v2\/%D0%93%D1%80%D0%B0%D0%BD%D0%B0%D1%9A%D0%B5-%D1%83-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D1%83-%D0%93%D0%B8%D1%82-%D0%A3%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE-%D0%BE-%D0%B3%D1%80%D0%B0%D0%BD%D0%B0%D1%9A%D1%83), |\n| [Svenska](https:\/\/git-scm.com\/book\/sv\/v2\/Git-grenar-Grenar-i-korthet), |\n| [Tagalog](https:\/\/git-scm.com\/book\/tl\/v2\/Pag-branch-ng-Git-Mga-Branch-sa-Maikling-Salita), |\n| [Türkçe](https:\/\/git-scm.com\/book\/tr\/v2\/Git-Dallar%C4%B1-Dallar). |\n| [Українська](https:\/\/git-scm.com\/book\/uk\/v2\/%D0%93%D0%B0%D0%BB%D1%83%D0%B6%D0%B5%D0%BD%D0%BD%D1%8F-%D0%B2-git-%D0%93%D1%96%D0%BB%D0%BA%D0%B8-%D1%83-%D0%BA%D1%96%D0%BB%D1%8C%D0%BA%D0%BE%D1%85-%D1%81%D0%BB%D0%BE%D0%B2%D0%B0%D1%85), |\n| [简体中文](https:\/\/git-scm.com\/book\/zh\/v2\/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%AE%80%E4%BB%8B), |\n\nPartial translations available in\n\n|   |\n|---|\n| [Čeština](https:\/\/git-scm.com\/book\/cs\/v2\/V%C4%9Btve-v-syst%C3%A9mu-Git-V%C4%9Btve-v-kostce), |\n| [Македонски](https:\/\/git-scm.com\/book\/mk\/v2\/%D0%93%D1%80%D0%B0%D0%BD%D0%B5%D1%9A%D0%B5-%D0%B2%D0%BE-Git-%D0%93%D1%80%D0%B0%D0%BD%D0%B5%D1%9A%D0%B5-%D0%BE%D0%B1%D1%98%D0%B0%D1%81%D0%BD%D0%B5%D1%82%D0%BE), |\n| [Polski](https:\/\/git-scm.com\/book\/pl\/v2\/Ga%C5%82%C4%99zie-Gita-Czym-jest-ga%C5%82%C4%85%C5%BA), |\n| [Português (Brasil)](https:\/\/git-scm.com\/book\/pt-br\/v2\/Branches-no-Git-Branches-em-poucas-palavras), |\n| [Ўзбекча](https:\/\/git-scm.com\/book\/uz\/v2\/Git-%D0%B4%D0%B0-%D1%82%D0%B0%D1%80%D0%BC%D0%BE%D2%9B%D0%BB%D0%B0%D0%BD%D0%B8%D1%88-%D0%A2%D0%B0%D1%80%D0%BC%D0%BE%D2%9B%D0%BB%D0%B0%D0%BD%D0%B8%D1%88-%D2%B3%D0%B0%D2%9B%D0%B8%D0%B4%D0%B0-%D0%B8%D0%BA%D0%BA%D0%B8-%D0%BE%D2%93%D0%B8%D0%B7-%D1%81%D1%9E%D0%B7), |\n| [繁體中文](https:\/\/git-scm.com\/book\/zh-tw\/v2\/%E4%BD%BF%E7%94%A8-Git-%E5%88%86%E6%94%AF-%E7%B0%A1%E8%BF%B0%E5%88%86%E6%94%AF), |\n\nTranslations started for\n\n|   |\n|---|\n| [Беларуская](https:\/\/git-scm.com\/book\/be\/v2\/Git-Branching-Branches-in-a-Nutshell), |\n| [Indonesian](https:\/\/git-scm.com\/book\/id\/v2\/Git-Branching-Branches-in-a-Nutshell), |\n| [Italiano](https:\/\/git-scm.com\/book\/it\/v2\/Git-Branching-Branches-in-a-Nutshell), |\n| [Bahasa Melayu](https:\/\/git-scm.com\/book\/ms\/v2\/Git-Branching-Branches-in-a-Nutshell), |\n| [Português (Portugal)](https:\/\/git-scm.com\/book\/pt-pt\/v2\/Ramifica%C3%A7%C3%A3o-do-Git-Branches-in-a-Nutshell). |\n***\nThe source of this book is [hosted on GitHub.](https:\/\/github.com\/progit\/progit2)  \n Patches, suggestions and comments are welcome.\n\n[Chapters ▾](https:\/\/git-scm.com\/book\/en\/v2\/Git-Branching-Branches-in-a-Nutshell)\n\n1. ## 1\\. [Getting Started](https:\/\/git-scm.com\/book\/en\/v2\/Getting-Started-About-Version-Control)\n   1. 1\\.1 [About Version Control](https:\/\/git-scm.com\/book\/en\/v2\/Getting-Started-About-Version-Control)\n   2. 1\\.2 [A Short History of Git](https:\/\/git-scm.com\/book\/en\/v2\/Getting-Started-A-Short-History-of-Git)\n   3. 1\\.3 [What is Git?](https:\/\/git-scm.com\/book\/en\/v2\/Getting-Started-What-is-Git%3F)\n   4. 1\\.4 [The Command Line](https:\/\/git-scm.com\/book\/en\/v2\/Getting-Started-The-Command-Line)\n   5. 1\\.5 [Installing Git](https:\/\/git-scm.com\/book\/en\/v2\/Getting-Started-Installing-Git)\n   6. 1\\.6 [First-Time Git Setup](https:\/\/git-scm.com\/book\/en\/v2\/Getting-Started-First-Time-Git-Setup)\n   7. 1\\.7 [Getting Help](https:\/\/git-scm.com\/book\/en\/v2\/Getting-Started-Getting-Help)\n   8. 1\\.8 [Summary](https:\/\/git-scm.com\/book\/en\/v2\/Getting-Started-Summary)\n2. ## 2\\. [Git Basics](https:\/\/git-scm.com\/book\/en\/v2\/Git-Basics-Getting-a-Git-Repository)\n   1. 2\\.1 [Getting a Git Repository](https:\/\/git-scm.com\/book\/en\/v2\/Git-Basics-Getting-a-Git-Repository)\n   2. 2\\.2 [Recording Changes to the Repository](https:\/\/git-scm.com\/book\/en\/v2\/Git-Basics-Recording-Changes-to-the-Repository)\n   3. 2\\.3 [Viewing the Commit History](https:\/\/git-scm.com\/book\/en\/v2\/Git-Basics-Viewing-the-Commit-History)\n   4. 2\\.4 [Undoing Things](https:\/\/git-scm.com\/book\/en\/v2\/Git-Basics-Undoing-Things)\n   5. 2\\.5 [Working with Remotes](https:\/\/git-scm.com\/book\/en\/v2\/Git-Basics-Working-with-Remotes)\n   6. 2\\.6 [Tagging](https:\/\/git-scm.com\/book\/en\/v2\/Git-Basics-Tagging)\n   7. 2\\.7 [Git Aliases](https:\/\/git-scm.com\/book\/en\/v2\/Git-Basics-Git-Aliases)\n   8. 2\\.8 [Summary](https:\/\/git-scm.com\/book\/en\/v2\/Git-Basics-Summary)\n3. ## 3\\. [Git Branching](https:\/\/git-scm.com\/book\/en\/v2\/Git-Branching-Branches-in-a-Nutshell)\n   1. 3\\.1 [Branches in a Nutshell](https:\/\/git-scm.com\/book\/en\/v2\/Git-Branching-Branches-in-a-Nutshell)\n   2. 3\\.2 [Basic Branching and Merging](https:\/\/git-scm.com\/book\/en\/v2\/Git-Branching-Basic-Branching-and-Merging)\n   3. 3\\.3 [Branch Management](https:\/\/git-scm.com\/book\/en\/v2\/Git-Branching-Branch-Management)\n   4. 3\\.4 [Branching Workflows](https:\/\/git-scm.com\/book\/en\/v2\/Git-Branching-Branching-Workflows)\n   5. 3\\.5 [Remote Branches](https:\/\/git-scm.com\/book\/en\/v2\/Git-Branching-Remote-Branches)\n   6. 3\\.6 [Rebasing](https:\/\/git-scm.com\/book\/en\/v2\/Git-Branching-Rebasing)\n   7. 3\\.7 [Summary](https:\/\/git-scm.com\/book\/en\/v2\/Git-Branching-Summary)\n4. ## 4\\. [Git on the Server](https:\/\/git-scm.com\/book\/en\/v2\/Git-on-the-Server-The-Protocols)\n   1. 4\\.1 [The Protocols](https:\/\/git-scm.com\/book\/en\/v2\/Git-on-the-Server-The-Protocols)\n   2. 4\\.2 [Getting Git on a Server](https:\/\/git-scm.com\/book\/en\/v2\/Git-on-the-Server-Getting-Git-on-a-Server)\n   3. 4\\.3 [Generating Your SSH Public Key](https:\/\/git-scm.com\/book\/en\/v2\/Git-on-the-Server-Generating-Your-SSH-Public-Key)\n   4. 4\\.4 [Setting Up the Server](https:\/\/git-scm.com\/book\/en\/v2\/Git-on-the-Server-Setting-Up-the-Server)\n   5. 4\\.5 [Git Daemon](https:\/\/git-scm.com\/book\/en\/v2\/Git-on-the-Server-Git-Daemon)\n   6. 4\\.6 [Smart HTTP](https:\/\/git-scm.com\/book\/en\/v2\/Git-on-the-Server-Smart-HTTP)\n   7. 4\\.7 [GitWeb](https:\/\/git-scm.com\/book\/en\/v2\/Git-on-the-Server-GitWeb)\n   8. 4\\.8 [GitLab](https:\/\/git-scm.com\/book\/en\/v2\/Git-on-the-Server-GitLab)\n   9. 4\\.9 [Third Party Hosted Options](https:\/\/git-scm.com\/book\/en\/v2\/Git-on-the-Server-Third-Party-Hosted-Options)\n   10. 4\\.10 [Summary](https:\/\/git-scm.com\/book\/en\/v2\/Git-on-the-Server-Summary)\n5. ## 5\\. [Distributed Git](https:\/\/git-scm.com\/book\/en\/v2\/Distributed-Git-Distributed-Workflows)\n   1. 5\\.1 [Distributed Workflows](https:\/\/git-scm.com\/book\/en\/v2\/Distributed-Git-Distributed-Workflows)\n   2. 5\\.2 [Contributing to a Project](https:\/\/git-scm.com\/book\/en\/v2\/Distributed-Git-Contributing-to-a-Project)\n   3. 5\\.3 [Maintaining a Project](https:\/\/git-scm.com\/book\/en\/v2\/Distributed-Git-Maintaining-a-Project)\n   4. 5\\.4 [Summary](https:\/\/git-scm.com\/book\/en\/v2\/Distributed-Git-Summary)\n\n1. ## 6\\. [GitHub](https:\/\/git-scm.com\/book\/en\/v2\/GitHub-Account-Setup-and-Configuration)\n   1. 6\\.1 [Account Setup and Configuration](https:\/\/git-scm.com\/book\/en\/v2\/GitHub-Account-Setup-and-Configuration)\n   2. 6\\.2 [Contributing to a Project](https:\/\/git-scm.com\/book\/en\/v2\/GitHub-Contributing-to-a-Project)\n   3. 6\\.3 [Maintaining a Project](https:\/\/git-scm.com\/book\/en\/v2\/GitHub-Maintaining-a-Project)\n   4. 6\\.4 [Managing an organization](https:\/\/git-scm.com\/book\/en\/v2\/GitHub-Managing-an-organization)\n   5. 6\\.5 [Scripting GitHub](https:\/\/git-scm.com\/book\/en\/v2\/GitHub-Scripting-GitHub)\n   6. 6\\.6 [Summary](https:\/\/git-scm.com\/book\/en\/v2\/GitHub-Summary)\n2. ## 7\\. [Git Tools](https:\/\/git-scm.com\/book\/en\/v2\/Git-Tools-Revision-Selection)\n   1. 7\\.1 [Revision Selection](https:\/\/git-scm.com\/book\/en\/v2\/Git-Tools-Revision-Selection)\n   2. 7\\.2 [Interactive Staging](https:\/\/git-scm.com\/book\/en\/v2\/Git-Tools-Interactive-Staging)\n   3. 7\\.3 [Stashing and Cleaning](https:\/\/git-scm.com\/book\/en\/v2\/Git-Tools-Stashing-and-Cleaning)\n   4. 7\\.4 [Signing Your Work](https:\/\/git-scm.com\/book\/en\/v2\/Git-Tools-Signing-Your-Work)\n   5. 7\\.5 [Searching](https:\/\/git-scm.com\/book\/en\/v2\/Git-Tools-Searching)\n   6. 7\\.6 [Rewriting History](https:\/\/git-scm.com\/book\/en\/v2\/Git-Tools-Rewriting-History)\n   7. 7\\.7 [Reset Demystified](https:\/\/git-scm.com\/book\/en\/v2\/Git-Tools-Reset-Demystified)\n   8. 7\\.8 [Advanced Merging](https:\/\/git-scm.com\/book\/en\/v2\/Git-Tools-Advanced-Merging)\n   9. 7\\.9 [Rerere](https:\/\/git-scm.com\/book\/en\/v2\/Git-Tools-Rerere)\n   10. 7\\.10 [Debugging with Git](https:\/\/git-scm.com\/book\/en\/v2\/Git-Tools-Debugging-with-Git)\n   11. 7\\.11 [Submodules](https:\/\/git-scm.com\/book\/en\/v2\/Git-Tools-Submodules)\n   12. 7\\.12 [Bundling](https:\/\/git-scm.com\/book\/en\/v2\/Git-Tools-Bundling)\n   13. 7\\.13 [Replace](https:\/\/git-scm.com\/book\/en\/v2\/Git-Tools-Replace)\n   14. 7\\.14 [Credential Storage](https:\/\/git-scm.com\/book\/en\/v2\/Git-Tools-Credential-Storage)\n   15. 7\\.15 [Summary](https:\/\/git-scm.com\/book\/en\/v2\/Git-Tools-Summary)\n3. ## 8\\. [Customizing Git](https:\/\/git-scm.com\/book\/en\/v2\/Customizing-Git-Git-Configuration)\n   1. 8\\.1 [Git Configuration](https:\/\/git-scm.com\/book\/en\/v2\/Customizing-Git-Git-Configuration)\n   2. 8\\.2 [Git Attributes](https:\/\/git-scm.com\/book\/en\/v2\/Customizing-Git-Git-Attributes)\n   3. 8\\.3 [Git Hooks](https:\/\/git-scm.com\/book\/en\/v2\/Customizing-Git-Git-Hooks)\n   4. 8\\.4 [An Example Git-Enforced Policy](https:\/\/git-scm.com\/book\/en\/v2\/Customizing-Git-An-Example-Git-Enforced-Policy)\n   5. 8\\.5 [Summary](https:\/\/git-scm.com\/book\/en\/v2\/Customizing-Git-Summary)\n4. ## 9\\. [Git and Other Systems](https:\/\/git-scm.com\/book\/en\/v2\/Git-and-Other-Systems-Git-as-a-Client)\n   1. 9\\.1 [Git as a Client](https:\/\/git-scm.com\/book\/en\/v2\/Git-and-Other-Systems-Git-as-a-Client)\n   2. 9\\.2 [Migrating to Git](https:\/\/git-scm.com\/book\/en\/v2\/Git-and-Other-Systems-Migrating-to-Git)\n   3. 9\\.3 [Summary](https:\/\/git-scm.com\/book\/en\/v2\/Git-and-Other-Systems-Summary)\n5. ## 10\\. [Git Internals](https:\/\/git-scm.com\/book\/en\/v2\/Git-Internals-Plumbing-and-Porcelain)\n   1. 10\\.1 [Plumbing and Porcelain](https:\/\/git-scm.com\/book\/en\/v2\/Git-Internals-Plumbing-and-Porcelain)\n   2. 10\\.2 [Git Objects](https:\/\/git-scm.com\/book\/en\/v2\/Git-Internals-Git-Objects)\n   3. 10\\.3 [Git References](https:\/\/git-scm.com\/book\/en\/v2\/Git-Internals-Git-References)\n   4. 10\\.4 [Packfiles](https:\/\/git-scm.com\/book\/en\/v2\/Git-Internals-Packfiles)\n   5. 10\\.5 [The Refspec](https:\/\/git-scm.com\/book\/en\/v2\/Git-Internals-The-Refspec)\n   6. 10\\.6 [Transfer Protocols](https:\/\/git-scm.com\/book\/en\/v2\/Git-Internals-Transfer-Protocols)\n   7. 10\\.7 [Maintenance and Data Recovery](https:\/\/git-scm.com\/book\/en\/v2\/Git-Internals-Maintenance-and-Data-Recovery)\n   8. 10\\.8 [Environment Variables](https:\/\/git-scm.com\/book\/en\/v2\/Git-Internals-Environment-Variables)\n   9. 10\\.9 [Summary](https:\/\/git-scm.com\/book\/en\/v2\/Git-Internals-Summary)\n\n1. ## A1. [Appendix A: Git in Other Environments](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-A:-Git-in-Other-Environments-Graphical-Interfaces)\n   1. A1.1 [Graphical Interfaces](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-A:-Git-in-Other-Environments-Graphical-Interfaces)\n   2. A1.2 [Git in Visual Studio](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-A:-Git-in-Other-Environments-Git-in-Visual-Studio)\n   3. A1.3 [Git in Visual Studio Code](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-A:-Git-in-Other-Environments-Git-in-Visual-Studio-Code)\n   4. A1.4 [Git in IntelliJ \/ PyCharm \/ WebStorm \/ PhpStorm \/ RubyMine](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-A:-Git-in-Other-Environments-Git-in-IntelliJ-\/-PyCharm-\/-WebStorm-\/-PhpStorm-\/-RubyMine)\n   5. A1.5 [Git in Sublime Text](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-A:-Git-in-Other-Environments-Git-in-Sublime-Text)\n   6. A1.6 [Git in Bash](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-A:-Git-in-Other-Environments-Git-in-Bash)\n   7. A1.7 [Git in Zsh](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-A:-Git-in-Other-Environments-Git-in-Zsh)\n   8. A1.8 [Git in PowerShell](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-A:-Git-in-Other-Environments-Git-in-PowerShell)\n   9. A1.9 [Summary](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-A:-Git-in-Other-Environments-Summary)\n2. ## A2. [Appendix B: Embedding Git in your Applications](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-B:-Embedding-Git-in-your-Applications-Command-line-Git)\n   1. A2.1 [Command-line Git](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-B:-Embedding-Git-in-your-Applications-Command-line-Git)\n   2. A2.2 [Libgit2](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-B:-Embedding-Git-in-your-Applications-Libgit2)\n   3. A2.3 [JGit](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-B:-Embedding-Git-in-your-Applications-JGit)\n   4. A2.4 [go-git](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-B:-Embedding-Git-in-your-Applications-go-git)\n   5. A2.5 [Dulwich](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-B:-Embedding-Git-in-your-Applications-Dulwich)\n3. ## A3. [Appendix C: Git Commands](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-C:-Git-Commands-Setup-and-Config)\n   1. A3.1 [Setup and Config](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-C:-Git-Commands-Setup-and-Config)\n   2. A3.2 [Getting and Creating Projects](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-C:-Git-Commands-Getting-and-Creating-Projects)\n   3. A3.3 [Basic Snapshotting](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-C:-Git-Commands-Basic-Snapshotting)\n   4. A3.4 [Branching and Merging](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-C:-Git-Commands-Branching-and-Merging)\n   5. A3.5 [Sharing and Updating Projects](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-C:-Git-Commands-Sharing-and-Updating-Projects)\n   6. A3.6 [Inspection and Comparison](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-C:-Git-Commands-Inspection-and-Comparison)\n   7. A3.7 [Debugging](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-C:-Git-Commands-Debugging)\n   8. A3.8 [Patching](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-C:-Git-Commands-Patching)\n   9. A3.9 [Email](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-C:-Git-Commands-Email)\n   10. A3.10 [External Systems](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-C:-Git-Commands-External-Systems)\n   11. A3.11 [Administration](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-C:-Git-Commands-Administration)\n   12. A3.12 [Plumbing Commands](https:\/\/git-scm.com\/book\/en\/v2\/Appendix-C:-Git-Commands-Plumbing-Commands)\n\n2nd Edition\n\n# 3\\.1 Git Branching - Branches in a Nutshell\nNearly every VCS has some form of branching support. Branching means you diverge from the main line of development and continue to do work without messing with that main line. In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects.\n\nSome people refer to Git’s branching model as its “killer feature,” and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop.\n\n## Branches in a Nutshell\nTo really understand the way Git does branching, we need to take a step back and examine how Git stores its data.\n\nAs you may remember from [What is Git?](https:\/\/git-scm.com\/book\/en\/v2\/ch00\/what_is_git_section), Git doesn’t store data as a series of changesets or differences, but instead as a series of *snapshots*.\n\nWhen you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged. This object also contains the author’s name and email address, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.\n\nTo visualize this, let’s assume that you have a directory containing three files, and you stage them all and commit. Staging the files computes a checksum for each one (the SHA-1 hash we mentioned in [What is Git?](https:\/\/git-scm.com\/book\/en\/v2\/ch00\/what_is_git_section)), stores that version of the file in the Git repository (Git refers to them as *blobs*), and adds that checksum to the staging area:\n```\n$ git add README test.rb LICENSE\n$ git commit -m 'Initial commit'\n```\nWhen you create the commit by running `git commit`, Git checksums each subdirectory (in this case, just the root project directory) and stores them as a tree object in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.\n\nYour Git repository now contains five objects: three *blobs* (each representing the contents of one of the three files), one *tree* that lists the contents of the directory and specifies which file names are stored as which blobs, and one *commit* with the pointer to that root tree and all the commit metadata.\n\n![A commit and its tree](https:\/\/git-scm.com\/book\/en\/v2\/images\/commit-and-tree.png)\n\nFigure 9. A commit and its tree\n\nIf you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it.\n\n![Commits and their parents](https:\/\/git-scm.com\/book\/en\/v2\/images\/commits-and-parents.png)\n\nFigure 10. Commits and their parents\n\nA branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is `master`. As you start making commits, you’re given a `master` branch that points to the last commit you made. Every time you commit, the `master` branch pointer moves forward automatically.\n\n|   |   |\n|---|---|\n| Note | The “master” branch in Git is not a special branch. It is exactly like any other branch. The only reason nearly every repository has one is that the `git init` command creates it by default and most people don’t bother to change it. |\n\n![A branch and its commit history](https:\/\/git-scm.com\/book\/en\/v2\/images\/branch-and-history.png)\n\nFigure 11. A branch and its commit history\n\n### Creating a New Branch\nWhat happens when you create a new branch? Well, doing so creates a new pointer for you to move around. Let’s say you want to create a new branch called `testing`. You do this with the `git branch` command:\n```\n$ git branch testing\n```\nThis creates a new pointer to the same commit you’re currently on.\n\n![Two branches pointing into the same series of commits](https:\/\/git-scm.com\/book\/en\/v2\/images\/two-branches.png)\n\nFigure 12. Two branches pointing into the same series of commits\n\nHow does Git know what branch you’re currently on? It keeps a special pointer called `HEAD`. Note that this is a lot different than the concept of `HEAD` in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on `master`. The `git branch` command only *created* a new branch — it didn’t switch to that branch.\n\n![HEAD pointing to a branch](https:\/\/git-scm.com\/book\/en\/v2\/images\/head-to-master.png)\n\nFigure 13. HEAD pointing to a branch\n\nYou can easily see this by running a simple `git log` command that shows you where the branch pointers are pointing. This option is called `--decorate`.\n```\n$ git log --oneline --decorate\nf30ab (HEAD -> master, testing) Add feature #32 - ability to add new formats to the central interface\n34ac2 Fix bug #1328 - stack overflow under certain conditions\n98ca9 Initial commit\n```\nYou can see the `master` and `testing` branches that are right there next to the `f30ab` commit.\n\n### Switching Branches\nTo switch to an existing branch, you run the `git checkout` command. Let’s switch to the new `testing` branch:\n```\n$ git checkout testing\n```\nThis moves `HEAD` to point to the `testing` branch.\n\n![HEAD points to the current branch](https:\/\/git-scm.com\/book\/en\/v2\/images\/head-to-testing.png)\n\nFigure 14. HEAD points to the current branch\n\nWhat is the significance of that? Well, let’s do another commit:\n```\n$ vim test.rb\n$ git commit -a -m 'Make a change'\n```\n![The HEAD branch moves forward when a commit is made](https:\/\/git-scm.com\/book\/en\/v2\/images\/advance-testing.png)\n\nFigure 15. The HEAD branch moves forward when a commit is made\n\nThis is interesting, because now your `testing` branch has moved forward, but your `master` branch still points to the commit you were on when you ran `git checkout` to switch branches. Let’s switch back to the `master` branch:\n```\n$ git checkout master\n```\n|   |   |\n|---|---|\n| Note | `git log` doesn’t show *all* the branches *all* the time If you were to run `git log` right now, you might wonder where the \"testing\" branch you just created went, as it would not appear in the output. The branch hasn’t disappeared; Git just doesn’t know that you’re interested in that branch and it is trying to show you what it thinks you’re interested in. In other words, by default, `git log` will only show commit history below the branch you’ve checked out. To show commit history for the desired branch you have to explicitly specify it: `git log testing`. To show all of the branches, add `--all` to your `git log` command. |\n\n![HEAD moves when you checkout](https:\/\/git-scm.com\/book\/en\/v2\/images\/checkout-master.png)\n\nFigure 16. HEAD moves when you checkout\n\nThat command did two things. It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your `testing` branch so you can go in a different direction.\n\n|   |   |\n|---|---|\n| Note | Switching branches changes files in your working directory It’s important to note that when you switch branches in Git, files in your working directory will change. If you switch to an older branch, your working directory will be reverted to look like it did the last time you committed on that branch. If Git cannot do it cleanly, it will not let you switch at all. |\n\nLet’s make a few changes and commit again:\n```\n$ vim test.rb\n$ git commit -a -m 'Make other changes'\n```\nNow your project history has diverged (see [Divergent history](https:\/\/git-scm.com\/book\/en\/v2\/ch00\/divergent_history)). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple `branch`, `checkout`, and `commit` commands.\n\n![Divergent history](https:\/\/git-scm.com\/book\/en\/v2\/images\/advance-master.png)\n\nFigure 17. Divergent history\n\nYou can also see this easily with the `git log` command. If you run `git log --oneline --decorate --graph --all` it will print out the history of your commits, showing where your branch pointers are and how your history has diverged.\n```\n$ git log --oneline --decorate --graph --all\n* c2b9e (HEAD, master) Make other changes\n| * 87ab2 (testing) Make a change\n|\/\n* f30ab Add feature #32 - ability to add new formats to the central interface\n* 34ac2 Fix bug #1328 - stack overflow under certain conditions\n* 98ca9 Initial commit of my project\n```\nBecause a branch in Git is actually a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).\n\nThis is in sharp contrast to the way most older VCS tools branch, which involves copying all of the project’s files into a second directory. This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. Also, because we’re recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. These features help encourage developers to create and use branches often.\n\nLet’s see why you should do so.\n\n|   |   |\n|---|---|\n| Note | Creating a new branch and switching to it at the same time It’s typical to create a new branch and want to switch to that new branch at the same time — this can be done in one operation with `git checkout -b <newbranchname>`. |\n\n|   |   |\n|---|---|\n| Note | From Git version 2.23 onwards you can use `git switch` instead of `git checkout` to: Switch to an existing branch: `git switch testing-branch`. Create a new branch and switch to it: `git switch -c new-branch`. The `-c` flag stands for create, you can also use the full flag: `--create`. Return to your previously checked out branch: `git switch -`. |\n\n[prev](https:\/\/git-scm.com\/book\/en\/v2\/Git-Basics-Summary) \\| [next](https:\/\/git-scm.com\/book\/en\/v2\/Git-Branching-Basic-Branching-and-Merging)\n\n[About this site](https:\/\/git-scm.com\/site)  \n Patches, suggestions, and comments are welcome.\n\nGit is a member of [Software Freedom Conservancy](https:\/\/git-scm.com\/sfc)","attrs_readable_markdown":"Nearly every VCS has some form of branching support. Branching means you diverge from the main line of development and continue to do work without messing with that main line. In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects.\n\nSome people refer to Git’s branching model as its “killer feature,” and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop.\n\nTo really understand the way Git does branching, we need to take a step back and examine how Git stores its data.\n\nAs you may remember from [What is Git?](https:\/\/git-scm.com\/book\/en\/v2\/ch00\/what_is_git_section), Git doesn’t store data as a series of changesets or differences, but instead as a series of *snapshots*.\n\nWhen you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged. This object also contains the author’s name and email address, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.\n\nTo visualize this, let’s assume that you have a directory containing three files, and you stage them all and commit. Staging the files computes a checksum for each one (the SHA-1 hash we mentioned in [What is Git?](https:\/\/git-scm.com\/book\/en\/v2\/ch00\/what_is_git_section)), stores that version of the file in the Git repository (Git refers to them as *blobs*), and adds that checksum to the staging area:\n```\n$ git add README test.rb LICENSE\n$ git commit -m 'Initial commit'\n```\nWhen you create the commit by running `git commit`, Git checksums each subdirectory (in this case, just the root project directory) and stores them as a tree object in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.\n\nYour Git repository now contains five objects: three *blobs* (each representing the contents of one of the three files), one *tree* that lists the contents of the directory and specifies which file names are stored as which blobs, and one *commit* with the pointer to that root tree and all the commit metadata.\n\n![A commit and its tree](https:\/\/git-scm.com\/book\/en\/v2\/images\/commit-and-tree.png)\n\nFigure 9. A commit and its tree\n\nIf you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it.\n\n![Commits and their parents](https:\/\/git-scm.com\/book\/en\/v2\/images\/commits-and-parents.png)\n\nFigure 10. Commits and their parents\n\nA branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is `master`. As you start making commits, you’re given a `master` branch that points to the last commit you made. Every time you commit, the `master` branch pointer moves forward automatically.\n\n|   |   |\n|---|---|\n| Note | The “master” branch in Git is not a special branch. It is exactly like any other branch. The only reason nearly every repository has one is that the `git init` command creates it by default and most people don’t bother to change it. |\n\n![A branch and its commit history](https:\/\/git-scm.com\/book\/en\/v2\/images\/branch-and-history.png)\n\nFigure 11. A branch and its commit history\n\n### Creating a New Branch\nWhat happens when you create a new branch? Well, doing so creates a new pointer for you to move around. Let’s say you want to create a new branch called `testing`. You do this with the `git branch` command:\n```\n$ git branch testing\n```\nThis creates a new pointer to the same commit you’re currently on.\n\n![Two branches pointing into the same series of commits](https:\/\/git-scm.com\/book\/en\/v2\/images\/two-branches.png)\n\nFigure 12. Two branches pointing into the same series of commits\n\nHow does Git know what branch you’re currently on? It keeps a special pointer called `HEAD`. Note that this is a lot different than the concept of `HEAD` in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on `master`. The `git branch` command only *created* a new branch — it didn’t switch to that branch.\n\n![HEAD pointing to a branch](https:\/\/git-scm.com\/book\/en\/v2\/images\/head-to-master.png)\n\nFigure 13. HEAD pointing to a branch\n\nYou can easily see this by running a simple `git log` command that shows you where the branch pointers are pointing. This option is called `--decorate`.\n```\n$ git log --oneline --decorate\nf30ab (HEAD -> master, testing) Add feature #32 - ability to add new formats to the central interface\n34ac2 Fix bug #1328 - stack overflow under certain conditions\n98ca9 Initial commit\n```\nYou can see the `master` and `testing` branches that are right there next to the `f30ab` commit.\n\n### Switching Branches\nTo switch to an existing branch, you run the `git checkout` command. Let’s switch to the new `testing` branch:\n```\n$ git checkout testing\n```\nThis moves `HEAD` to point to the `testing` branch.\n\n![HEAD points to the current branch](https:\/\/git-scm.com\/book\/en\/v2\/images\/head-to-testing.png)\n\nFigure 14. HEAD points to the current branch\n\nWhat is the significance of that? Well, let’s do another commit:\n```\n$ vim test.rb\n$ git commit -a -m 'Make a change'\n```\n![The HEAD branch moves forward when a commit is made](https:\/\/git-scm.com\/book\/en\/v2\/images\/advance-testing.png)\n\nFigure 15. The HEAD branch moves forward when a commit is made\n\nThis is interesting, because now your `testing` branch has moved forward, but your `master` branch still points to the commit you were on when you ran `git checkout` to switch branches. Let’s switch back to the `master` branch:\n```\n$ git checkout master\n```\n|   |   |\n|---|---|\n| Note | `git log` doesn’t show *all* the branches *all* the time If you were to run `git log` right now, you might wonder where the \"testing\" branch you just created went, as it would not appear in the output. The branch hasn’t disappeared; Git just doesn’t know that you’re interested in that branch and it is trying to show you what it thinks you’re interested in. In other words, by default, `git log` will only show commit history below the branch you’ve checked out. To show commit history for the desired branch you have to explicitly specify it: `git log testing`. To show all of the branches, add `--all` to your `git log` command. |\n\n![HEAD moves when you checkout](https:\/\/git-scm.com\/book\/en\/v2\/images\/checkout-master.png)\n\nFigure 16. HEAD moves when you checkout\n\nThat command did two things. It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your `testing` branch so you can go in a different direction.\n\n|   |   |\n|---|---|\n| Note | Switching branches changes files in your working directory It’s important to note that when you switch branches in Git, files in your working directory will change. If you switch to an older branch, your working directory will be reverted to look like it did the last time you committed on that branch. If Git cannot do it cleanly, it will not let you switch at all. |\n\nLet’s make a few changes and commit again:\n```\n$ vim test.rb\n$ git commit -a -m 'Make other changes'\n```\nNow your project history has diverged (see [Divergent history](https:\/\/git-scm.com\/book\/en\/v2\/ch00\/divergent_history)). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple `branch`, `checkout`, and `commit` commands.\n\n![Divergent history](https:\/\/git-scm.com\/book\/en\/v2\/images\/advance-master.png)\n\nFigure 17. Divergent history\n\nYou can also see this easily with the `git log` command. If you run `git log --oneline --decorate --graph --all` it will print out the history of your commits, showing where your branch pointers are and how your history has diverged.\n```\n$ git log --oneline --decorate --graph --all\n* c2b9e (HEAD, master) Make other changes\n| * 87ab2 (testing) Make a change\n|\/\n* f30ab Add feature #32 - ability to add new formats to the central interface\n* 34ac2 Fix bug #1328 - stack overflow under certain conditions\n* 98ca9 Initial commit of my project\n```\nBecause a branch in Git is actually a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).\n\nThis is in sharp contrast to the way most older VCS tools branch, which involves copying all of the project’s files into a second directory. This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. Also, because we’re recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. These features help encourage developers to create and use branches often.\n\nLet’s see why you should do so.\n\n|   |   |\n|---|---|\n| Note | Creating a new branch and switching to it at the same time It’s typical to create a new branch and want to switch to that new branch at the same time — this can be done in one operation with `git checkout -b <newbranchname>`. |\n\n|   |   |\n|---|---|\n| Note | From Git version 2.23 onwards you can use `git switch` instead of `git checkout` to: Switch to an existing branch: `git switch testing-branch`. Create a new branch and switch to it: `git switch -c new-branch`. The `-c` flag stands for create, you can also use the full flag: `--create`. Return to your previously checked out branch: `git switch -`. |","meta_canonical":null}

3. Robots.txt Check

Query:

Response:

4. Spam/Ban Check

Query:

Response:

5. Seen Status Check

ℹ️ Skipped - page is already crawled

📄

INDEXABLE

✅

CRAWLED

15 hours ago

🤖

ROBOTS ALLOWED

Page Info Filters

Filter	Status	Condition	Details
HTTP status	PASS	`download_http_code = 200`	HTTP 200
Age cutoff	PASS	`download_stamp > now() - 6 MONTH`	0 months ago
History drop	PASS	`isNull(history_drop_reason)`	No drop reason
Spam/ban	PASS	`fh_dont_index != 1 AND ml_spam_score = 0`	ml_spam_score=0
Canonical	PASS	`meta_canonical IS NULL OR = '' OR = src_unparsed`	Not set

Page Details

Property	Value
URL	https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell
Last Crawled	2026-04-12 07:10:40 (15 hours ago)
First Indexed	2014-10-27 12:00:30 (11 years ago)
HTTP Status Code	200
Meta Title	Git - Branches in a Nutshell
Meta Description	null
Meta Canonical	null
Boilerpipe Text	Nearly every VCS has some form of branching support. Branching means you diverge from the main line of development and continue to do work without messing with that main line. In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects. Some people refer to Git’s branching model as its “killer feature,” and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop. 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 What is Git? , Git doesn’t store data as a series of changesets or differences, but instead as a series of snapshots . When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged. This object also contains the author’s name and email address, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches. To visualize this, let’s assume that you have a directory containing three files, and you stage them all and commit. Staging the files computes a checksum for each one (the SHA-1 hash we mentioned in What is Git? ), stores that version of the file in the Git repository (Git refers to them as blobs ), and adds that checksum to the staging area: $ git add README test.rb LICENSE $ git commit -m 'Initial commit' When you create the commit by running git commit , Git checksums each subdirectory (in this case, just the root project directory) and stores them as a tree object in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed. Your Git repository now contains five objects: three blobs (each representing the contents of one of the three files), one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. Figure 9. A commit and its tree If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it. Figure 10. Commits and their parents 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 start making commits, you’re given a master branch that points to the last commit you made. Every time you commit, the master branch pointer moves forward automatically. Note The “master” branch in Git is not a special branch. It is exactly like any other branch. The only reason nearly every repository has one is that the git init command creates it by default and most people don’t bother to change it. Figure 11. A branch and its commit history Creating a New Branch What happens when you create a new branch? Well, doing so creates a new pointer for you to move around. Let’s say you want to create a new branch called testing . You do this with the git branch command: $ git branch testing This creates a new pointer to the same commit you’re currently on. Figure 12. Two branches pointing into the same series of commits How does Git know what branch you’re currently on? It keeps a special pointer called HEAD . Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master . The git branch command only created a new branch — it didn’t switch to that branch. Figure 13. HEAD pointing to a branch You can easily see this by running a simple git log command that shows you where the branch pointers are pointing. This option is called --decorate . $ git log --oneline --decorate f30ab (HEAD -> master, testing) Add feature #32 - ability to add new formats to the central interface 34ac2 Fix bug #1328 - stack overflow under certain conditions 98ca9 Initial commit You can see the master and testing branches that are right there next to the f30ab commit. Switching Branches To switch to an existing branch, you run the git checkout command. Let’s switch to the new testing branch: $ git checkout testing This moves HEAD to point to the testing branch. Figure 14. HEAD points to the current branch What is the significance of that? Well, let’s do another commit: $ vim test.rb $ git commit -a -m 'Make a change' Figure 15. The HEAD branch moves forward when a commit is made This is interesting, because now your testing branch has moved forward, but your master branch still points to the commit you were on when you ran git checkout to switch branches. Let’s switch back to the master branch: $ git checkout master Note git log doesn’t show all the branches all the time If you were to run git log right now, you might wonder where the "testing" branch you just created went, as it would not appear in the output. The branch hasn’t disappeared; Git just doesn’t know that you’re interested in that branch and it is trying to show you what it thinks you’re interested in. In other words, by default, git log will only show commit history below the branch you’ve checked out. To show commit history for the desired branch you have to explicitly specify it: git log testing . To show all of the branches, add --all to your git log command. Figure 16. HEAD moves when you checkout That command did two things. It moved the HEAD pointer back to point to the master branch, and it reverted the files in your working directory back to the snapshot that master points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your testing branch so you can go in a different direction. Note Switching branches changes files in your working directory It’s important to note that when you switch branches in Git, files in your working directory will change. If you switch to an older branch, your working directory will be reverted to look like it did the last time you committed on that branch. If Git cannot do it cleanly, it will not let you switch at all. Let’s make a few changes and commit again: $ vim test.rb $ git commit -a -m 'Make other changes' Now your project history has diverged (see Divergent history ). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple branch , checkout , and commit commands. Figure 17. Divergent history You can also see this easily with the git log command. If you run git log --oneline --decorate --graph --all it will print out the history of your commits, showing where your branch pointers are and how your history has diverged. $ git log --oneline --decorate --graph --all * c2b9e (HEAD, master) Make other changes \| * 87ab2 (testing) Make a change \|/ * f30ab Add feature #32 - ability to add new formats to the central interface * 34ac2 Fix bug #1328 - stack overflow under certain conditions * 98ca9 Initial commit of my project Because a branch in Git is actually a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline). This is in sharp contrast to the way most older VCS tools branch, which involves copying all of the project’s files into a second directory. This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. Also, because we’re recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. These features help encourage developers to create and use branches often. Let’s see why you should do so. Note Creating a new branch and switching to it at the same time It’s typical to create a new branch and want to switch to that new branch at the same time — this can be done in one operation with git checkout -b <newbranchname> . Note From Git version 2.23 onwards you can use git switch instead of git checkout to: Switch to an existing branch: git switch testing-branch . Create a new branch and switch to it: git switch -c new-branch . The -c flag stands for create, you can also use the full flag: --create . Return to your previously checked out branch: git switch - .
Markdown	[![Git](https://git-scm.com/images/logo@2x.png)](https://git-scm.com/) \--distributed-is-the-new-centralized ![](https://git-scm.com/images/dark-mode.svg) - [About](https://git-scm.com/about) - [Trademark](https://git-scm.com/about/trademark) - [Learn](https://git-scm.com/learn) - [Book](https://git-scm.com/book) - [Cheat Sheet](https://git-scm.com/cheat-sheet) - [Videos](https://git-scm.com/videos) - [External Links](https://git-scm.com/doc/ext) - [Tools](https://git-scm.com/tools) - [Command Line](https://git-scm.com/tools/command-line) - [GUIs](https://git-scm.com/tools/guis) - [Hosting](https://git-scm.com/tools/hosting) - [Reference](https://git-scm.com/docs) - [Install](https://git-scm.com/install/linux) - [Community](https://git-scm.com/community) * This book is available in [English](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell). Full translation available in \| \| \|---\| \| [azərbaycan dili](https://git-scm.com/book/az/v2/Git%E2%80%99d%C9%99-Branch-Nutshell%E2%80%99d%C9%99-Branch%E2%80%99lar), \| \| [български език](https://git-scm.com/book/bg/v2/%D0%9A%D0%BB%D0%BE%D0%BD%D0%BE%D0%B2%D0%B5-%D0%B2-Git-%D0%9D%D0%B0%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE-%D0%B7%D0%B0-%D1%80%D0%B0%D0%B7%D0%BA%D0%BB%D0%BE%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F%D1%82%D0%B0), \| \| [Deutsch](https://git-scm.com/book/de/v2/Git-Branching-Branches-auf-einen-Blick), \| \| [Español](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-%C2%BFQu%C3%A9-es-una-rama), \| \| [فارسی](https://git-scm.com/book/fa/v2/%D8%A7%D9%86%D8%B4%D8%B9%D8%A7%D8%A8%E2%80%8C%DA%AF%DB%8C%D8%B1%DB%8C-%D8%AF%D8%B1-%DA%AF%DB%8C%D8%AA-Git-Branching-%D8%B4%D8%A7%D8%AE%D9%87%E2%80%8C%D9%87%D8%A7-%D8%AF%D8%B1-%DB%8C%DA%A9-%D9%86%DA%AF%D8%A7%D9%87-Branches-in-a-Nutshell), \| \| [Français](https://git-scm.com/book/fr/v2/Les-branches-avec-Git-Les-branches-en-bref), \| \| [Ελληνικά](https://git-scm.com/book/gr/v2/%CE%94%CE%B9%CE%B1%CE%BA%CE%BB%CE%B1%CE%B4%CF%8E%CF%83%CE%B5%CE%B9%CF%82-%CF%83%CF%84%CE%BF-Git-%CE%9F%CE%B9-%CE%BA%CE%BB%CE%AC%CE%B4%CE%BF%CE%B9-%CE%BC%CE%B5-%CE%BB%CE%AF%CE%B3%CE%B1-%CE%BB%CF%8C%CE%B3%CE%B9%CE%B1), \| \| [日本語](https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%81%A8%E3%81%AF), \| \| [한국어](https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%B8%8C%EB%9E%9C%EC%B9%98%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80), \| \| [Nederlands](https://git-scm.com/book/nl/v2/Branchen-in-Git-Branches-in-vogelvlucht), \| \| [Русский](https://git-scm.com/book/ru/v2/%D0%92%D0%B5%D1%82%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B2-Git-%D0%9E-%D0%B2%D0%B5%D1%82%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B8-%D0%B2-%D0%B4%D0%B2%D1%83%D1%85-%D1%81%D0%BB%D0%BE%D0%B2%D0%B0%D1%85), \| \| [Slovenščina](https://git-scm.com/book/sl/v2/Veje-Git-Veje-na-kratko), \| \| [Српски](https://git-scm.com/book/sr/v2/%D0%93%D1%80%D0%B0%D0%BD%D0%B0%D1%9A%D0%B5-%D1%83-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D1%83-%D0%93%D0%B8%D1%82-%D0%A3%D0%BA%D1%80%D0%B0%D1%82%D0%BA%D0%BE-%D0%BE-%D0%B3%D1%80%D0%B0%D0%BD%D0%B0%D1%9A%D1%83), \| \| [Svenska](https://git-scm.com/book/sv/v2/Git-grenar-Grenar-i-korthet), \| \| [Tagalog](https://git-scm.com/book/tl/v2/Pag-branch-ng-Git-Mga-Branch-sa-Maikling-Salita), \| \| [Türkçe](https://git-scm.com/book/tr/v2/Git-Dallar%C4%B1-Dallar). \| \| [Українська](https://git-scm.com/book/uk/v2/%D0%93%D0%B0%D0%BB%D1%83%D0%B6%D0%B5%D0%BD%D0%BD%D1%8F-%D0%B2-git-%D0%93%D1%96%D0%BB%D0%BA%D0%B8-%D1%83-%D0%BA%D1%96%D0%BB%D1%8C%D0%BA%D0%BE%D1%85-%D1%81%D0%BB%D0%BE%D0%B2%D0%B0%D1%85), \| \| [简体中文](https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%AE%80%E4%BB%8B), \| Partial translations available in \| \| \|---\| \| [Čeština](https://git-scm.com/book/cs/v2/V%C4%9Btve-v-syst%C3%A9mu-Git-V%C4%9Btve-v-kostce), \| \| [Македонски](https://git-scm.com/book/mk/v2/%D0%93%D1%80%D0%B0%D0%BD%D0%B5%D1%9A%D0%B5-%D0%B2%D0%BE-Git-%D0%93%D1%80%D0%B0%D0%BD%D0%B5%D1%9A%D0%B5-%D0%BE%D0%B1%D1%98%D0%B0%D1%81%D0%BD%D0%B5%D1%82%D0%BE), \| \| [Polski](https://git-scm.com/book/pl/v2/Ga%C5%82%C4%99zie-Gita-Czym-jest-ga%C5%82%C4%85%C5%BA), \| \| [Português (Brasil)](https://git-scm.com/book/pt-br/v2/Branches-no-Git-Branches-em-poucas-palavras), \| \| [Ўзбекча](https://git-scm.com/book/uz/v2/Git-%D0%B4%D0%B0-%D1%82%D0%B0%D1%80%D0%BC%D0%BE%D2%9B%D0%BB%D0%B0%D0%BD%D0%B8%D1%88-%D0%A2%D0%B0%D1%80%D0%BC%D0%BE%D2%9B%D0%BB%D0%B0%D0%BD%D0%B8%D1%88-%D2%B3%D0%B0%D2%9B%D0%B8%D0%B4%D0%B0-%D0%B8%D0%BA%D0%BA%D0%B8-%D0%BE%D2%93%D0%B8%D0%B7-%D1%81%D1%9E%D0%B7), \| \| [繁體中文](https://git-scm.com/book/zh-tw/v2/%E4%BD%BF%E7%94%A8-Git-%E5%88%86%E6%94%AF-%E7%B0%A1%E8%BF%B0%E5%88%86%E6%94%AF), \| Translations started for \| \| \|---\| \| [Беларуская](https://git-scm.com/book/be/v2/Git-Branching-Branches-in-a-Nutshell), \| \| [Indonesian](https://git-scm.com/book/id/v2/Git-Branching-Branches-in-a-Nutshell), \| \| [Italiano](https://git-scm.com/book/it/v2/Git-Branching-Branches-in-a-Nutshell), \| \| [Bahasa Melayu](https://git-scm.com/book/ms/v2/Git-Branching-Branches-in-a-Nutshell), \| \| [Português (Portugal)](https://git-scm.com/book/pt-pt/v2/Ramifica%C3%A7%C3%A3o-do-Git-Branches-in-a-Nutshell). \| * The source of this book is [hosted on GitHub.](https://github.com/progit/progit2) Patches, suggestions and comments are welcome. [Chapters ▾](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell) 1. ## 1\. [Getting Started](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control) 1. 1\.1 [About Version Control](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control) 2. 1\.2 [A Short History of Git](https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git) 3. 1\.3 [What is Git?](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F) 4. 1\.4 [The Command Line](https://git-scm.com/book/en/v2/Getting-Started-The-Command-Line) 5. 1\.5 [Installing Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) 6. 1\.6 [First-Time Git Setup](https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup) 7. 1\.7 [Getting Help](https://git-scm.com/book/en/v2/Getting-Started-Getting-Help) 8. 1\.8 [Summary](https://git-scm.com/book/en/v2/Getting-Started-Summary) 2. ## 2\. [Git Basics](https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository) 1. 2\.1 [Getting a Git Repository](https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository) 2. 2\.2 [Recording Changes to the Repository](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository) 3. 2\.3 [Viewing the Commit History](https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History) 4. 2\.4 [Undoing Things](https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things) 5. 2\.5 [Working with Remotes](https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes) 6. 2\.6 [Tagging](https://git-scm.com/book/en/v2/Git-Basics-Tagging) 7. 2\.7 [Git Aliases](https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases) 8. 2\.8 [Summary](https://git-scm.com/book/en/v2/Git-Basics-Summary) 3. ## 3\. [Git Branching](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell) 1. 3\.1 [Branches in a Nutshell](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell) 2. 3\.2 [Basic Branching and Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging) 3. 3\.3 [Branch Management](https://git-scm.com/book/en/v2/Git-Branching-Branch-Management) 4. 3\.4 [Branching Workflows](https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows) 5. 3\.5 [Remote Branches](https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches) 6. 3\.6 [Rebasing](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) 7. 3\.7 [Summary](https://git-scm.com/book/en/v2/Git-Branching-Summary) 4. ## 4\. [Git on the Server](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols) 1. 4\.1 [The Protocols](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols) 2. 4\.2 [Getting Git on a Server](https://git-scm.com/book/en/v2/Git-on-the-Server-Getting-Git-on-a-Server) 3. 4\.3 [Generating Your SSH Public Key](https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key) 4. 4\.4 [Setting Up the Server](https://git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-the-Server) 5. 4\.5 [Git Daemon](https://git-scm.com/book/en/v2/Git-on-the-Server-Git-Daemon) 6. 4\.6 [Smart HTTP](https://git-scm.com/book/en/v2/Git-on-the-Server-Smart-HTTP) 7. 4\.7 [GitWeb](https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb) 8. 4\.8 [GitLab](https://git-scm.com/book/en/v2/Git-on-the-Server-GitLab) 9. 4\.9 [Third Party Hosted Options](https://git-scm.com/book/en/v2/Git-on-the-Server-Third-Party-Hosted-Options) 10. 4\.10 [Summary](https://git-scm.com/book/en/v2/Git-on-the-Server-Summary) 5. ## 5\. [Distributed Git](https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows) 1. 5\.1 [Distributed Workflows](https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows) 2. 5\.2 [Contributing to a Project](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project) 3. 5\.3 [Maintaining a Project](https://git-scm.com/book/en/v2/Distributed-Git-Maintaining-a-Project) 4. 5\.4 [Summary](https://git-scm.com/book/en/v2/Distributed-Git-Summary) 1. ## 6\. [GitHub](https://git-scm.com/book/en/v2/GitHub-Account-Setup-and-Configuration) 1. 6\.1 [Account Setup and Configuration](https://git-scm.com/book/en/v2/GitHub-Account-Setup-and-Configuration) 2. 6\.2 [Contributing to a Project](https://git-scm.com/book/en/v2/GitHub-Contributing-to-a-Project) 3. 6\.3 [Maintaining a Project](https://git-scm.com/book/en/v2/GitHub-Maintaining-a-Project) 4. 6\.4 [Managing an organization](https://git-scm.com/book/en/v2/GitHub-Managing-an-organization) 5. 6\.5 [Scripting GitHub](https://git-scm.com/book/en/v2/GitHub-Scripting-GitHub) 6. 6\.6 [Summary](https://git-scm.com/book/en/v2/GitHub-Summary) 2. ## 7\. [Git Tools](https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection) 1. 7\.1 [Revision Selection](https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection) 2. 7\.2 [Interactive Staging](https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging) 3. 7\.3 [Stashing and Cleaning](https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning) 4. 7\.4 [Signing Your Work](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work) 5. 7\.5 [Searching](https://git-scm.com/book/en/v2/Git-Tools-Searching) 6. 7\.6 [Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) 7. 7\.7 [Reset Demystified](https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified) 8. 7\.8 [Advanced Merging](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging) 9. 7\.9 [Rerere](https://git-scm.com/book/en/v2/Git-Tools-Rerere) 10. 7\.10 [Debugging with Git](https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git) 11. 7\.11 [Submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules) 12. 7\.12 [Bundling](https://git-scm.com/book/en/v2/Git-Tools-Bundling) 13. 7\.13 [Replace](https://git-scm.com/book/en/v2/Git-Tools-Replace) 14. 7\.14 [Credential Storage](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage) 15. 7\.15 [Summary](https://git-scm.com/book/en/v2/Git-Tools-Summary) 3. ## 8\. [Customizing Git](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration) 1. 8\.1 [Git Configuration](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration) 2. 8\.2 [Git Attributes](https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes) 3. 8\.3 [Git Hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) 4. 8\.4 [An Example Git-Enforced Policy](https://git-scm.com/book/en/v2/Customizing-Git-An-Example-Git-Enforced-Policy) 5. 8\.5 [Summary](https://git-scm.com/book/en/v2/Customizing-Git-Summary) 4. ## 9\. [Git and Other Systems](https://git-scm.com/book/en/v2/Git-and-Other-Systems-Git-as-a-Client) 1. 9\.1 [Git as a Client](https://git-scm.com/book/en/v2/Git-and-Other-Systems-Git-as-a-Client) 2. 9\.2 [Migrating to Git](https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git) 3. 9\.3 [Summary](https://git-scm.com/book/en/v2/Git-and-Other-Systems-Summary) 5. ## 10\. [Git Internals](https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain) 1. 10\.1 [Plumbing and Porcelain](https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain) 2. 10\.2 [Git Objects](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects) 3. 10\.3 [Git References](https://git-scm.com/book/en/v2/Git-Internals-Git-References) 4. 10\.4 [Packfiles](https://git-scm.com/book/en/v2/Git-Internals-Packfiles) 5. 10\.5 [The Refspec](https://git-scm.com/book/en/v2/Git-Internals-The-Refspec) 6. 10\.6 [Transfer Protocols](https://git-scm.com/book/en/v2/Git-Internals-Transfer-Protocols) 7. 10\.7 [Maintenance and Data Recovery](https://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery) 8. 10\.8 [Environment Variables](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables) 9. 10\.9 [Summary](https://git-scm.com/book/en/v2/Git-Internals-Summary) 1. ## A1. [Appendix A: Git in Other Environments](https://git-scm.com/book/en/v2/Appendix-A:-Git-in-Other-Environments-Graphical-Interfaces) 1. A1.1 [Graphical Interfaces](https://git-scm.com/book/en/v2/Appendix-A:-Git-in-Other-Environments-Graphical-Interfaces) 2. A1.2 [Git in Visual Studio](https://git-scm.com/book/en/v2/Appendix-A:-Git-in-Other-Environments-Git-in-Visual-Studio) 3. A1.3 [Git in Visual Studio Code](https://git-scm.com/book/en/v2/Appendix-A:-Git-in-Other-Environments-Git-in-Visual-Studio-Code) 4. A1.4 [Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine](https://git-scm.com/book/en/v2/Appendix-A:-Git-in-Other-Environments-Git-in-IntelliJ-/-PyCharm-/-WebStorm-/-PhpStorm-/-RubyMine) 5. A1.5 [Git in Sublime Text](https://git-scm.com/book/en/v2/Appendix-A:-Git-in-Other-Environments-Git-in-Sublime-Text) 6. A1.6 [Git in Bash](https://git-scm.com/book/en/v2/Appendix-A:-Git-in-Other-Environments-Git-in-Bash) 7. A1.7 [Git in Zsh](https://git-scm.com/book/en/v2/Appendix-A:-Git-in-Other-Environments-Git-in-Zsh) 8. A1.8 [Git in PowerShell](https://git-scm.com/book/en/v2/Appendix-A:-Git-in-Other-Environments-Git-in-PowerShell) 9. A1.9 [Summary](https://git-scm.com/book/en/v2/Appendix-A:-Git-in-Other-Environments-Summary) 2. ## A2. [Appendix B: Embedding Git in your Applications](https://git-scm.com/book/en/v2/Appendix-B:-Embedding-Git-in-your-Applications-Command-line-Git) 1. A2.1 [Command-line Git](https://git-scm.com/book/en/v2/Appendix-B:-Embedding-Git-in-your-Applications-Command-line-Git) 2. A2.2 [Libgit2](https://git-scm.com/book/en/v2/Appendix-B:-Embedding-Git-in-your-Applications-Libgit2) 3. A2.3 [JGit](https://git-scm.com/book/en/v2/Appendix-B:-Embedding-Git-in-your-Applications-JGit) 4. A2.4 [go-git](https://git-scm.com/book/en/v2/Appendix-B:-Embedding-Git-in-your-Applications-go-git) 5. A2.5 [Dulwich](https://git-scm.com/book/en/v2/Appendix-B:-Embedding-Git-in-your-Applications-Dulwich) 3. ## A3. [Appendix C: Git Commands](https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Setup-and-Config) 1. A3.1 [Setup and Config](https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Setup-and-Config) 2. A3.2 [Getting and Creating Projects](https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Getting-and-Creating-Projects) 3. A3.3 [Basic Snapshotting](https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Basic-Snapshotting) 4. A3.4 [Branching and Merging](https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Branching-and-Merging) 5. A3.5 [Sharing and Updating Projects](https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Sharing-and-Updating-Projects) 6. A3.6 [Inspection and Comparison](https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Inspection-and-Comparison) 7. A3.7 [Debugging](https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Debugging) 8. A3.8 [Patching](https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Patching) 9. A3.9 [Email](https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Email) 10. A3.10 [External Systems](https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-External-Systems) 11. A3.11 [Administration](https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Administration) 12. A3.12 [Plumbing Commands](https://git-scm.com/book/en/v2/Appendix-C:-Git-Commands-Plumbing-Commands) 2nd Edition # 3\.1 Git Branching - Branches in a Nutshell Nearly every VCS has some form of branching support. Branching means you diverge from the main line of development and continue to do work without messing with that main line. In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects. Some people refer to Git’s branching model as its “killer feature,” and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop. ## Branches in a Nutshell 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 [What is Git?](https://git-scm.com/book/en/v2/ch00/what_is_git_section), Git doesn’t store data as a series of changesets or differences, but instead as a series of snapshots. When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged. This object also contains the author’s name and email address, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches. To visualize this, let’s assume that you have a directory containing three files, and you stage them all and commit. Staging the files computes a checksum for each one (the SHA-1 hash we mentioned in [What is Git?](https://git-scm.com/book/en/v2/ch00/what_is_git_section)), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area: ``` $ git add README test.rb LICENSE $ git commit -m 'Initial commit' ``` When you create the commit by running `git commit`, Git checksums each subdirectory (in this case, just the root project directory) and stores them as a tree object in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed. Your Git repository now contains five objects: three blobs (each representing the contents of one of the three files), one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. ![A commit and its tree](https://git-scm.com/book/en/v2/images/commit-and-tree.png) Figure 9. A commit and its tree If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it. ![Commits and their parents](https://git-scm.com/book/en/v2/images/commits-and-parents.png) Figure 10. Commits and their parents 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 start making commits, you’re given a `master` branch that points to the last commit you made. Every time you commit, the `master` branch pointer moves forward automatically. \| \| \| \|---\|---\| \| Note \| The “master” branch in Git is not a special branch. It is exactly like any other branch. The only reason nearly every repository has one is that the `git init` command creates it by default and most people don’t bother to change it. \| ![A branch and its commit history](https://git-scm.com/book/en/v2/images/branch-and-history.png) Figure 11. A branch and its commit history ### Creating a New Branch What happens when you create a new branch? Well, doing so creates a new pointer for you to move around. Let’s say you want to create a new branch called `testing`. You do this with the `git branch` command: ``` $ git branch testing ``` This creates a new pointer to the same commit you’re currently on. ![Two branches pointing into the same series of commits](https://git-scm.com/book/en/v2/images/two-branches.png) Figure 12. Two branches pointing into the same series of commits How does Git know what branch you’re currently on? It keeps a special pointer called `HEAD`. Note that this is a lot different than the concept of `HEAD` in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on `master`. The `git branch` command only created a new branch — it didn’t switch to that branch. ![HEAD pointing to a branch](https://git-scm.com/book/en/v2/images/head-to-master.png) Figure 13. HEAD pointing to a branch You can easily see this by running a simple `git log` command that shows you where the branch pointers are pointing. This option is called `--decorate`. ``` $ git log --oneline --decorate f30ab (HEAD -> master, testing) Add feature #32 - ability to add new formats to the central interface 34ac2 Fix bug #1328 - stack overflow under certain conditions 98ca9 Initial commit ``` You can see the `master` and `testing` branches that are right there next to the `f30ab` commit. ### Switching Branches To switch to an existing branch, you run the `git checkout` command. Let’s switch to the new `testing` branch: ``` $ git checkout testing ``` This moves `HEAD` to point to the `testing` branch. ![HEAD points to the current branch](https://git-scm.com/book/en/v2/images/head-to-testing.png) Figure 14. HEAD points to the current branch What is the significance of that? Well, let’s do another commit: ``` $ vim test.rb $ git commit -a -m 'Make a change' ``` ![The HEAD branch moves forward when a commit is made](https://git-scm.com/book/en/v2/images/advance-testing.png) Figure 15. The HEAD branch moves forward when a commit is made This is interesting, because now your `testing` branch has moved forward, but your `master` branch still points to the commit you were on when you ran `git checkout` to switch branches. Let’s switch back to the `master` branch: ``` $ git checkout master ``` \| \| \| \|---\|---\| \| Note \| `git log` doesn’t show all the branches all the time If you were to run `git log` right now, you might wonder where the "testing" branch you just created went, as it would not appear in the output. The branch hasn’t disappeared; Git just doesn’t know that you’re interested in that branch and it is trying to show you what it thinks you’re interested in. In other words, by default, `git log` will only show commit history below the branch you’ve checked out. To show commit history for the desired branch you have to explicitly specify it: `git log testing`. To show all of the branches, add `--all` to your `git log` command. \| ![HEAD moves when you checkout](https://git-scm.com/book/en/v2/images/checkout-master.png) Figure 16. HEAD moves when you checkout That command did two things. It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your `testing` branch so you can go in a different direction. \| \| \| \|---\|---\| \| Note \| Switching branches changes files in your working directory It’s important to note that when you switch branches in Git, files in your working directory will change. If you switch to an older branch, your working directory will be reverted to look like it did the last time you committed on that branch. If Git cannot do it cleanly, it will not let you switch at all. \| Let’s make a few changes and commit again: ``` $ vim test.rb $ git commit -a -m 'Make other changes' ``` Now your project history has diverged (see [Divergent history](https://git-scm.com/book/en/v2/ch00/divergent_history)). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple `branch`, `checkout`, and `commit` commands. ![Divergent history](https://git-scm.com/book/en/v2/images/advance-master.png) Figure 17. Divergent history You can also see this easily with the `git log` command. If you run `git log --oneline --decorate --graph --all` it will print out the history of your commits, showing where your branch pointers are and how your history has diverged. ``` $ git log --oneline --decorate --graph --all * c2b9e (HEAD, master) Make other changes \| * 87ab2 (testing) Make a change \|/ * f30ab Add feature #32 - ability to add new formats to the central interface * 34ac2 Fix bug #1328 - stack overflow under certain conditions * 98ca9 Initial commit of my project ``` Because a branch in Git is actually a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline). This is in sharp contrast to the way most older VCS tools branch, which involves copying all of the project’s files into a second directory. This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. Also, because we’re recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. These features help encourage developers to create and use branches often. Let’s see why you should do so. \| \| \| \|---\|---\| \| Note \| Creating a new branch and switching to it at the same time It’s typical to create a new branch and want to switch to that new branch at the same time — this can be done in one operation with `git checkout -b <newbranchname>`. \| \| \| \| \|---\|---\| \| Note \| From Git version 2.23 onwards you can use `git switch` instead of `git checkout` to: Switch to an existing branch: `git switch testing-branch`. Create a new branch and switch to it: `git switch -c new-branch`. The `-c` flag stands for create, you can also use the full flag: `--create`. Return to your previously checked out branch: `git switch -`. \| [prev](https://git-scm.com/book/en/v2/Git-Basics-Summary) \\| [next](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging) [About this site](https://git-scm.com/site) Patches, suggestions, and comments are welcome. Git is a member of [Software Freedom Conservancy](https://git-scm.com/sfc)
Readable Markdown	Nearly every VCS has some form of branching support. Branching means you diverge from the main line of development and continue to do work without messing with that main line. In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects. Some people refer to Git’s branching model as its “killer feature,” and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop. 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 [What is Git?](https://git-scm.com/book/en/v2/ch00/what_is_git_section), Git doesn’t store data as a series of changesets or differences, but instead as a series of snapshots. When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged. This object also contains the author’s name and email address, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches. To visualize this, let’s assume that you have a directory containing three files, and you stage them all and commit. Staging the files computes a checksum for each one (the SHA-1 hash we mentioned in [What is Git?](https://git-scm.com/book/en/v2/ch00/what_is_git_section)), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area: ``` $ git add README test.rb LICENSE $ git commit -m 'Initial commit' ``` When you create the commit by running `git commit`, Git checksums each subdirectory (in this case, just the root project directory) and stores them as a tree object in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed. Your Git repository now contains five objects: three blobs (each representing the contents of one of the three files), one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. ![A commit and its tree](https://git-scm.com/book/en/v2/images/commit-and-tree.png) Figure 9. A commit and its tree If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it. ![Commits and their parents](https://git-scm.com/book/en/v2/images/commits-and-parents.png) Figure 10. Commits and their parents 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 start making commits, you’re given a `master` branch that points to the last commit you made. Every time you commit, the `master` branch pointer moves forward automatically. \| \| \| \|---\|---\| \| Note \| The “master” branch in Git is not a special branch. It is exactly like any other branch. The only reason nearly every repository has one is that the `git init` command creates it by default and most people don’t bother to change it. \| ![A branch and its commit history](https://git-scm.com/book/en/v2/images/branch-and-history.png) Figure 11. A branch and its commit history ### Creating a New Branch What happens when you create a new branch? Well, doing so creates a new pointer for you to move around. Let’s say you want to create a new branch called `testing`. You do this with the `git branch` command: ``` $ git branch testing ``` This creates a new pointer to the same commit you’re currently on. ![Two branches pointing into the same series of commits](https://git-scm.com/book/en/v2/images/two-branches.png) Figure 12. Two branches pointing into the same series of commits How does Git know what branch you’re currently on? It keeps a special pointer called `HEAD`. Note that this is a lot different than the concept of `HEAD` in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on `master`. The `git branch` command only created a new branch — it didn’t switch to that branch. ![HEAD pointing to a branch](https://git-scm.com/book/en/v2/images/head-to-master.png) Figure 13. HEAD pointing to a branch You can easily see this by running a simple `git log` command that shows you where the branch pointers are pointing. This option is called `--decorate`. ``` $ git log --oneline --decorate f30ab (HEAD -> master, testing) Add feature #32 - ability to add new formats to the central interface 34ac2 Fix bug #1328 - stack overflow under certain conditions 98ca9 Initial commit ``` You can see the `master` and `testing` branches that are right there next to the `f30ab` commit. ### Switching Branches To switch to an existing branch, you run the `git checkout` command. Let’s switch to the new `testing` branch: ``` $ git checkout testing ``` This moves `HEAD` to point to the `testing` branch. ![HEAD points to the current branch](https://git-scm.com/book/en/v2/images/head-to-testing.png) Figure 14. HEAD points to the current branch What is the significance of that? Well, let’s do another commit: ``` $ vim test.rb $ git commit -a -m 'Make a change' ``` ![The HEAD branch moves forward when a commit is made](https://git-scm.com/book/en/v2/images/advance-testing.png) Figure 15. The HEAD branch moves forward when a commit is made This is interesting, because now your `testing` branch has moved forward, but your `master` branch still points to the commit you were on when you ran `git checkout` to switch branches. Let’s switch back to the `master` branch: ``` $ git checkout master ``` \| \| \| \|---\|---\| \| Note \| `git log` doesn’t show all the branches all the time If you were to run `git log` right now, you might wonder where the "testing" branch you just created went, as it would not appear in the output. The branch hasn’t disappeared; Git just doesn’t know that you’re interested in that branch and it is trying to show you what it thinks you’re interested in. In other words, by default, `git log` will only show commit history below the branch you’ve checked out. To show commit history for the desired branch you have to explicitly specify it: `git log testing`. To show all of the branches, add `--all` to your `git log` command. \| ![HEAD moves when you checkout](https://git-scm.com/book/en/v2/images/checkout-master.png) Figure 16. HEAD moves when you checkout That command did two things. It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your `testing` branch so you can go in a different direction. \| \| \| \|---\|---\| \| Note \| Switching branches changes files in your working directory It’s important to note that when you switch branches in Git, files in your working directory will change. If you switch to an older branch, your working directory will be reverted to look like it did the last time you committed on that branch. If Git cannot do it cleanly, it will not let you switch at all. \| Let’s make a few changes and commit again: ``` $ vim test.rb $ git commit -a -m 'Make other changes' ``` Now your project history has diverged (see [Divergent history](https://git-scm.com/book/en/v2/ch00/divergent_history)). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple `branch`, `checkout`, and `commit` commands. ![Divergent history](https://git-scm.com/book/en/v2/images/advance-master.png) Figure 17. Divergent history You can also see this easily with the `git log` command. If you run `git log --oneline --decorate --graph --all` it will print out the history of your commits, showing where your branch pointers are and how your history has diverged. ``` $ git log --oneline --decorate --graph --all * c2b9e (HEAD, master) Make other changes \| * 87ab2 (testing) Make a change \|/ * f30ab Add feature #32 - ability to add new formats to the central interface * 34ac2 Fix bug #1328 - stack overflow under certain conditions * 98ca9 Initial commit of my project ``` Because a branch in Git is actually a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline). This is in sharp contrast to the way most older VCS tools branch, which involves copying all of the project’s files into a second directory. This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. Also, because we’re recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. These features help encourage developers to create and use branches often. Let’s see why you should do so. \| \| \| \|---\|---\| \| Note \| Creating a new branch and switching to it at the same time It’s typical to create a new branch and want to switch to that new branch at the same time — this can be done in one operation with `git checkout -b <newbranchname>`. \| \| \| \| \|---\|---\| \| Note \| From Git version 2.23 onwards you can use `git switch` instead of `git checkout` to: Switch to an existing branch: `git switch testing-branch`. Create a new branch and switch to it: `git switch -c new-branch`. The `-c` flag stands for create, you can also use the full flag: `--create`. Return to your previously checked out branch: `git switch -`. \|
Shard	54 (laksa)
Root Hash	7104038400628677254
Unparsed URL	com,git-scm!/book/en/v2/Git-Branching-Branches-in-a-Nutshell s443