🕷️ Crawler Inspector

URL Lookup

Direct Parameter Lookup

Raw Queries and Responses

1. Shard Calculation

Query:

Response:

Calculated Shard: 54 (from laksa060)

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-Basic-Branching-and-Merging\')), getAhrefsUnparsedNoserviceFromURL(\'https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging\'))) FORMAT JSONEachRow'

Response:

{"found_url":"https:\/\/git-scm.com\/book\/en\/v2\/Git-Branching-Basic-Branching-and-Merging","crawl_time":1775476990,"first_indexed_time":1414456633,"http_code":200,"src_unparsed":"com,git-scm!\/book\/en\/v2\/Git-Branching-Basic-Branching-and-Merging s443","src_root_hash":"7104038400628677254","history_drop_reason":null,"meta_title":"Git - Basic Branching and Merging","meta_descriptions":[],"attrs_boilerpipe_text":"Basic Branching and Merging\nLet’s go through a simple example of branching and merging with a workflow that you might use in the real world.\nYou’ll follow these steps:\nDo some work on a website.\nCreate a branch for a new user story you’re working on.\nDo some work in that branch.\nAt this stage, you’ll receive a call that another issue is critical and you need a hotfix.\nYou’ll do the following:\nSwitch to your production branch.\nCreate a branch to add the hotfix.\nAfter it’s tested, merge the hotfix branch, and push to production.\nSwitch back to your original user story and continue working.\nBasic Branching\nFirst, let’s say you’re working on your project and have a couple of commits already on the\nmaster\nbranch.\nFigure 18. A simple commit history\nYou’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses.\nTo create a new branch and switch to it at the same time, you can run the\ngit checkout\ncommand with the\n-b\nswitch:\n$ git checkout -b iss53\nSwitched to a new branch \"iss53\"\nThis is shorthand for:\n$ git branch iss53\n$ git checkout iss53\nFigure 19. Creating a new branch pointer\nYou work on your website and do some commits.\nDoing so moves the\niss53\nbranch forward, because you have it checked out (that is, your\nHEAD\nis pointing to it):\n$ vim index.html\n$ git commit -a -m 'Create new footer [issue 53]'\nFigure 20. The\niss53\nbranch has moved forward with your work\nNow you get the call that there is an issue with the website, and you need to fix it immediately.\nWith Git, you don’t have to deploy your fix along with the\niss53\nchanges you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production.\nAll you have to do is switch back to your\nmaster\nbranch.\nHowever, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches.\nIt’s best to have a clean working state when you switch branches.\nThere are ways to get around this (namely, stashing and commit amending) that we’ll cover later on, in\nStashing and Cleaning\n.\nFor now, let’s assume you’ve committed all your changes, so you can switch back to your\nmaster\nbranch:\n$ git checkout master\nSwitched to branch 'master'\nAt this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix.\nThis is an important point to remember: when you switch branches, Git resets your working directory to look like it did the last time you committed on that branch.\nIt adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it.\nNext, you have a hotfix to make.\nLet’s create a\nhotfix\nbranch on which to work until it’s completed:\n$ git checkout -b hotfix\nSwitched to a new branch 'hotfix'\n$ vim index.html\n$ git commit -a -m 'Fix broken email address'\n[hotfix 1fb7853] Fix broken email address\n 1 file changed, 2 insertions(+)\nFigure 21. Hotfix branch based on\nmaster\nYou can run your tests, make sure the hotfix is what you want, and finally merge the\nhotfix\nbranch back into your\nmaster\nbranch to deploy to production.\nYou do this with the\ngit merge\ncommand:\n$ git checkout master\n$ git merge hotfix\nUpdating f42c576..3a0874c\nFast-forward\n index.html | 2 ++\n 1 file changed, 2 insertions(+)\nYou’ll notice the phrase “fast-forward” in that merge.\nBecause the commit\nC4\npointed to by the branch\nhotfix\nyou merged in was directly ahead of the commit\nC2\nyou’re on, Git simply moves the pointer forward.\nTo phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a “fast-forward.”\nYour change is now in the snapshot of the commit pointed to by the\nmaster\nbranch, and you can deploy the fix.\nFigure 22.\nmaster\nis fast-forwarded to\nhotfix\nAfter your super-important fix is deployed, you’re ready to switch back to the work you were doing before you were interrupted.\nHowever, first you’ll delete the\nhotfix\nbranch, because you no longer need it — the\nmaster\nbranch points at the same place.\nYou can delete it with the\n-d\noption to\ngit branch\n:\n$ git branch -d hotfix\nDeleted branch hotfix (3a0874c).\nNow you can switch back to your work-in-progress branch on issue #53 and continue working on it.\n$ git checkout iss53\nSwitched to branch \"iss53\"\n$ vim index.html\n$ git commit -a -m 'Finish the new footer [issue 53]'\n[iss53 ad82d7a] Finish the new footer [issue 53]\n1 file changed, 1 insertion(+)\nFigure 23. Work continues on\niss53\nIt’s worth noting here that the work you did in your\nhotfix\nbranch is not contained in the files in your\niss53\nbranch.\nIf you need to pull it in, you can merge your\nmaster\nbranch into your\niss53\nbranch by running\ngit merge master\n, or you can wait to integrate those changes until you decide to pull the\niss53\nbranch back into\nmaster\nlater.\nBasic Merging\nSuppose you’ve decided that your issue #53 work is complete and ready to be merged into your\nmaster\nbranch.\nIn order to do that, you’ll merge your\niss53\nbranch into\nmaster\n, much like you merged your\nhotfix\nbranch earlier.\nAll you have to do is check out the branch you wish to merge into and then run the\ngit merge\ncommand:\n$ git checkout master\nSwitched to branch 'master'\n$ git merge iss53\nMerge made by the 'recursive' strategy.\nindex.html |    1 +\n1 file changed, 1 insertion(+)\nThis looks a bit different than the\nhotfix\nmerge you did earlier.\nIn this case, your development history has diverged from some older point.\nBecause the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work.\nIn this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two.\nFigure 24. Three snapshots used in a typical merge\nInstead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it.\nThis is referred to as a merge commit, and is special in that it has more than one parent.\nFigure 25. A merge commit\nNow that your work is merged in, you have no further need for the\niss53\nbranch.\nYou can close the issue in your issue-tracking system, and delete the branch:\n$ git branch -d iss53\nBasic Merge Conflicts\nOccasionally, this process doesn’t go smoothly.\nIf you changed the same part of the same file differently in the two branches you’re merging, Git won’t be able to merge them cleanly.\nIf your fix for issue #53 modified the same part of a file as the\nhotfix\nbranch, you’ll get a merge conflict that looks something like this:\n$ git merge iss53\nAuto-merging index.html\nCONFLICT (content): Merge conflict in index.html\nAutomatic merge failed; fix conflicts and then commit the result.\nGit hasn’t automatically created a new merge commit.\nIt has paused the process while you resolve the conflict.\nIf you want to see which files are unmerged at any point after a merge conflict, you can run\ngit status\n:\n$ git status\nOn branch master\nYou have unmerged paths.\n  (fix conflicts and run \"git commit\")\n\nUnmerged paths:\n  (use \"git add <file>...\" to mark resolution)\n\n    both modified:      index.html\n\nno changes added to commit (use \"git add\" and\/or \"git commit -a\")\nAnything that has merge conflicts and hasn’t been resolved is listed as unmerged.\nGit adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts.\nYour file contains a section that looks something like this:\n<<<<<<< HEAD:index.html\n<div id=\"footer\">contact : email.support@github.com<\/div>\n=======\n<div id=\"footer\">\n please contact us at support@github.com\n<\/div>\n>>>>>>> iss53:index.html\nThis means the version in\nHEAD\n(your\nmaster\nbranch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the\n=======\n), while the version in your\niss53\nbranch looks like everything in the bottom part.\nIn order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself.\nFor instance, you might resolve this conflict by replacing the entire block with this:\n<div id=\"footer\">\nplease contact us at email.support@github.com\n<\/div>\nThis resolution has a little of each section, and the\n<<<<<<<\n,\n=======\n, and\n>>>>>>>\nlines have been completely removed.\nAfter you’ve resolved each of these sections in each conflicted file, run\ngit add\non each file to mark it as resolved.\nStaging the file marks it as resolved in Git.\nIf you want to use a graphical tool to resolve these issues, you can run\ngit mergetool\n, which fires up an appropriate visual merge tool and walks you through the conflicts:\n$ git mergetool\n\nThis message is displayed because 'merge.tool' is not configured.\nSee 'git mergetool --tool-help' or 'git help config' for more details.\n'git mergetool' will now attempt to use one of the following tools:\nopendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge\nMerging:\nindex.html\n\nNormal merge conflict for 'index.html':\n  {local}: modified file\n  {remote}: modified file\nHit return to start merge resolution tool (opendiff):\nIf you want to use a merge tool other than the default (Git chose\nopendiff\nin this case because the command was run on macOS), you can see all the supported tools listed at the top after “one of the following tools.”\nJust type the name of the tool you’d rather use.\nNote\nIf you need more advanced tools for resolving tricky merge conflicts, we cover more on merging in\nAdvanced Merging\n.\nAfter you exit the merge tool, Git asks you if the merge was successful.\nIf you tell the script that it was, it stages the file to mark it as resolved for you.\nYou can run\ngit status\nagain to verify that all conflicts have been resolved:\n$ git status\nOn branch master\nAll conflicts fixed but you are still merging.\n  (use \"git commit\" to conclude merge)\n\nChanges to be committed:\n\n    modified:   index.html\nIf you’re happy with that, and you verify that everything that had conflicts has been staged, you can type\ngit commit\nto finalize the merge commit.\nThe commit message by default looks something like this:\nMerge branch 'iss53'\n\nConflicts:\n    index.html\n#\n# It looks like you may be committing a merge.\n# If this is not correct, please remove the file\n#\t.git\/MERGE_HEAD\n# and try again.\n\n\n# Please enter the commit message for your changes. Lines starting\n# with '#' will be ignored, and an empty message aborts the commit.\n# On branch master\n# All conflicts fixed but you are still merging.\n#\n# Changes to be committed:\n#\tmodified:   index.html\n#\nIf you think it would be helpful to others looking at this merge in the future, you can modify this commit message with details about how you resolved the merge and explain why you did the changes you made if these are not obvious.","attrs_markdown":"[![Git](https:\/\/git-scm.com\/images\/logo@2x.png)](https:\/\/git-scm.com\/) \\--distributed-even-if-your-workflow-isnt\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-Basic-Branching-and-Merging).\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-Sad%C9%99-Branching-v%C9%99-Birl%C9%99%C5%9Fdirm%C9%99), |\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%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%B8-%D0%BD%D0%B0-%D0%BA%D0%BB%D0%BE%D0%BD%D0%BE%D0%B2%D0%B5%D1%82%D0%B5-%D0%BA%D0%BE%D0%B4-%D0%B8-%D1%81%D0%BB%D0%B8%D0%B2%D0%B0%D0%BD%D0%B5%D1%82%D0%BE), |\n| [Deutsch](https:\/\/git-scm.com\/book\/de\/v2\/Git-Branching-Einfaches-Branching-und-Merging), |\n| [Español](https:\/\/git-scm.com\/book\/es\/v2\/Ramificaciones-en-Git-Procedimientos-B%C3%A1sicos-para-Ramificar-y-Fusionar), |\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%D8%A8%D9%86%D8%AF%DB%8C-%D9%88-%D8%A7%D8%AF%D8%BA%D8%A7%D9%85-%D9%BE%D8%A7%DB%8C%D9%87%E2%80%8C%D8%A7%DB%8C-Basic-Branching-and-Merging), |\n| [Français](https:\/\/git-scm.com\/book\/fr\/v2\/Les-branches-avec-Git-Branches-et-fusions%C2%A0:-les-bases), |\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%92%CE%B1%CF%83%CE%B9%CE%BA%CE%AD%CF%82-%CE%AD%CE%BD%CE%BD%CE%BF%CE%B9%CE%B5%CF%82-%CE%B4%CE%B9%CE%B1%CE%BA%CE%BB%CE%B1%CE%B4%CF%8E%CF%83%CE%B5%CF%89%CE%BD-%CE%BA%CE%B1%CE%B9-%CF%83%CF%85%CE%B3%CF%87%CF%89%CE%BD%CE%B5%CF%8D%CF%83%CE%B5%CF%89%CE%BD), |\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%83%9E%E3%83%BC%E3%82%B8%E3%81%AE%E5%9F%BA%E6%9C%AC), |\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%EC%99%80-Merge-%EC%9D%98-%EA%B8%B0%EC%B4%88), |\n| [Nederlands](https:\/\/git-scm.com\/book\/nl\/v2\/Branchen-in-Git-Eenvoudig-branchen-en-mergen), |\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%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-%D0%B2%D0%B5%D1%82%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-%D0%B8-%D1%81%D0%BB%D0%B8%D1%8F%D0%BD%D0%B8%D1%8F), |\n| [Slovenščina](https:\/\/git-scm.com\/book\/sl\/v2\/Veje-Git-Osnove-vej-in-zdru%C5%BEevanja), |\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%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%B5-%D0%B3%D1%80%D0%B0%D0%BD%D0%B0%D1%9A%D0%B0-%D0%B8-%D1%81%D0%BF%D0%B0%D1%98%D0%B0%D1%9A%D0%B0), |\n| [Svenska](https:\/\/git-scm.com\/book\/sv\/v2\/Git-grenar-Grundl%C3%A4ggande-gren--och-sammanfogningsarbete), |\n| [Tagalog](https:\/\/git-scm.com\/book\/tl\/v2\/Pag-branch-ng-Git-Batayan-ng-Pag-branch-at-Pag-merge), |\n| [Türkçe](https:\/\/git-scm.com\/book\/tr\/v2\/Git-Dallar%C4%B1-K%C4%B1saca-Dalland%C4%B1rma-ve-Birle%C5%9Ftirme-Temelleri). |\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%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%B8-%D0%B3%D0%B0%D0%BB%D1%83%D0%B6%D0%B5%D0%BD%D0%BD%D1%8F-%D1%82%D0%B0-%D0%B7%D0%BB%D0%B8%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F), |\n| [简体中文](https:\/\/git-scm.com\/book\/zh\/v2\/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%9A%84%E6%96%B0%E5%BB%BA%E4%B8%8E%E5%90%88%E5%B9%B6), |\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-Z%C3%A1klady-v%C4%9Btven%C3%AD-a-slu%C4%8Dov%C3%A1n%C3%AD), |\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%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D0%BE-%D1%80%D0%B0%D0%B7%D0%B3%D1%80%D0%B0%D0%BD%D1%83%D0%B2%D0%B0%D1%9A%D0%B5-%D0%B8-%D1%81%D0%BF%D0%BE%D1%98%D1%83%D0%B2%D0%B0%D1%9A%D0%B5), |\n| [Polski](https:\/\/git-scm.com\/book\/pl\/v2\/Ga%C5%82%C4%99zie-Gita-Podstawy-rozga%C5%82%C4%99ziania-i-scalania), |\n| [Português (Brasil)](https:\/\/git-scm.com\/book\/pt-br\/v2\/Branches-no-Git-O-b%C3%A1sico-de-Ramifica%C3%A7%C3%A3o-Branch-e-Mesclagem-Merge), |\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-%D0%B2%D0%B0-%D0%B1%D0%B8%D1%80%D0%BB%D0%B0%D1%88%D0%B8%D1%88-%D0%B0%D1%81%D0%BE%D1%81%D0%BB%D0%B0%D1%80%D0%B8), |\n| [繁體中文](https:\/\/git-scm.com\/book\/zh-tw\/v2\/%E4%BD%BF%E7%94%A8-Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E5%92%8C%E5%90%88%E4%BD%B5%E7%9A%84%E5%9F%BA%E6%9C%AC%E7%94%A8%E6%B3%95), |\n\nTranslations started for\n\n|   |\n|---|\n| [Беларуская](https:\/\/git-scm.com\/book\/be\/v2\/Git-Branching-Basic-Branching-and-Merging), |\n| [Indonesian](https:\/\/git-scm.com\/book\/id\/v2\/Git-Branching-Basic-Branching-and-Merging), |\n| [Italiano](https:\/\/git-scm.com\/book\/it\/v2\/Git-Branching-Basic-Branching-and-Merging), |\n| [Bahasa Melayu](https:\/\/git-scm.com\/book\/ms\/v2\/Git-Branching-Basic-Branching-and-Merging), |\n| [Português (Portugal)](https:\/\/git-scm.com\/book\/pt-pt\/v2\/Ramifica%C3%A7%C3%A3o-do-Git-Basic-Branching-and-Merging). |\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-Basic-Branching-and-Merging)\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\\.2 Git Branching - Basic Branching and Merging\n## Basic Branching and Merging\nLet’s go through a simple example of branching and merging with a workflow that you might use in the real world. You’ll follow these steps:\n\n1. Do some work on a website.\n2. Create a branch for a new user story you’re working on.\n3. Do some work in that branch.\n\nAt this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following:\n\n1. Switch to your production branch.\n2. Create a branch to add the hotfix.\n3. After it’s tested, merge the hotfix branch, and push to production.\n4. Switch back to your original user story and continue working.\n\n### Basic Branching\nFirst, let’s say you’re working on your project and have a couple of commits already on the `master` branch.\n\n![A simple commit history](https:\/\/git-scm.com\/book\/en\/v2\/images\/basic-branching-1.png)\n\nFigure 18. A simple commit history\n\nYou’ve decided that you’re going to work on issue \\#53 in whatever issue-tracking system your company uses. To create a new branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch:\n```\n$ git checkout -b iss53\nSwitched to a new branch \"iss53\"\n```\nThis is shorthand for:\n```\n$ git branch iss53\n$ git checkout iss53\n```\n![Creating a new branch pointer](https:\/\/git-scm.com\/book\/en\/v2\/images\/basic-branching-2.png)\n\nFigure 19. Creating a new branch pointer\n\nYou work on your website and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your `HEAD` is pointing to it):\n```\n$ vim index.html\n$ git commit -a -m 'Create new footer [issue 53]'\n```\n![The \\`iss53\\` branch has moved forward with your work](https:\/\/git-scm.com\/book\/en\/v2\/images\/basic-branching-3.png)\n\nFigure 20. The `iss53` branch has moved forward with your work\n\nNow you get the call that there is an issue with the website, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your `master` branch.\n\nHowever, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later on, in [Stashing and Cleaning](https:\/\/git-scm.com\/book\/en\/v2\/ch00\/_git_stashing). For now, let’s assume you’ve committed all your changes, so you can switch back to your `master` branch:\n```\n$ git checkout master\nSwitched to branch 'master'\n```\nAt this point, your project working directory is exactly the way it was before you started working on issue \\#53, and you can concentrate on your hotfix. This is an important point to remember: when you switch branches, Git resets your working directory to look like it did the last time you committed on that branch. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it.\n\nNext, you have a hotfix to make. Let’s create a `hotfix` branch on which to work until it’s completed:\n```\n$ git checkout -b hotfix\nSwitched to a new branch 'hotfix'\n$ vim index.html\n$ git commit -a -m 'Fix broken email address'\n[hotfix 1fb7853] Fix broken email address\n 1 file changed, 2 insertions(+)\n```\n![Hotfix branch based on \\`master\\`](https:\/\/git-scm.com\/book\/en\/v2\/images\/basic-branching-4.png)\n\nFigure 21. Hotfix branch based on `master`\n\nYou can run your tests, make sure the hotfix is what you want, and finally merge the `hotfix` branch back into your `master` branch to deploy to production. You do this with the `git merge` command:\n```\n$ git checkout master\n$ git merge hotfix\nUpdating f42c576..3a0874c\nFast-forward\n index.html | 2 ++\n 1 file changed, 2 insertions(+)\n```\nYou’ll notice the phrase “fast-forward” in that merge. Because the commit `C4` pointed to by the branch `hotfix` you merged in was directly ahead of the commit `C2` you’re on, Git simply moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a “fast-forward.”\n\nYour change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy the fix.\n\n![\\`master\\` is fast-forwarded to \\`hotfix\\`](https:\/\/git-scm.com\/book\/en\/v2\/images\/basic-branching-5.png)\n\nFigure 22. `master` is fast-forwarded to `hotfix`\n\nAfter your super-important fix is deployed, you’re ready to switch back to the work you were doing before you were interrupted. However, first you’ll delete the `hotfix` branch, because you no longer need it — the `master` branch points at the same place. You can delete it with the `-d` option to `git branch`:\n```\n$ git branch -d hotfix\nDeleted branch hotfix (3a0874c).\n```\nNow you can switch back to your work-in-progress branch on issue \\#53 and continue working on it.\n```\n$ git checkout iss53\nSwitched to branch \"iss53\"\n$ vim index.html\n$ git commit -a -m 'Finish the new footer [issue 53]'\n[iss53 ad82d7a] Finish the new footer [issue 53]\n1 file changed, 1 insertion(+)\n```\n![Work continues on \\`iss53\\`](https:\/\/git-scm.com\/book\/en\/v2\/images\/basic-branching-6.png)\n\nFigure 23. Work continues on `iss53`\n\nIt’s worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch. If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later.\n\n### Basic Merging\nSuppose you’ve decided that your issue \\#53 work is complete and ready to be merged into your `master` branch. In order to do that, you’ll merge your `iss53` branch into `master`, much like you merged your `hotfix` branch earlier. All you have to do is check out the branch you wish to merge into and then run the `git merge` command:\n```\n$ git checkout master\nSwitched to branch 'master'\n$ git merge iss53\nMerge made by the 'recursive' strategy.\nindex.html |    1 +\n1 file changed, 1 insertion(+)\n```\nThis looks a bit different than the `hotfix` merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two.\n\n![Three snapshots used in a typical merge](https:\/\/git-scm.com\/book\/en\/v2\/images\/basic-merging-1.png)\n\nFigure 24. Three snapshots used in a typical merge\n\nInstead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it. This is referred to as a merge commit, and is special in that it has more than one parent.\n\n![A merge commit](https:\/\/git-scm.com\/book\/en\/v2\/images\/basic-merging-2.png)\n\nFigure 25. A merge commit\n\nNow that your work is merged in, you have no further need for the `iss53` branch. You can close the issue in your issue-tracking system, and delete the branch:\n```\n$ git branch -d iss53\n```\n\n### Basic Merge Conflicts\nOccasionally, this process doesn’t go smoothly. If you changed the same part of the same file differently in the two branches you’re merging, Git won’t be able to merge them cleanly. If your fix for issue \\#53 modified the same part of a file as the `hotfix` branch, you’ll get a merge conflict that looks something like this:\n```\n$ git merge iss53\nAuto-merging index.html\nCONFLICT (content): Merge conflict in index.html\nAutomatic merge failed; fix conflicts and then commit the result.\n```\nGit hasn’t automatically created a new merge commit. It has paused the process while you resolve the conflict. If you want to see which files are unmerged at any point after a merge conflict, you can run `git status`:\n```\n$ git status\nOn branch master\nYou have unmerged paths.\n  (fix conflicts and run \"git commit\")\n\nUnmerged paths:\n  (use \"git add <file>...\" to mark resolution)\n\n    both modified:      index.html\n\nno changes added to commit (use \"git add\" and\/or \"git commit -a\")\n```\nAnything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this:\n```\n<<<<<<< HEAD:index.html\n<div id=\"footer\">contact : email.support@github.com<\/div>\n=======\n<div id=\"footer\">\n please contact us at support@github.com\n<\/div>\n>>>>>>> iss53:index.html\n```\nThis means the version in `HEAD` (your `master` branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this:\n```\n<div id=\"footer\">\nplease contact us at email.support@github.com\n<\/div>\n```\nThis resolution has a little of each section, and the `<<<<<<<`, `=======`, and `>>>>>>>` lines have been completely removed. After you’ve resolved each of these sections in each conflicted file, run `git add` on each file to mark it as resolved. Staging the file marks it as resolved in Git.\n\nIf you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts:\n```\n$ git mergetool\n\nThis message is displayed because 'merge.tool' is not configured.\nSee 'git mergetool --tool-help' or 'git help config' for more details.\n'git mergetool' will now attempt to use one of the following tools:\nopendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge\nMerging:\nindex.html\n\nNormal merge conflict for 'index.html':\n  {local}: modified file\n  {remote}: modified file\nHit return to start merge resolution tool (opendiff):\n```\nIf you want to use a merge tool other than the default (Git chose `opendiff` in this case because the command was run on macOS), you can see all the supported tools listed at the top after “one of the following tools.” Just type the name of the tool you’d rather use.\n\n|   |   |\n|---|---|\n| Note | If you need more advanced tools for resolving tricky merge conflicts, we cover more on merging in [Advanced Merging](https:\/\/git-scm.com\/book\/en\/v2\/ch00\/_advanced_merging). |\n\nAfter you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you. You can run `git status` again to verify that all conflicts have been resolved:\n```\n$ git status\nOn branch master\nAll conflicts fixed but you are still merging.\n  (use \"git commit\" to conclude merge)\n\nChanges to be committed:\n\n    modified:   index.html\n```\nIf you’re happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. The commit message by default looks something like this:\n```\nMerge branch 'iss53'\n\nConflicts:\n    index.html\n#\n# It looks like you may be committing a merge.\n# If this is not correct, please remove the file\n#\t.git\/MERGE_HEAD\n# and try again.\n\n\n# Please enter the commit message for your changes. Lines starting\n# with '#' will be ignored, and an empty message aborts the commit.\n# On branch master\n# All conflicts fixed but you are still merging.\n#\n# Changes to be committed:\n#\tmodified:   index.html\n#\n```\nIf you think it would be helpful to others looking at this merge in the future, you can modify this commit message with details about how you resolved the merge and explain why you did the changes you made if these are not obvious.\n\n[prev](https:\/\/git-scm.com\/book\/en\/v2\/Git-Branching-Branches-in-a-Nutshell) \\| [next](https:\/\/git-scm.com\/book\/en\/v2\/Git-Branching-Branch-Management)\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":"## Basic Branching and Merging\nLet’s go through a simple example of branching and merging with a workflow that you might use in the real world. You’ll follow these steps:\n\n1. Do some work on a website.\n2. Create a branch for a new user story you’re working on.\n3. Do some work in that branch.\n\nAt this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following:\n\n1. Switch to your production branch.\n2. Create a branch to add the hotfix.\n3. After it’s tested, merge the hotfix branch, and push to production.\n4. Switch back to your original user story and continue working.\n\n### Basic Branching\nFirst, let’s say you’re working on your project and have a couple of commits already on the `master` branch.\n\n![A simple commit history](https:\/\/git-scm.com\/book\/en\/v2\/images\/basic-branching-1.png)\n\nFigure 18. A simple commit history\n\nYou’ve decided that you’re going to work on issue \\#53 in whatever issue-tracking system your company uses. To create a new branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch:\n```\n$ git checkout -b iss53\nSwitched to a new branch \"iss53\"\n```\nThis is shorthand for:\n```\n$ git branch iss53\n$ git checkout iss53\n```\n![Creating a new branch pointer](https:\/\/git-scm.com\/book\/en\/v2\/images\/basic-branching-2.png)\n\nFigure 19. Creating a new branch pointer\n\nYou work on your website and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your `HEAD` is pointing to it):\n```\n$ vim index.html\n$ git commit -a -m 'Create new footer [issue 53]'\n```\n![The \\`iss53\\` branch has moved forward with your work](https:\/\/git-scm.com\/book\/en\/v2\/images\/basic-branching-3.png)\n\nFigure 20. The `iss53` branch has moved forward with your work\n\nNow you get the call that there is an issue with the website, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your `master` branch.\n\nHowever, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later on, in [Stashing and Cleaning](https:\/\/git-scm.com\/book\/en\/v2\/ch00\/_git_stashing). For now, let’s assume you’ve committed all your changes, so you can switch back to your `master` branch:\n```\n$ git checkout master\nSwitched to branch 'master'\n```\nAt this point, your project working directory is exactly the way it was before you started working on issue \\#53, and you can concentrate on your hotfix. This is an important point to remember: when you switch branches, Git resets your working directory to look like it did the last time you committed on that branch. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it.\n\nNext, you have a hotfix to make. Let’s create a `hotfix` branch on which to work until it’s completed:\n```\n$ git checkout -b hotfix\nSwitched to a new branch 'hotfix'\n$ vim index.html\n$ git commit -a -m 'Fix broken email address'\n[hotfix 1fb7853] Fix broken email address\n 1 file changed, 2 insertions(+)\n```\n![Hotfix branch based on \\`master\\`](https:\/\/git-scm.com\/book\/en\/v2\/images\/basic-branching-4.png)\n\nFigure 21. Hotfix branch based on `master`\n\nYou can run your tests, make sure the hotfix is what you want, and finally merge the `hotfix` branch back into your `master` branch to deploy to production. You do this with the `git merge` command:\n```\n$ git checkout master\n$ git merge hotfix\nUpdating f42c576..3a0874c\nFast-forward\n index.html | 2 ++\n 1 file changed, 2 insertions(+)\n```\nYou’ll notice the phrase “fast-forward” in that merge. Because the commit `C4` pointed to by the branch `hotfix` you merged in was directly ahead of the commit `C2` you’re on, Git simply moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a “fast-forward.”\n\nYour change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy the fix.\n\n![\\`master\\` is fast-forwarded to \\`hotfix\\`](https:\/\/git-scm.com\/book\/en\/v2\/images\/basic-branching-5.png)\n\nFigure 22. `master` is fast-forwarded to `hotfix`\n\nAfter your super-important fix is deployed, you’re ready to switch back to the work you were doing before you were interrupted. However, first you’ll delete the `hotfix` branch, because you no longer need it — the `master` branch points at the same place. You can delete it with the `-d` option to `git branch`:\n```\n$ git branch -d hotfix\nDeleted branch hotfix (3a0874c).\n```\nNow you can switch back to your work-in-progress branch on issue \\#53 and continue working on it.\n```\n$ git checkout iss53\nSwitched to branch \"iss53\"\n$ vim index.html\n$ git commit -a -m 'Finish the new footer [issue 53]'\n[iss53 ad82d7a] Finish the new footer [issue 53]\n1 file changed, 1 insertion(+)\n```\n![Work continues on \\`iss53\\`](https:\/\/git-scm.com\/book\/en\/v2\/images\/basic-branching-6.png)\n\nFigure 23. Work continues on `iss53`\n\nIt’s worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch. If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later.\n\n### Basic Merging\nSuppose you’ve decided that your issue \\#53 work is complete and ready to be merged into your `master` branch. In order to do that, you’ll merge your `iss53` branch into `master`, much like you merged your `hotfix` branch earlier. All you have to do is check out the branch you wish to merge into and then run the `git merge` command:\n```\n$ git checkout master\nSwitched to branch 'master'\n$ git merge iss53\nMerge made by the 'recursive' strategy.\nindex.html |    1 +\n1 file changed, 1 insertion(+)\n```\nThis looks a bit different than the `hotfix` merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two.\n\n![Three snapshots used in a typical merge](https:\/\/git-scm.com\/book\/en\/v2\/images\/basic-merging-1.png)\n\nFigure 24. Three snapshots used in a typical merge\n\nInstead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it. This is referred to as a merge commit, and is special in that it has more than one parent.\n\n![A merge commit](https:\/\/git-scm.com\/book\/en\/v2\/images\/basic-merging-2.png)\n\nFigure 25. A merge commit\n\nNow that your work is merged in, you have no further need for the `iss53` branch. You can close the issue in your issue-tracking system, and delete the branch:\n```\n$ git branch -d iss53\n```\n\n### Basic Merge Conflicts\nOccasionally, this process doesn’t go smoothly. If you changed the same part of the same file differently in the two branches you’re merging, Git won’t be able to merge them cleanly. If your fix for issue \\#53 modified the same part of a file as the `hotfix` branch, you’ll get a merge conflict that looks something like this:\n```\n$ git merge iss53\nAuto-merging index.html\nCONFLICT (content): Merge conflict in index.html\nAutomatic merge failed; fix conflicts and then commit the result.\n```\nGit hasn’t automatically created a new merge commit. It has paused the process while you resolve the conflict. If you want to see which files are unmerged at any point after a merge conflict, you can run `git status`:\n```\n$ git status\nOn branch master\nYou have unmerged paths.\n  (fix conflicts and run \"git commit\")\n\nUnmerged paths:\n  (use \"git add <file>...\" to mark resolution)\n\n    both modified:      index.html\n\nno changes added to commit (use \"git add\" and\/or \"git commit -a\")\n```\nAnything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this:\n```\n<<<<<<< HEAD:index.html\n<div id=\"footer\">contact : email.support@github.com<\/div>\n=======\n<div id=\"footer\">\n please contact us at support@github.com\n<\/div>\n>>>>>>> iss53:index.html\n```\nThis means the version in `HEAD` (your `master` branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this:\n```\n<div id=\"footer\">\nplease contact us at email.support@github.com\n<\/div>\n```\nThis resolution has a little of each section, and the `<<<<<<<`, `=======`, and `>>>>>>>` lines have been completely removed. After you’ve resolved each of these sections in each conflicted file, run `git add` on each file to mark it as resolved. Staging the file marks it as resolved in Git.\n\nIf you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts:\n```\n$ git mergetool\n\nThis message is displayed because 'merge.tool' is not configured.\nSee 'git mergetool --tool-help' or 'git help config' for more details.\n'git mergetool' will now attempt to use one of the following tools:\nopendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge\nMerging:\nindex.html\n\nNormal merge conflict for 'index.html':\n  {local}: modified file\n  {remote}: modified file\nHit return to start merge resolution tool (opendiff):\n```\nIf you want to use a merge tool other than the default (Git chose `opendiff` in this case because the command was run on macOS), you can see all the supported tools listed at the top after “one of the following tools.” Just type the name of the tool you’d rather use.\n\n|   |   |\n|---|---|\n| Note | If you need more advanced tools for resolving tricky merge conflicts, we cover more on merging in [Advanced Merging](https:\/\/git-scm.com\/book\/en\/v2\/ch00\/_advanced_merging). |\n\nAfter you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you. You can run `git status` again to verify that all conflicts have been resolved:\n```\n$ git status\nOn branch master\nAll conflicts fixed but you are still merging.\n  (use \"git commit\" to conclude merge)\n\nChanges to be committed:\n\n    modified:   index.html\n```\nIf you’re happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. The commit message by default looks something like this:\n```\nMerge branch 'iss53'\n\nConflicts:\n    index.html\n#\n# It looks like you may be committing a merge.\n# If this is not correct, please remove the file\n#\t.git\/MERGE_HEAD\n# and try again.\n\n\n# Please enter the commit message for your changes. Lines starting\n# with '#' will be ignored, and an empty message aborts the commit.\n# On branch master\n# All conflicts fixed but you are still merging.\n#\n# Changes to be committed:\n#\tmodified:   index.html\n#\n```\nIf you think it would be helpful to others looking at this merge in the future, you can modify this commit message with details about how you resolved the merge and explain why you did the changes you made if these are not obvious.","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

8 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-Basic-Branching-and-Merging
Last Crawled	2026-04-06 12:03:10 (8 hours ago)
First Indexed	2014-10-28 00:37:13 (11 years ago)
HTTP Status Code	200
Meta Title	Git - Basic Branching and Merging
Meta Description	null
Meta Canonical	null
Boilerpipe Text	Basic Branching and Merging Let’s go through a simple example of branching and merging with a workflow that you might use in the real world. You’ll follow these steps: Do some work on a website. Create a branch for a new user story you’re working on. Do some work in that branch. At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following: Switch to your production branch. Create a branch to add the hotfix. After it’s tested, merge the hotfix branch, and push to production. Switch back to your original user story and continue working. Basic Branching First, let’s say you’re working on your project and have a couple of commits already on the master branch. Figure 18. A simple commit history You’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses. To create a new branch and switch to it at the same time, you can run the git checkout command with the -b switch: $ git checkout -b iss53 Switched to a new branch "iss53" This is shorthand for: $ git branch iss53 $ git checkout iss53 Figure 19. Creating a new branch pointer You work on your website and do some commits. Doing so moves the iss53 branch forward, because you have it checked out (that is, your HEAD is pointing to it): $ vim index.html $ git commit -a -m 'Create new footer [issue 53]' Figure 20. The iss53 branch has moved forward with your work Now you get the call that there is an issue with the website, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the iss53 changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your master branch. However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later on, in Stashing and Cleaning . For now, let’s assume you’ve committed all your changes, so you can switch back to your master branch: $ git checkout master Switched to branch 'master' At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. This is an important point to remember: when you switch branches, Git resets your working directory to look like it did the last time you committed on that branch. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it. Next, you have a hotfix to make. Let’s create a hotfix branch on which to work until it’s completed: $ git checkout -b hotfix Switched to a new branch 'hotfix' $ vim index.html $ git commit -a -m 'Fix broken email address' [hotfix 1fb7853] Fix broken email address 1 file changed, 2 insertions(+) Figure 21. Hotfix branch based on master You can run your tests, make sure the hotfix is what you want, and finally merge the hotfix branch back into your master branch to deploy to production. You do this with the git merge command: $ git checkout master $ git merge hotfix Updating f42c576..3a0874c Fast-forward index.html \| 2 ++ 1 file changed, 2 insertions(+) You’ll notice the phrase “fast-forward” in that merge. Because the commit C4 pointed to by the branch hotfix you merged in was directly ahead of the commit C2 you’re on, Git simply moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a “fast-forward.” Your change is now in the snapshot of the commit pointed to by the master branch, and you can deploy the fix. Figure 22. master is fast-forwarded to hotfix After your super-important fix is deployed, you’re ready to switch back to the work you were doing before you were interrupted. However, first you’ll delete the hotfix branch, because you no longer need it — the master branch points at the same place. You can delete it with the -d option to git branch : $ git branch -d hotfix Deleted branch hotfix (3a0874c). Now you can switch back to your work-in-progress branch on issue #53 and continue working on it. $ git checkout iss53 Switched to branch "iss53" $ vim index.html $ git commit -a -m 'Finish the new footer [issue 53]' [iss53 ad82d7a] Finish the new footer [issue 53] 1 file changed, 1 insertion(+) Figure 23. Work continues on iss53 It’s worth noting here that the work you did in your hotfix branch is not contained in the files in your iss53 branch. If you need to pull it in, you can merge your master branch into your iss53 branch by running git merge master , or you can wait to integrate those changes until you decide to pull the iss53 branch back into master later. Basic Merging Suppose you’ve decided that your issue #53 work is complete and ready to be merged into your master branch. In order to do that, you’ll merge your iss53 branch into master , much like you merged your hotfix branch earlier. All you have to do is check out the branch you wish to merge into and then run the git merge command: $ git checkout master Switched to branch 'master' $ git merge iss53 Merge made by the 'recursive' strategy. index.html \| 1 + 1 file changed, 1 insertion(+) This looks a bit different than the hotfix merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. Figure 24. Three snapshots used in a typical merge Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it. This is referred to as a merge commit, and is special in that it has more than one parent. Figure 25. A merge commit Now that your work is merged in, you have no further need for the iss53 branch. You can close the issue in your issue-tracking system, and delete the branch: $ git branch -d iss53 Basic Merge Conflicts Occasionally, this process doesn’t go smoothly. If you changed the same part of the same file differently in the two branches you’re merging, Git won’t be able to merge them cleanly. If your fix for issue #53 modified the same part of a file as the hotfix branch, you’ll get a merge conflict that looks something like this: $ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. Git hasn’t automatically created a new merge commit. It has paused the process while you resolve the conflict. If you want to see which files are unmerged at any point after a merge conflict, you can run git status : $ git status On branch master You have unmerged paths. (fix conflicts and run "git commit") Unmerged paths: (use "git add <file>..." to mark resolution) both modified: index.html no changes added to commit (use "git add" and/or "git commit -a") Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this: <<<<<<< HEAD:index.html <div id="footer">contact : email.support@github.com</div> ======= <div id="footer"> please contact us at support@github.com </div> >>>>>>> iss53:index.html This means the version in HEAD (your master branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the ======= ), while the version in your iss53 branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this: <div id="footer"> please contact us at email.support@github.com </div> This resolution has a little of each section, and the <<<<<<< , ======= , and >>>>>>> lines have been completely removed. After you’ve resolved each of these sections in each conflicted file, run git add on each file to mark it as resolved. Staging the file marks it as resolved in Git. If you want to use a graphical tool to resolve these issues, you can run git mergetool , which fires up an appropriate visual merge tool and walks you through the conflicts: $ git mergetool This message is displayed because 'merge.tool' is not configured. See 'git mergetool --tool-help' or 'git help config' for more details. 'git mergetool' will now attempt to use one of the following tools: opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge Merging: index.html Normal merge conflict for 'index.html': {local}: modified file {remote}: modified file Hit return to start merge resolution tool (opendiff): If you want to use a merge tool other than the default (Git chose opendiff in this case because the command was run on macOS), you can see all the supported tools listed at the top after “one of the following tools.” Just type the name of the tool you’d rather use. Note If you need more advanced tools for resolving tricky merge conflicts, we cover more on merging in Advanced Merging . After you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you. You can run git status again to verify that all conflicts have been resolved: $ git status On branch master All conflicts fixed but you are still merging. (use "git commit" to conclude merge) Changes to be committed: modified: index.html If you’re happy with that, and you verify that everything that had conflicts has been staged, you can type git commit to finalize the merge commit. The commit message by default looks something like this: Merge branch 'iss53' Conflicts: index.html # # It looks like you may be committing a merge. # If this is not correct, please remove the file # .git/MERGE_HEAD # and try again. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # All conflicts fixed but you are still merging. # # Changes to be committed: # modified: index.html # If you think it would be helpful to others looking at this merge in the future, you can modify this commit message with details about how you resolved the merge and explain why you did the changes you made if these are not obvious.
Markdown	[![Git](https://git-scm.com/images/logo@2x.png)](https://git-scm.com/) \--distributed-even-if-your-workflow-isnt ![](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-Basic-Branching-and-Merging). Full translation available in \| \| \|---\| \| [azərbaycan dili](https://git-scm.com/book/az/v2/Git%E2%80%99d%C9%99-Branch-Sad%C9%99-Branching-v%C9%99-Birl%C9%99%C5%9Fdirm%C9%99), \| \| [български език](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%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%B8-%D0%BD%D0%B0-%D0%BA%D0%BB%D0%BE%D0%BD%D0%BE%D0%B2%D0%B5%D1%82%D0%B5-%D0%BA%D0%BE%D0%B4-%D0%B8-%D1%81%D0%BB%D0%B8%D0%B2%D0%B0%D0%BD%D0%B5%D1%82%D0%BE), \| \| [Deutsch](https://git-scm.com/book/de/v2/Git-Branching-Einfaches-Branching-und-Merging), \| \| [Español](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Procedimientos-B%C3%A1sicos-para-Ramificar-y-Fusionar), \| \| [فارسی](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%D8%A8%D9%86%D8%AF%DB%8C-%D9%88-%D8%A7%D8%AF%D8%BA%D8%A7%D9%85-%D9%BE%D8%A7%DB%8C%D9%87%E2%80%8C%D8%A7%DB%8C-Basic-Branching-and-Merging), \| \| [Français](https://git-scm.com/book/fr/v2/Les-branches-avec-Git-Branches-et-fusions%C2%A0:-les-bases), \| \| [Ελληνικά](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%92%CE%B1%CF%83%CE%B9%CE%BA%CE%AD%CF%82-%CE%AD%CE%BD%CE%BD%CE%BF%CE%B9%CE%B5%CF%82-%CE%B4%CE%B9%CE%B1%CE%BA%CE%BB%CE%B1%CE%B4%CF%8E%CF%83%CE%B5%CF%89%CE%BD-%CE%BA%CE%B1%CE%B9-%CF%83%CF%85%CE%B3%CF%87%CF%89%CE%BD%CE%B5%CF%8D%CF%83%CE%B5%CF%89%CE%BD), \| \| [日本語](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%83%9E%E3%83%BC%E3%82%B8%E3%81%AE%E5%9F%BA%E6%9C%AC), \| \| [한국어](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%EC%99%80-Merge-%EC%9D%98-%EA%B8%B0%EC%B4%88), \| \| [Nederlands](https://git-scm.com/book/nl/v2/Branchen-in-Git-Eenvoudig-branchen-en-mergen), \| \| [Русский](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%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-%D0%B2%D0%B5%D1%82%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-%D0%B8-%D1%81%D0%BB%D0%B8%D1%8F%D0%BD%D0%B8%D1%8F), \| \| [Slovenščina](https://git-scm.com/book/sl/v2/Veje-Git-Osnove-vej-in-zdru%C5%BEevanja), \| \| [Српски](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%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%B5-%D0%B3%D1%80%D0%B0%D0%BD%D0%B0%D1%9A%D0%B0-%D0%B8-%D1%81%D0%BF%D0%B0%D1%98%D0%B0%D1%9A%D0%B0), \| \| [Svenska](https://git-scm.com/book/sv/v2/Git-grenar-Grundl%C3%A4ggande-gren--och-sammanfogningsarbete), \| \| [Tagalog](https://git-scm.com/book/tl/v2/Pag-branch-ng-Git-Batayan-ng-Pag-branch-at-Pag-merge), \| \| [Türkçe](https://git-scm.com/book/tr/v2/Git-Dallar%C4%B1-K%C4%B1saca-Dalland%C4%B1rma-ve-Birle%C5%9Ftirme-Temelleri). \| \| [Українська](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%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%B8-%D0%B3%D0%B0%D0%BB%D1%83%D0%B6%D0%B5%D0%BD%D0%BD%D1%8F-%D1%82%D0%B0-%D0%B7%D0%BB%D0%B8%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F), \| \| [简体中文](https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%9A%84%E6%96%B0%E5%BB%BA%E4%B8%8E%E5%90%88%E5%B9%B6), \| Partial translations available in \| \| \|---\| \| [Čeština](https://git-scm.com/book/cs/v2/V%C4%9Btve-v-syst%C3%A9mu-Git-Z%C3%A1klady-v%C4%9Btven%C3%AD-a-slu%C4%8Dov%C3%A1n%C3%AD), \| \| [Македонски](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%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D0%BE-%D1%80%D0%B0%D0%B7%D0%B3%D1%80%D0%B0%D0%BD%D1%83%D0%B2%D0%B0%D1%9A%D0%B5-%D0%B8-%D1%81%D0%BF%D0%BE%D1%98%D1%83%D0%B2%D0%B0%D1%9A%D0%B5), \| \| [Polski](https://git-scm.com/book/pl/v2/Ga%C5%82%C4%99zie-Gita-Podstawy-rozga%C5%82%C4%99ziania-i-scalania), \| \| [Português (Brasil)](https://git-scm.com/book/pt-br/v2/Branches-no-Git-O-b%C3%A1sico-de-Ramifica%C3%A7%C3%A3o-Branch-e-Mesclagem-Merge), \| \| [Ўзбекча](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-%D0%B2%D0%B0-%D0%B1%D0%B8%D1%80%D0%BB%D0%B0%D1%88%D0%B8%D1%88-%D0%B0%D1%81%D0%BE%D1%81%D0%BB%D0%B0%D1%80%D0%B8), \| \| [繁體中文](https://git-scm.com/book/zh-tw/v2/%E4%BD%BF%E7%94%A8-Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E5%92%8C%E5%90%88%E4%BD%B5%E7%9A%84%E5%9F%BA%E6%9C%AC%E7%94%A8%E6%B3%95), \| Translations started for \| \| \|---\| \| [Беларуская](https://git-scm.com/book/be/v2/Git-Branching-Basic-Branching-and-Merging), \| \| [Indonesian](https://git-scm.com/book/id/v2/Git-Branching-Basic-Branching-and-Merging), \| \| [Italiano](https://git-scm.com/book/it/v2/Git-Branching-Basic-Branching-and-Merging), \| \| [Bahasa Melayu](https://git-scm.com/book/ms/v2/Git-Branching-Basic-Branching-and-Merging), \| \| [Português (Portugal)](https://git-scm.com/book/pt-pt/v2/Ramifica%C3%A7%C3%A3o-do-Git-Basic-Branching-and-Merging). \| * 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-Basic-Branching-and-Merging) 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\.2 Git Branching - Basic Branching and Merging ## Basic Branching and Merging Let’s go through a simple example of branching and merging with a workflow that you might use in the real world. You’ll follow these steps: 1. Do some work on a website. 2. Create a branch for a new user story you’re working on. 3. Do some work in that branch. At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following: 1. Switch to your production branch. 2. Create a branch to add the hotfix. 3. After it’s tested, merge the hotfix branch, and push to production. 4. Switch back to your original user story and continue working. ### Basic Branching First, let’s say you’re working on your project and have a couple of commits already on the `master` branch. ![A simple commit history](https://git-scm.com/book/en/v2/images/basic-branching-1.png) Figure 18. A simple commit history You’ve decided that you’re going to work on issue \#53 in whatever issue-tracking system your company uses. To create a new branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch: ``` $ git checkout -b iss53 Switched to a new branch "iss53" ``` This is shorthand for: ``` $ git branch iss53 $ git checkout iss53 ``` ![Creating a new branch pointer](https://git-scm.com/book/en/v2/images/basic-branching-2.png) Figure 19. Creating a new branch pointer You work on your website and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your `HEAD` is pointing to it): ``` $ vim index.html $ git commit -a -m 'Create new footer [issue 53]' ``` ![The \`iss53\` branch has moved forward with your work](https://git-scm.com/book/en/v2/images/basic-branching-3.png) Figure 20. The `iss53` branch has moved forward with your work Now you get the call that there is an issue with the website, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your `master` branch. However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later on, in [Stashing and Cleaning](https://git-scm.com/book/en/v2/ch00/_git_stashing). For now, let’s assume you’ve committed all your changes, so you can switch back to your `master` branch: ``` $ git checkout master Switched to branch 'master' ``` At this point, your project working directory is exactly the way it was before you started working on issue \#53, and you can concentrate on your hotfix. This is an important point to remember: when you switch branches, Git resets your working directory to look like it did the last time you committed on that branch. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it. Next, you have a hotfix to make. Let’s create a `hotfix` branch on which to work until it’s completed: ``` $ git checkout -b hotfix Switched to a new branch 'hotfix' $ vim index.html $ git commit -a -m 'Fix broken email address' [hotfix 1fb7853] Fix broken email address 1 file changed, 2 insertions(+) ``` ![Hotfix branch based on \`master\`](https://git-scm.com/book/en/v2/images/basic-branching-4.png) Figure 21. Hotfix branch based on `master` You can run your tests, make sure the hotfix is what you want, and finally merge the `hotfix` branch back into your `master` branch to deploy to production. You do this with the `git merge` command: ``` $ git checkout master $ git merge hotfix Updating f42c576..3a0874c Fast-forward index.html \| 2 ++ 1 file changed, 2 insertions(+) ``` You’ll notice the phrase “fast-forward” in that merge. Because the commit `C4` pointed to by the branch `hotfix` you merged in was directly ahead of the commit `C2` you’re on, Git simply moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a “fast-forward.” Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy the fix. ![\`master\` is fast-forwarded to \`hotfix\`](https://git-scm.com/book/en/v2/images/basic-branching-5.png) Figure 22. `master` is fast-forwarded to `hotfix` After your super-important fix is deployed, you’re ready to switch back to the work you were doing before you were interrupted. However, first you’ll delete the `hotfix` branch, because you no longer need it — the `master` branch points at the same place. You can delete it with the `-d` option to `git branch`: ``` $ git branch -d hotfix Deleted branch hotfix (3a0874c). ``` Now you can switch back to your work-in-progress branch on issue \#53 and continue working on it. ``` $ git checkout iss53 Switched to branch "iss53" $ vim index.html $ git commit -a -m 'Finish the new footer [issue 53]' [iss53 ad82d7a] Finish the new footer [issue 53] 1 file changed, 1 insertion(+) ``` ![Work continues on \`iss53\`](https://git-scm.com/book/en/v2/images/basic-branching-6.png) Figure 23. Work continues on `iss53` It’s worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch. If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later. ### Basic Merging Suppose you’ve decided that your issue \#53 work is complete and ready to be merged into your `master` branch. In order to do that, you’ll merge your `iss53` branch into `master`, much like you merged your `hotfix` branch earlier. All you have to do is check out the branch you wish to merge into and then run the `git merge` command: ``` $ git checkout master Switched to branch 'master' $ git merge iss53 Merge made by the 'recursive' strategy. index.html \| 1 + 1 file changed, 1 insertion(+) ``` This looks a bit different than the `hotfix` merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. ![Three snapshots used in a typical merge](https://git-scm.com/book/en/v2/images/basic-merging-1.png) Figure 24. Three snapshots used in a typical merge Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it. This is referred to as a merge commit, and is special in that it has more than one parent. ![A merge commit](https://git-scm.com/book/en/v2/images/basic-merging-2.png) Figure 25. A merge commit Now that your work is merged in, you have no further need for the `iss53` branch. You can close the issue in your issue-tracking system, and delete the branch: ``` $ git branch -d iss53 ``` ### Basic Merge Conflicts Occasionally, this process doesn’t go smoothly. If you changed the same part of the same file differently in the two branches you’re merging, Git won’t be able to merge them cleanly. If your fix for issue \#53 modified the same part of a file as the `hotfix` branch, you’ll get a merge conflict that looks something like this: ``` $ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. ``` Git hasn’t automatically created a new merge commit. It has paused the process while you resolve the conflict. If you want to see which files are unmerged at any point after a merge conflict, you can run `git status`: ``` $ git status On branch master You have unmerged paths. (fix conflicts and run "git commit") Unmerged paths: (use "git add <file>..." to mark resolution) both modified: index.html no changes added to commit (use "git add" and/or "git commit -a") ``` Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this: ``` <<<<<<< HEAD:index.html <div id="footer">contact : email.support@github.com</div> ======= <div id="footer"> please contact us at support@github.com </div> >>>>>>> iss53:index.html ``` This means the version in `HEAD` (your `master` branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this: ``` <div id="footer"> please contact us at email.support@github.com </div> ``` This resolution has a little of each section, and the `<<<<<<<`, `=======`, and `>>>>>>>` lines have been completely removed. After you’ve resolved each of these sections in each conflicted file, run `git add` on each file to mark it as resolved. Staging the file marks it as resolved in Git. If you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts: ``` $ git mergetool This message is displayed because 'merge.tool' is not configured. See 'git mergetool --tool-help' or 'git help config' for more details. 'git mergetool' will now attempt to use one of the following tools: opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge Merging: index.html Normal merge conflict for 'index.html': {local}: modified file {remote}: modified file Hit return to start merge resolution tool (opendiff): ``` If you want to use a merge tool other than the default (Git chose `opendiff` in this case because the command was run on macOS), you can see all the supported tools listed at the top after “one of the following tools.” Just type the name of the tool you’d rather use. \| \| \| \|---\|---\| \| Note \| If you need more advanced tools for resolving tricky merge conflicts, we cover more on merging in [Advanced Merging](https://git-scm.com/book/en/v2/ch00/_advanced_merging). \| After you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you. You can run `git status` again to verify that all conflicts have been resolved: ``` $ git status On branch master All conflicts fixed but you are still merging. (use "git commit" to conclude merge) Changes to be committed: modified: index.html ``` If you’re happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. The commit message by default looks something like this: ``` Merge branch 'iss53' Conflicts: index.html # # It looks like you may be committing a merge. # If this is not correct, please remove the file # .git/MERGE_HEAD # and try again. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # All conflicts fixed but you are still merging. # # Changes to be committed: # modified: index.html # ``` If you think it would be helpful to others looking at this merge in the future, you can modify this commit message with details about how you resolved the merge and explain why you did the changes you made if these are not obvious. [prev](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell) \\| [next](https://git-scm.com/book/en/v2/Git-Branching-Branch-Management) [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	## Basic Branching and Merging Let’s go through a simple example of branching and merging with a workflow that you might use in the real world. You’ll follow these steps: 1. Do some work on a website. 2. Create a branch for a new user story you’re working on. 3. Do some work in that branch. At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following: 1. Switch to your production branch. 2. Create a branch to add the hotfix. 3. After it’s tested, merge the hotfix branch, and push to production. 4. Switch back to your original user story and continue working. ### Basic Branching First, let’s say you’re working on your project and have a couple of commits already on the `master` branch. ![A simple commit history](https://git-scm.com/book/en/v2/images/basic-branching-1.png) Figure 18. A simple commit history You’ve decided that you’re going to work on issue \#53 in whatever issue-tracking system your company uses. To create a new branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch: ``` $ git checkout -b iss53 Switched to a new branch "iss53" ``` This is shorthand for: ``` $ git branch iss53 $ git checkout iss53 ``` ![Creating a new branch pointer](https://git-scm.com/book/en/v2/images/basic-branching-2.png) Figure 19. Creating a new branch pointer You work on your website and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your `HEAD` is pointing to it): ``` $ vim index.html $ git commit -a -m 'Create new footer [issue 53]' ``` ![The \`iss53\` branch has moved forward with your work](https://git-scm.com/book/en/v2/images/basic-branching-3.png) Figure 20. The `iss53` branch has moved forward with your work Now you get the call that there is an issue with the website, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your `master` branch. However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later on, in [Stashing and Cleaning](https://git-scm.com/book/en/v2/ch00/_git_stashing). For now, let’s assume you’ve committed all your changes, so you can switch back to your `master` branch: ``` $ git checkout master Switched to branch 'master' ``` At this point, your project working directory is exactly the way it was before you started working on issue \#53, and you can concentrate on your hotfix. This is an important point to remember: when you switch branches, Git resets your working directory to look like it did the last time you committed on that branch. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it. Next, you have a hotfix to make. Let’s create a `hotfix` branch on which to work until it’s completed: ``` $ git checkout -b hotfix Switched to a new branch 'hotfix' $ vim index.html $ git commit -a -m 'Fix broken email address' [hotfix 1fb7853] Fix broken email address 1 file changed, 2 insertions(+) ``` ![Hotfix branch based on \`master\`](https://git-scm.com/book/en/v2/images/basic-branching-4.png) Figure 21. Hotfix branch based on `master` You can run your tests, make sure the hotfix is what you want, and finally merge the `hotfix` branch back into your `master` branch to deploy to production. You do this with the `git merge` command: ``` $ git checkout master $ git merge hotfix Updating f42c576..3a0874c Fast-forward index.html \| 2 ++ 1 file changed, 2 insertions(+) ``` You’ll notice the phrase “fast-forward” in that merge. Because the commit `C4` pointed to by the branch `hotfix` you merged in was directly ahead of the commit `C2` you’re on, Git simply moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a “fast-forward.” Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy the fix. ![\`master\` is fast-forwarded to \`hotfix\`](https://git-scm.com/book/en/v2/images/basic-branching-5.png) Figure 22. `master` is fast-forwarded to `hotfix` After your super-important fix is deployed, you’re ready to switch back to the work you were doing before you were interrupted. However, first you’ll delete the `hotfix` branch, because you no longer need it — the `master` branch points at the same place. You can delete it with the `-d` option to `git branch`: ``` $ git branch -d hotfix Deleted branch hotfix (3a0874c). ``` Now you can switch back to your work-in-progress branch on issue \#53 and continue working on it. ``` $ git checkout iss53 Switched to branch "iss53" $ vim index.html $ git commit -a -m 'Finish the new footer [issue 53]' [iss53 ad82d7a] Finish the new footer [issue 53] 1 file changed, 1 insertion(+) ``` ![Work continues on \`iss53\`](https://git-scm.com/book/en/v2/images/basic-branching-6.png) Figure 23. Work continues on `iss53` It’s worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch. If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later. ### Basic Merging Suppose you’ve decided that your issue \#53 work is complete and ready to be merged into your `master` branch. In order to do that, you’ll merge your `iss53` branch into `master`, much like you merged your `hotfix` branch earlier. All you have to do is check out the branch you wish to merge into and then run the `git merge` command: ``` $ git checkout master Switched to branch 'master' $ git merge iss53 Merge made by the 'recursive' strategy. index.html \| 1 + 1 file changed, 1 insertion(+) ``` This looks a bit different than the `hotfix` merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. ![Three snapshots used in a typical merge](https://git-scm.com/book/en/v2/images/basic-merging-1.png) Figure 24. Three snapshots used in a typical merge Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it. This is referred to as a merge commit, and is special in that it has more than one parent. ![A merge commit](https://git-scm.com/book/en/v2/images/basic-merging-2.png) Figure 25. A merge commit Now that your work is merged in, you have no further need for the `iss53` branch. You can close the issue in your issue-tracking system, and delete the branch: ``` $ git branch -d iss53 ``` ### Basic Merge Conflicts Occasionally, this process doesn’t go smoothly. If you changed the same part of the same file differently in the two branches you’re merging, Git won’t be able to merge them cleanly. If your fix for issue \#53 modified the same part of a file as the `hotfix` branch, you’ll get a merge conflict that looks something like this: ``` $ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. ``` Git hasn’t automatically created a new merge commit. It has paused the process while you resolve the conflict. If you want to see which files are unmerged at any point after a merge conflict, you can run `git status`: ``` $ git status On branch master You have unmerged paths. (fix conflicts and run "git commit") Unmerged paths: (use "git add <file>..." to mark resolution) both modified: index.html no changes added to commit (use "git add" and/or "git commit -a") ``` Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this: ``` <<<<<<< HEAD:index.html <div id="footer">contact : email.support@github.com</div> ======= <div id="footer"> please contact us at support@github.com </div> >>>>>>> iss53:index.html ``` This means the version in `HEAD` (your `master` branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this: ``` <div id="footer"> please contact us at email.support@github.com </div> ``` This resolution has a little of each section, and the `<<<<<<<`, `=======`, and `>>>>>>>` lines have been completely removed. After you’ve resolved each of these sections in each conflicted file, run `git add` on each file to mark it as resolved. Staging the file marks it as resolved in Git. If you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts: ``` $ git mergetool This message is displayed because 'merge.tool' is not configured. See 'git mergetool --tool-help' or 'git help config' for more details. 'git mergetool' will now attempt to use one of the following tools: opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge Merging: index.html Normal merge conflict for 'index.html': {local}: modified file {remote}: modified file Hit return to start merge resolution tool (opendiff): ``` If you want to use a merge tool other than the default (Git chose `opendiff` in this case because the command was run on macOS), you can see all the supported tools listed at the top after “one of the following tools.” Just type the name of the tool you’d rather use. \| \| \| \|---\|---\| \| Note \| If you need more advanced tools for resolving tricky merge conflicts, we cover more on merging in [Advanced Merging](https://git-scm.com/book/en/v2/ch00/_advanced_merging). \| After you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you. You can run `git status` again to verify that all conflicts have been resolved: ``` $ git status On branch master All conflicts fixed but you are still merging. (use "git commit" to conclude merge) Changes to be committed: modified: index.html ``` If you’re happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. The commit message by default looks something like this: ``` Merge branch 'iss53' Conflicts: index.html # # It looks like you may be committing a merge. # If this is not correct, please remove the file # .git/MERGE_HEAD # and try again. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # All conflicts fixed but you are still merging. # # Changes to be committed: # modified: index.html # ``` If you think it would be helpful to others looking at this merge in the future, you can modify this commit message with details about how you resolved the merge and explain why you did the changes you made if these are not obvious.
Shard	54 (laksa)
Root Hash	7104038400628677254
Unparsed URL	com,git-scm!/book/en/v2/Git-Branching-Basic-Branching-and-Merging s443