CINXE.COM
Git - Contributing to a Project
<!DOCTYPE html> <html lang="sv"> <head> <meta charset='utf-8'> <meta content='IE=edge,chrome=1' http-equiv='X-UA-Compatible'> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Git - Contributing to a Project</title> <link href="/favicon.ico" rel='shortcut icon' type='image/x-icon'> <link rel="stylesheet" href="/application.min.css"> <script src="/js/modernizr.js"></script> <script src="/js/modernize.js"></script> </head> <body id="documentation"> <div class="inner"> <header> <a href="/"><img src="/images/logo@2x.png" width="110" height="46" alt="Git" /></a> <span id="tagline"></span> <script type="text/javascript"> const taglines = [ "fast-version-control", "everything-is-local", "distributed-even-if-your-workflow-isnt", "local-branching-on-the-cheap", "distributed-is-the-new-centralized" ]; var tagline = taglines[Math.floor(Math.random() * taglines.length)]; document.getElementById('tagline').innerHTML = '--' + tagline; </script> <form id="search" action="/search/results"> <input id="search-text" name="search" placeholder="Type / to search entire site…" autocomplete="off" type="text" /> </form> <div id="search-results"></div> </header> </div> <div class="inner"> <div id="content-wrapper"> <div tabindex="1" class="sidebar-btn"></div> <aside class="sidebar" id="sidebar"> <nav> <ul> <li> <a href="/about">About</a> <ul> </ul> </li> <li> <a href="/doc" class="active">Documentation</a> <ul class="expanded"> <li> <a href="/docs">Reference</a> </li> <li> <a href="/book" class="active">Book</a> </li> <li> <a href="/videos">Videos</a> </li> <li> <a href="/doc/ext">External Links</a> </li> </ul> </li> <li> <a href="/downloads">Downloads</a> <ul > <li> <a href="/downloads/guis">GUI Clients</a> </li> <li> <a href="/downloads/logos">Logos</a> </li> </ul> </li> <li> <a href="/community">Community</a> </li> </ul> <hr class="sidebar"> <p> This book is available in <a href="/book/en/v2/GitHub-Contributing-to-a-Project">English</a>. </p> <p> Full translation available in <table> <tr><td><a href="/book/az/v2/GitHub-Bir-Layih%c9%99y%c9%99-T%c3%b6hf%c9%99-Verm%c9%99k">azərbaycan dili</a>,</td></tr> <tr><td><a href="/book/bg/v2/%d0%9d%d0%b0%d1%81%d1%82%d1%80%d0%be%d0%b9%d0%b2%d0%b0%d0%bd%d0%b5-%d0%bd%d0%b0-Git-Git-%d0%b0%d1%82%d1%80%d0%b8%d0%b1%d1%83%d1%82%d0%b8">български език</a>,</td></tr> <tr><td><a href="/book/de/v2/GitHub-Mitwirken-an-einem-Projekt">Deutsch</a>,</td></tr> <tr><td><a href="/book/es/v2/GitHub-Participando-en-Proyectos">Español</a>,</td></tr> <tr><td><a href="/book/fr/v2/GitHub-Contribution-%c3%a0-un-projet">Français</a>,</td></tr> <tr><td><a href="/book/gr">Ελληνικά</a>,</td></tr> <tr><td><a href="/book/ja/v2/GitHub-%e3%83%97%e3%83%ad%e3%82%b8%e3%82%a7%e3%82%af%e3%83%88%e3%81%b8%e3%81%ae%e8%b2%a2%e7%8c%ae">日本語</a>,</td></tr> <tr><td><a href="/book/ko/v2/GitHub-GitHub-%ed%94%84%eb%a1%9c%ec%a0%9d%ed%8a%b8%ec%97%90-%ea%b8%b0%ec%97%ac%ed%95%98%ea%b8%b0">한국어</a>,</td></tr> <tr><td><a href="/book/nl/v2/GitHub-Aan-een-project-bijdragen">Nederlands</a>,</td></tr> <tr><td><a href="/book/ru/v2/GitHub-%d0%92%d0%bd%d0%b5%d1%81%d0%b5%d0%bd%d0%b8%d0%b5-%d1%81%d0%be%d0%b1%d1%81%d1%82%d0%b2%d0%b5%d0%bd%d0%bd%d0%be%d0%b3%d0%be-%d0%b2%d0%ba%d0%bb%d0%b0%d0%b4%d0%b0-%d0%b2-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d1%8b">Русский</a>,</td></tr> <tr><td><a href="/book/sl/v2/GitHub-Prispevek-k-projektu">Slovenščina</a>,</td></tr> <tr><td><a href="/book/tl/v2/GitHub-Pag-aambag-sa-isang-Proyekto">Tagalog</a>,</td></tr> <tr><td><a href="/book/uk/v2/GitHub-%d0%af%d0%ba-%d0%b7%d1%80%d0%be%d0%b1%d0%b8%d1%82%d0%b8-%d0%b2%d0%bd%d0%b5%d1%81%d0%be%d0%ba-%d0%b4%d0%be-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82%d1%83">Українська</a></td></tr> <tr><td><a href="/book/zh/v2/GitHub-%e5%af%b9%e9%a1%b9%e7%9b%ae%e5%81%9a%e5%87%ba%e8%b4%a1%e7%8c%ae">简体中文</a>,</td></tr> </table> </p> <p> Partial translations available in <table> <tr><td><a href="/book/cs/v2/GitHub-P%c5%99isp%c3%adv%c3%a1n%c3%ad-do-projektu">Čeština</a>,</td></tr> <tr><td><a href="/book/mk/v2/GitHub-%d0%9f%d1%80%d0%b8%d0%b4%d0%be%d0%bd%d0%b5%d1%81-%d0%ba%d0%be%d0%bd-%d0%bf%d1%80%d0%be%d0%b5%d0%ba%d1%82">Македонски</a>,</td></tr> <tr><td><a href="/book/pl/v2/GitHub-Contributing-to-a-Project">Polski</a>,</td></tr> <tr><td><a href="/book/sr/v2/GitHub-%d0%9a%d0%b0%d0%ba%d0%be-%d1%81%d0%b5-%d0%b4%d0%b0%d1%98%d0%b5-%d0%b4%d0%be%d0%bf%d1%80%d0%b8%d0%bd%d0%be%d1%81-%d0%bf%d1%80%d0%be%d1%98%d0%b5%d0%ba%d1%82%d1%83">Српски</a>,</td></tr> <tr><td><a href="/book/uz/v2/GitHub-Contributing-to-a-Project">Ўзбекча</a>,</td></tr> <tr><td><a href="/book/zh-tw/v2/GitHub-%e5%8f%83%e8%88%87%e4%b8%80%e5%80%8b%e5%b0%88%e6%a1%88">繁體中文</a>,</td></tr> </table> </p> <p> Translations started for <table> <tr><td><a href="/book/be/v2/GitHub-Contributing-to-a-Project">Беларуская</a>,</td></tr> <tr><td><a href="/book/fa/v2/GitHub-Contributing-to-a-Project" dir="rtl">فارسی</a>,</td></tr> <tr><td><a href="/book/id/v2/GitHub-Contributing-to-a-Project">Indonesian</a>,</td></tr> <tr><td><a href="/book/it/v2/GitHub-Contributing-to-a-Project">Italiano</a>,</td></tr> <tr><td><a href="/book/ms/v2/GitHub-Contributing-to-a-Project">Bahasa Melayu</a>,</td></tr> <tr><td><a href="/book/pt-br/v2/GitHub-Contribuindo-em-um-projeto">Português (Brasil)</a>,</td></tr> <tr><td><a href="/book/pt-pt/v2/GitHub-Contributing-to-a-Project">Português (Portugal)</a>,</td></tr> <tr><td><a href="/book/sv/v2/GitHub-Contributing-to-a-Project">Svenska</a>,</td></tr> <tr><td><a href="/book/tr/v2/GitHub-Proje-Bak%c4%b1m%c4%b1">Türkçe</a>.</td></tr> </table> </p> <hr class="sidebar"/> <p> The source of this book is <a href="https://github.com/progit2-sv/progit2">hosted on GitHub.</a></br> Patches, suggestions and comments are welcome. </p> </nav> </aside> <div id="content"> <div id="book-chapters"> <a class="dropdown-trigger" id="book-chapters-trigger" data-panel-id="chapters-dropdown" href="#">Chapters ▾</a> <div class='dropdown-panel' id='chapters-dropdown'> <div class='three-column'> <div class="column-left"> <ol class='book-toc'> <li class='chapter'> <h2>1. <a href="/book/sv/v2/Kom-ig%c3%a5ng-Om-versionshantering">Kom igång</a></h2> <ol> <li> 1.1 <a href="/book/sv/v2/Kom-ig%c3%a5ng-Om-versionshantering">Om versionshantering</a> </li> <li> 1.2 <a href="/book/sv/v2/Kom-ig%c3%a5ng-En-kort-historik-av-Git">En kort historik av Git</a> </li> <li> 1.3 <a href="/book/sv/v2/Kom-ig%c3%a5ng-Vad-%c3%a4r-Git%3F">Vad är Git?</a> </li> <li> 1.4 <a href="/book/sv/v2/Kom-ig%c3%a5ng-Kommandoraden">Kommandoraden</a> </li> <li> 1.5 <a href="/book/sv/v2/Kom-ig%c3%a5ng-Installera-Git">Installera Git</a> </li> <li> 1.6 <a href="/book/sv/v2/Kom-ig%c3%a5ng-Anv%c3%a4nda-Git-f%c3%b6r-f%c3%b6rsta-g%c3%a5ngen">Använda Git för första gången</a> </li> <li> 1.7 <a href="/book/sv/v2/Kom-ig%c3%a5ng-F%c3%a5-hj%c3%a4lp">Få hjälp</a> </li> <li> 1.8 <a href="/book/sv/v2/Kom-ig%c3%a5ng-Sammanfattning">Sammanfattning</a> </li> </ol> </li> <li class='chapter'> <h2>2. <a href="/book/sv/v2/Grunder-i-Git-Skaffa-ett-Git-f%c3%b6rvar">Grunder i Git</a></h2> <ol> <li> 2.1 <a href="/book/sv/v2/Grunder-i-Git-Skaffa-ett-Git-f%c3%b6rvar">Skaffa ett Git-förvar</a> </li> <li> 2.2 <a href="/book/sv/v2/Grunder-i-Git-Spara-%c3%a4ndringar-till-f%c3%b6rvaret">Spara ändringar till förvaret</a> </li> <li> 2.3 <a href="/book/sv/v2/Grunder-i-Git-Visa-historiken">Visa historiken</a> </li> <li> 2.4 <a href="/book/sv/v2/Grunder-i-Git-%c3%85ngra-saker">Ångra saker</a> </li> <li> 2.5 <a href="/book/sv/v2/Grunder-i-Git-Jobba-med-fj%c3%a4rrf%c3%b6rvar">Jobba med fjärrförvar</a> </li> <li> 2.6 <a href="/book/sv/v2/Grunder-i-Git-Taggning">Taggning</a> </li> <li> 2.7 <a href="/book/sv/v2/Grunder-i-Git-Git-alias">Git alias</a> </li> <li> 2.8 <a href="/book/sv/v2/Grunder-i-Git-Sammanfattning">Sammanfattning</a> </li> </ol> </li> <li class='chapter'> <h2>3. <a href="/book/sv/v2/Git-f%c3%b6rgreningar-Grenar-i-ett-n%c3%b6tskal">Git förgreningar</a></h2> <ol> <li> 3.1 <a href="/book/sv/v2/Git-f%c3%b6rgreningar-Grenar-i-ett-n%c3%b6tskal">Grenar i ett nötskal</a> </li> <li> 3.2 <a href="/book/sv/v2/Git-f%c3%b6rgreningar-Grundl%c3%a4ggande-f%c3%b6rgrening-och-sammanslagning">Grundläggande förgrening och sammanslagning</a> </li> <li> 3.3 <a href="/book/sv/v2/Git-f%c3%b6rgreningar-Hantera-grenar">Hantera grenar</a> </li> <li> 3.4 <a href="/book/sv/v2/Git-f%c3%b6rgreningar-Arbetsfl%c3%b6de-med-grenar">Arbetsflöde med grenar</a> </li> <li> 3.5 <a href="/book/sv/v2/Git-f%c3%b6rgreningar-Fj%c3%a4rrgrenar">Fjärrgrenar</a> </li> <li> 3.6 <a href="/book/sv/v2/Git-f%c3%b6rgreningar-Grenflytt">Grenflytt</a> </li> <li> 3.7 <a href="/book/sv/v2/Git-f%c3%b6rgreningar-Sammanfattning">Sammanfattning</a> </li> </ol> </li> <li class='chapter'> <h2>4. <a href="/book/sv/v2/Git-p%c3%a5-servern-Protokollen">Git på servern</a></h2> <ol> <li> 4.1 <a href="/book/sv/v2/Git-p%c3%a5-servern-Protokollen">Protokollen</a> </li> <li> 4.2 <a href="/book/sv/v2/Git-p%c3%a5-servern-Skaffa-Git-p%c3%a5-en-server">Skaffa Git på en server</a> </li> <li> 4.3 <a href="/book/sv/v2/Git-p%c3%a5-servern-Generera-din-publika-SSH-nyckel">Generera din publika SSH-nyckel</a> </li> <li> 4.4 <a href="/book/sv/v2/Git-p%c3%a5-servern-Konvigurera-servern">Konvigurera servern</a> </li> <li> 4.5 <a href="/book/sv/v2/Git-p%c3%a5-servern-Git-Daemonen">Git Daemonen</a> </li> <li> 4.6 <a href="/book/sv/v2/Git-p%c3%a5-servern-Smart-HTTP">Smart HTTP</a> </li> <li> 4.7 <a href="/book/sv/v2/Git-p%c3%a5-servern-GitWeb">GitWeb</a> </li> <li> 4.8 <a href="/book/sv/v2/Git-p%c3%a5-servern-GitLab">GitLab</a> </li> <li> 4.9 <a href="/book/sv/v2/Git-p%c3%a5-servern-Alternativ-tillhandah%c3%a5llna-av-tredje-part">Alternativ tillhandahållna av tredje part</a> </li> <li> 4.10 <a href="/book/sv/v2/Git-p%c3%a5-servern-Sammanfattning">Sammanfattning</a> </li> </ol> </li> <li class='chapter'> <h2>5. <a href="/book/sv/v2/Distribuerade-Git-Distribuerade-arbetsfl%c3%b6den">Distribuerade Git</a></h2> <ol> <li> 5.1 <a href="/book/sv/v2/Distribuerade-Git-Distribuerade-arbetsfl%c3%b6den">Distribuerade arbetsflöden</a> </li> <li> 5.2 <a href="/book/sv/v2/Distribuerade-Git-Medverka-i-ett-projekt">Medverka i ett projekt</a> </li> <li> 5.3 <a href="/book/sv/v2/Distribuerade-Git-Underh%c3%a5lla-ett-projekt">Underhålla ett projekt</a> </li> <li> 5.4 <a href="/book/sv/v2/Distribuerade-Git-Sammanfattning">Sammanfattning</a> </li> </ol> </li> </ol> </div> <div class='column-middle'> <ol class='book-toc'> <li class='chapter'> <h2>6. <a href="/book/sv/v2/GitHub-Account-Setup-and-Configuration">GitHub</a></h2> <ol> <li> 6.1 <a href="/book/sv/v2/GitHub-Account-Setup-and-Configuration">Account Setup and Configuration</a> </li> <li> 6.2 <a href="/book/sv/v2/GitHub-Contributing-to-a-Project" class="active">Contributing to a Project</a> </li> <li> 6.3 <a href="/book/sv/v2/GitHub-Maintaining-a-Project">Maintaining a Project</a> </li> <li> 6.4 <a href="/book/sv/v2/GitHub-Managing-an-organization">Managing an organization</a> </li> <li> 6.5 <a href="/book/sv/v2/GitHub-Scripting-GitHub">Scripting GitHub</a> </li> <li> 6.6 <a href="/book/sv/v2/GitHub-Summary">Summary</a> </li> </ol> </li> <li class='chapter'> <h2>7. <a href="/book/sv/v2/Git-Tools-Revision-Selection">Git Tools</a></h2> <ol> <li> 7.1 <a href="/book/sv/v2/Git-Tools-Revision-Selection">Revision Selection</a> </li> <li> 7.2 <a href="/book/sv/v2/Git-Tools-Interactive-Staging">Interactive Staging</a> </li> <li> 7.3 <a href="/book/sv/v2/Git-Tools-Stashing-and-Cleaning">Stashing and Cleaning</a> </li> <li> 7.4 <a href="/book/sv/v2/Git-Tools-Signing-Your-Work">Signing Your Work</a> </li> <li> 7.5 <a href="/book/sv/v2/Git-Tools-Searching">Searching</a> </li> <li> 7.6 <a href="/book/sv/v2/Git-Tools-Rewriting-History">Rewriting History</a> </li> <li> 7.7 <a href="/book/sv/v2/Git-Tools-Reset-Demystified">Reset Demystified</a> </li> <li> 7.8 <a href="/book/sv/v2/Git-Tools-Advanced-Merging">Advanced Merging</a> </li> <li> 7.9 <a href="/book/sv/v2/Git-Tools-Rerere">Rerere</a> </li> <li> 7.10 <a href="/book/sv/v2/Git-Tools-Debugging-with-Git">Debugging with Git</a> </li> <li> 7.11 <a href="/book/sv/v2/Git-Tools-Submodules">Submodules</a> </li> <li> 7.12 <a href="/book/sv/v2/Git-Tools-Bundling">Bundling</a> </li> <li> 7.13 <a href="/book/sv/v2/Git-Tools-Replace">Replace</a> </li> <li> 7.14 <a href="/book/sv/v2/Git-Tools-Credential-Storage">Credential Storage</a> </li> <li> 7.15 <a href="/book/sv/v2/Git-Tools-Summary">Summary</a> </li> </ol> </li> <li class='chapter'> <h2>8. <a href="/book/sv/v2/Customizing-Git-Git-Configuration">Customizing Git</a></h2> <ol> <li> 8.1 <a href="/book/sv/v2/Customizing-Git-Git-Configuration">Git Configuration</a> </li> <li> 8.2 <a href="/book/sv/v2/Customizing-Git-Git-Attributes">Git Attributes</a> </li> <li> 8.3 <a href="/book/sv/v2/Customizing-Git-Git-Hooks">Git Hooks</a> </li> <li> 8.4 <a href="/book/sv/v2/Customizing-Git-An-Example-Git-Enforced-Policy">An Example Git-Enforced Policy</a> </li> <li> 8.5 <a href="/book/sv/v2/Customizing-Git-Summary">Summary</a> </li> </ol> </li> <li class='chapter'> <h2>9. <a href="/book/sv/v2/Git-and-Other-Systems-Git-as-a-Client">Git and Other Systems</a></h2> <ol> <li> 9.1 <a href="/book/sv/v2/Git-and-Other-Systems-Git-as-a-Client">Git as a Client</a> </li> <li> 9.2 <a href="/book/sv/v2/Git-and-Other-Systems-Migrating-to-Git">Migrating to Git</a> </li> <li> 9.3 <a href="/book/sv/v2/Git-and-Other-Systems-Summary">Summary</a> </li> </ol> </li> <li class='chapter'> <h2>10. <a href="/book/sv/v2/Git-Internals-Plumbing-and-Porcelain">Git Internals</a></h2> <ol> <li> 10.1 <a href="/book/sv/v2/Git-Internals-Plumbing-and-Porcelain">Plumbing and Porcelain</a> </li> <li> 10.2 <a href="/book/sv/v2/Git-Internals-Git-Objects">Git Objects</a> </li> <li> 10.3 <a href="/book/sv/v2/Git-Internals-Git-References">Git References</a> </li> <li> 10.4 <a href="/book/sv/v2/Git-Internals-Packfiles">Packfiles</a> </li> <li> 10.5 <a href="/book/sv/v2/Git-Internals-The-Refspec">The Refspec</a> </li> <li> 10.6 <a href="/book/sv/v2/Git-Internals-Transfer-Protocols">Transfer Protocols</a> </li> <li> 10.7 <a href="/book/sv/v2/Git-Internals-Maintenance-and-Data-Recovery">Maintenance and Data Recovery</a> </li> <li> 10.8 <a href="/book/sv/v2/Git-Internals-Environment-Variables">Environment Variables</a> </li> <li> 10.9 <a href="/book/sv/v2/Git-Internals-Summary">Summary</a> </li> </ol> </li> </ol> </div> <div class='column-right'> <ol class='book-toc'> <li class='chapter'> <h2>A1. <a href="/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Graphical-Interfaces">Bilaga A: Git in Other Environments</a></h2> <ol> <li> A1.1 <a href="/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Graphical-Interfaces">Graphical Interfaces</a> </li> <li> A1.2 <a href="/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Git-in-Visual-Studio">Git in Visual Studio</a> </li> <li> A1.3 <a href="/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Git-in-Eclipse">Git in Eclipse</a> </li> <li> A1.4 <a href="/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Git-in-Bash">Git in Bash</a> </li> <li> A1.5 <a href="/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Git-in-Zsh">Git in Zsh</a> </li> <li> A1.6 <a href="/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Git-in-PowerShell">Git in PowerShell</a> </li> <li> A1.7 <a href="/book/sv/v2/Bilaga-A:-Git-in-Other-Environments-Summary">Summary</a> </li> </ol> </li> <li class='chapter'> <h2>A2. <a href="/book/sv/v2/Bilaga-B:-Embedding-Git-in-your-Applications-Command-line-Git">Bilaga B: Embedding Git in your Applications</a></h2> <ol> <li> A2.1 <a href="/book/sv/v2/Bilaga-B:-Embedding-Git-in-your-Applications-Command-line-Git">Command-line Git</a> </li> <li> A2.2 <a href="/book/sv/v2/Bilaga-B:-Embedding-Git-in-your-Applications-Libgit2">Libgit2</a> </li> <li> A2.3 <a href="/book/sv/v2/Bilaga-B:-Embedding-Git-in-your-Applications-JGit">JGit</a> </li> <li> A2.4 <a href="/book/sv/v2/Bilaga-B:-Embedding-Git-in-your-Applications-go-git">go-git</a> </li> <li> A2.5 <a href="/book/sv/v2/Bilaga-B:-Embedding-Git-in-your-Applications-Dulwich">Dulwich</a> </li> </ol> </li> <li class='chapter'> <h2>A3. <a href="/book/sv/v2/Bilaga-C:-Git-Commands-Setup-and-Config">Bilaga C: Git Commands</a></h2> <ol> <li> A3.1 <a href="/book/sv/v2/Bilaga-C:-Git-Commands-Setup-and-Config">Setup and Config</a> </li> <li> A3.2 <a href="/book/sv/v2/Bilaga-C:-Git-Commands-Getting-and-Creating-Projects">Getting and Creating Projects</a> </li> <li> A3.3 <a href="/book/sv/v2/Bilaga-C:-Git-Commands-Basic-Snapshotting">Basic Snapshotting</a> </li> <li> A3.4 <a href="/book/sv/v2/Bilaga-C:-Git-Commands-Branching-and-Merging">Branching and Merging</a> </li> <li> A3.5 <a href="/book/sv/v2/Bilaga-C:-Git-Commands-Sharing-and-Updating-Projects">Sharing and Updating Projects</a> </li> <li> A3.6 <a href="/book/sv/v2/Bilaga-C:-Git-Commands-Inspection-and-Comparison">Inspection and Comparison</a> </li> <li> A3.7 <a href="/book/sv/v2/Bilaga-C:-Git-Commands-Debugging">Debugging</a> </li> <li> A3.8 <a href="/book/sv/v2/Bilaga-C:-Git-Commands-Patching">Patching</a> </li> <li> A3.9 <a href="/book/sv/v2/Bilaga-C:-Git-Commands-Email">Email</a> </li> <li> A3.10 <a href="/book/sv/v2/Bilaga-C:-Git-Commands-External-Systems">External Systems</a> </li> <li> A3.11 <a href="/book/sv/v2/Bilaga-C:-Git-Commands-Administration">Administration</a> </li> <li> A3.12 <a href="/book/sv/v2/Bilaga-C:-Git-Commands-Plumbing-Commands">Plumbing Commands</a> </li> </ol> </li> </ol> </div> </div> </div> <span class="light" id="edition"> 2nd Edition </span> </div> <div id="main" data-pagefind-filter="category:book" data-pagefind-meta="category:Book" data-pagefind-weight="0.05" data-pagefind-body class="book edition2"> <h1>6.2 GitHub - Contributing to a Project</h1> <div> <h2 id="_contributing_to_a_project">Contributing to a Project</h2> <div class="paragraph"> <p>Now that our account is set up, let’s walk through some details that could be useful in helping you contribute to an existing project.</p> </div> <div class="sect3"> <h3 id="_forking_projects">Forking Projects</h3> <div class="paragraph"> <p> If you want to contribute to an existing project to which you don’t have push access, you can “fork” the project. When you “fork” a project, GitHub will make a copy of the project that is entirely yours; it lives in your namespace, and you can push to it.</p> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <div class="title">Notera</div> </td> <td class="content"> <div class="paragraph"> <p>Historically, the term “fork” has been somewhat negative in context, meaning that someone took an open source project in a different direction, sometimes creating a competing project and splitting the contributors. In GitHub, a “fork” is simply the same project in your own namespace, allowing you to make changes to a project publicly as a way to contribute in a more open manner.</p> </div> </td> </tr> </table> </div> <div class="paragraph"> <p>This way, projects don’t have to worry about adding users as collaborators to give them push access. People can fork a project, push to it, and contribute their changes back to the original repository by creating what’s called a Pull Request, which we’ll cover next. This opens up a discussion thread with code review, and the owner and the contributor can then communicate about the change until the owner is happy with it, at which point the owner can merge it in.</p> </div> <div class="paragraph"> <p>To fork a project, visit the project page and click the “Fork” button at the top-right of the page.</p> </div> <div class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/forkbutton.png" alt="The ``Fork'' button."> </div> <div class="title">Figur 89. The “Fork” button.</div> </div> <div class="paragraph"> <p>After a few seconds, you’ll be taken to your new project page, with your own writeable copy of the code.</p> </div> </div> <div class="sect3"> <h3 id="ch06-github_flow">The GitHub Flow</h3> <div class="paragraph"> <p> GitHub is designed around a particular collaboration workflow, centered on Pull Requests. This flow works whether you’re collaborating with a tightly-knit team in a single shared repository, or a globally-distributed company or network of strangers contributing to a project through dozens of forks. It is centered on the <a href="/book/sv/v2/ch00/_topic_branch">Ämnesgrenar</a> workflow covered in <a href="/book/sv/v2/ch00/ch03-git-branching">Git förgreningar</a>.</p> </div> <div class="paragraph"> <p>Here’s how it generally works:</p> </div> <div class="olist arabic"> <ol class="arabic"> <li> <p>Fork the project</p> </li> <li> <p>Create a topic branch from <code>master</code>.</p> </li> <li> <p>Make some commits to improve the project.</p> </li> <li> <p>Push this branch to your GitHub project.</p> </li> <li> <p>Open a Pull Request on GitHub.</p> </li> <li> <p>Discuss, and optionally continue committing.</p> </li> <li> <p>The project owner merges or closes the Pull Request.</p> </li> </ol> </div> <div class="paragraph"> <p>This is basically the Integration Manager workflow covered in <a href="/book/sv/v2/ch00/_integration_manager">Integrationsstyrd arbetsprocess</a>, but instead of using email to communicate and review changes, teams use GitHub’s web based tools.</p> </div> <div class="paragraph"> <p>Let’s walk through an example of proposing a change to an open source project hosted on GitHub using this flow.</p> </div> <div class="sect4"> <h4 id="_creating_a_pull_request">Creating a Pull Request</h4> <div class="paragraph"> <p>Tony is looking for code to run on his Arduino programmable microcontroller and has found a great program file on GitHub at <a href="https://github.com/schacon/blink" class="bare">https://github.com/schacon/blink</a>.</p> </div> <div class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/blink-01-start.png" alt="The project we want to contribute to."> </div> <div class="title">Figur 90. The project we want to contribute to.</div> </div> <div class="paragraph"> <p>The only problem is that the blinking rate is too fast. We think it’s much nicer to wait 3 seconds instead of 1 in between each state change. So let’s improve the program and submit it back to the project as a proposed change.</p> </div> <div class="paragraph"> <p>First, we click the <em>Fork</em> button as mentioned earlier to get our own copy of the project. Our user name here is “tonychacon” so our copy of this project is at <code>https://github.com/tonychacon/blink</code> and that’s where we can edit it. We will clone it locally, create a topic branch, make the code change and finally push that change back up to GitHub.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-console" data-lang="console">$ git clone https://github.com/tonychacon/blink <b class="conum">(1)</b> Cloning into 'blink'... $ cd blink $ git checkout -b slow-blink <b class="conum">(2)</b> Switched to a new branch 'slow-blink' $ sed -i '' 's/1000/3000/' blink.ino (macOS) <b class="conum">(3)</b> # If you're on a Linux system, do this instead: # $ sed -i 's/1000/3000/' blink.ino <b class="conum">(3)</b> $ git diff --word-diff <b class="conum">(4)</b> diff --git a/blink.ino b/blink.ino index 15b9911..a6cc5a5 100644 --- a/blink.ino +++ b/blink.ino @@ -18,7 +18,7 @@ void setup() { // the loop routine runs over and over again forever: void loop() { digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level) [-delay(1000);-]{+delay(3000);+} // wait for a second digitalWrite(led, LOW); // turn the LED off by making the voltage LOW [-delay(1000);-]{+delay(3000);+} // wait for a second } $ git commit -a -m 'three seconds is better' <b class="conum">(5)</b> [slow-blink 5ca509d] three seconds is better 1 file changed, 2 insertions(+), 2 deletions(-) $ git push origin slow-blink <b class="conum">(6)</b> Username for 'https://github.com': tonychacon Password for 'https://tonychacon@github.com': Counting objects: 5, done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 340 bytes | 0 bytes/s, done. Total 3 (delta 1), reused 0 (delta 0) To https://github.com/tonychacon/blink * [new branch] slow-blink -> slow-blink</code></pre> </div> </div> <div class="colist arabic"> <ol> <li> <p>Clone our fork of the project locally</p> </li> <li> <p>Create a descriptive topic branch</p> </li> <li> <p>Make our change to the code</p> </li> <li> <p>Check that the change is good</p> </li> <li> <p>Commit our change to the topic branch</p> </li> <li> <p>Push our new topic branch back up to our GitHub fork</p> </li> </ol> </div> <div class="paragraph"> <p>Now if we go back to our fork on GitHub, we can see that GitHub noticed that we pushed a new topic branch up and presents us with a big green button to check out our changes and open a Pull Request to the original project.</p> </div> <div class="paragraph"> <p>You can alternatively go to the “Branches” page at <code>https://github.com/<user>/<project>/branches</code> to locate your branch and open a new Pull Request from there.</p> </div> <div class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/blink-02-pr.png" alt="Pull Request button"> </div> <div class="title">Figur 91. Pull Request button</div> </div> <div class="paragraph"> <p> If we click that green button, we’ll see a screen that asks us to give our Pull Request a title and description. It is almost always worthwhile to put some effort into this, since a good description helps the owner of the original project determine what you were trying to do, whether your proposed changes are correct, and whether accepting the changes would improve the original project.</p> </div> <div class="paragraph"> <p>We also see a list of the commits in our topic branch that are “ahead” of the <code>master</code> branch (in this case, just the one) and a unified diff of all the changes that will be made should this branch get merged by the project owner.</p> </div> <div class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/blink-03-pull-request-open.png" alt="Pull Request creation"> </div> <div class="title">Figur 92. Pull Request creation page</div> </div> <div class="paragraph"> <p>When you hit the <em>Create pull request</em> button on this screen, the owner of the project you forked will get a notification that someone is suggesting a change and will link to a page that has all of this information on it.</p> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <div class="title">Notera</div> </td> <td class="content"> <div class="paragraph"> <p>Though Pull Requests are used commonly for public projects like this when the contributor has a complete change ready to be made, it’s also often used in internal projects <em>at the beginning</em> of the development cycle. Since you can keep pushing to the topic branch even <strong>after</strong> the Pull Request is opened, it’s often opened early and used as a way to iterate on work as a team within a context, rather than opened at the very end of the process.</p> </div> </td> </tr> </table> </div> </div> <div class="sect4"> <h4 id="_iterating_on_a_pull_request">Iterating on a Pull Request</h4> <div class="paragraph"> <p>At this point, the project owner can look at the suggested change and merge it, reject it or comment on it. Let’s say that he likes the idea, but would prefer a slightly longer time for the light to be off than on.</p> </div> <div class="paragraph"> <p>Where this conversation may take place over email in the workflows presented in <a href="/book/sv/v2/ch00/ch05-distributed-git">Distribuerade Git</a>, on GitHub this happens online. The project owner can review the unified diff and leave a comment by clicking on any of the lines.</p> </div> <div class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/blink-04-pr-comment.png" alt="PR line comment"> </div> <div class="title">Figur 93. Comment on a specific line of code in a Pull Request</div> </div> <div class="paragraph"> <p>Once the maintainer makes this comment, the person who opened the Pull Request (and indeed, anyone else watching the repository) will get a notification. We’ll go over customizing this later, but if he had email notifications turned on, Tony would get an email like this:</p> </div> <div id="_email_notification" class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/blink-04-email.png" alt="Email notification"> </div> <div class="title">Figur 94. Comments sent as email notifications</div> </div> <div class="paragraph"> <p>Anyone can also leave general comments on the Pull Request. In <a href="/book/sv/v2/ch00/_pr_discussion">Pull Request discussion page</a> we can see an example of the project owner both commenting on a line of code and then leaving a general comment in the discussion section. You can see that the code comments are brought into the conversation as well.</p> </div> <div id="_pr_discussion" class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/blink-05-general-comment.png" alt="PR discussion page"> </div> <div class="title">Figur 95. Pull Request discussion page</div> </div> <div class="paragraph"> <p>Now the contributor can see what they need to do in order to get their change accepted. Luckily this is very straightforward. Where over email you may have to re-roll your series and resubmit it to the mailing list, with GitHub you simply commit to the topic branch again and push, which will automatically update the Pull Request. In <a href="/book/sv/v2/ch00/_pr_final">Pull Request final</a> you can also see that the old code comment has been collapsed in the updated Pull Request, since it was made on a line that has since been changed.</p> </div> <div class="paragraph"> <p>Adding commits to an existing Pull Request doesn’t trigger a notification, so once Tony has pushed his corrections he decides to leave a comment to inform the project owner that he made the requested change.</p> </div> <div id="_pr_final" class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/blink-06-final.png" alt="PR final"> </div> <div class="title">Figur 96. Pull Request final</div> </div> <div class="paragraph"> <p>An interesting thing to notice is that if you click on the “Files Changed” tab on this Pull Request, you’ll get the “unified” diff — that is, the total aggregate difference that would be introduced to your main branch if this topic branch was merged in. In <code>git diff</code> terms, it basically automatically shows you <code>git diff master...<branch></code> for the branch this Pull Request is based on. See <a href="/book/sv/v2/ch00/_what_is_introduced">Avgöra vad som ska integreras</a> for more about this type of diff.</p> </div> <div class="paragraph"> <p>The other thing you’ll notice is that GitHub checks to see if the Pull Request merges cleanly and provides a button to do the merge for you on the server. This button only shows up if you have write access to the repository and a trivial merge is possible. If you click it GitHub will perform a “non-fast-forward” merge, meaning that even if the merge <strong>could</strong> be a fast-forward, it will still create a merge commit.</p> </div> <div class="paragraph"> <p>If you would prefer, you can simply pull the branch down and merge it locally. If you merge this branch into the <code>master</code> branch and push it to GitHub, the Pull Request will automatically be closed.</p> </div> <div class="paragraph"> <p>This is the basic workflow that most GitHub projects use. Topic branches are created, Pull Requests are opened on them, a discussion ensues, possibly more work is done on the branch and eventually the request is either closed or merged.</p> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <div class="title">Notera</div> </td> <td class="content"> <div class="title">Not Only Forks</div> <div class="paragraph"> <p>It’s important to note that you can also open a Pull Request between two branches in the same repository. If you’re working on a feature with someone and you both have write access to the project, you can push a topic branch to the repository and open a Pull Request on it to the <code>master</code> branch of that same project to initiate the code review and discussion process. No forking necessary.</p> </div> </td> </tr> </table> </div> </div> </div> <div class="sect3"> <h3 id="_advanced_pull_requests">Advanced Pull Requests</h3> <div class="paragraph"> <p>Now that we’ve covered the basics of contributing to a project on GitHub, let’s cover a few interesting tips and tricks about Pull Requests so you can be more effective in using them.</p> </div> <div class="sect4"> <h4 id="_pull_requests_as_patches">Pull Requests as Patches</h4> <div class="paragraph"> <p>It’s important to understand that many projects don’t really think of Pull Requests as queues of perfect patches that should apply cleanly in order, as most mailing list-based projects think of patch series contributions. Most GitHub projects think about Pull Request branches as iterative conversations around a proposed change, culminating in a unified diff that is applied by merging.</p> </div> <div class="paragraph"> <p>This is an important distinction, because generally the change is suggested before the code is thought to be perfect, which is far more rare with mailing list based patch series contributions. This enables an earlier conversation with the maintainers so that arriving at the proper solution is more of a community effort. When code is proposed with a Pull Request and the maintainers or community suggest a change, the patch series is generally not re-rolled, but instead the difference is pushed as a new commit to the branch, moving the conversation forward with the context of the previous work intact.</p> </div> <div class="paragraph"> <p>For instance, if you go back and look again at <a href="/book/sv/v2/ch00/_pr_final">Pull Request final</a>, you’ll notice that the contributor did not rebase his commit and send another Pull Request. Instead they added new commits and pushed them to the existing branch. This way if you go back and look at this Pull Request in the future, you can easily find all of the context of why decisions were made. Pushing the “Merge” button on the site purposefully creates a merge commit that references the Pull Request so that it’s easy to go back and research the original conversation if necessary.</p> </div> </div> <div class="sect4"> <h4 id="_keeping_up_with_upstream">Keeping up with Upstream</h4> <div class="paragraph"> <p>If your Pull Request becomes out of date or otherwise doesn’t merge cleanly, you will want to fix it so the maintainer can easily merge it. GitHub will test this for you and let you know at the bottom of every Pull Request if the merge is trivial or not.</p> </div> <div id="_pr_fail" class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/pr-01-fail.png" alt="PR merge failure"> </div> <div class="title">Figur 97. Pull Request does not merge cleanly</div> </div> <div class="paragraph"> <p>If you see something like <a href="/book/sv/v2/ch00/_pr_fail">Pull Request does not merge cleanly</a>, you’ll want to fix your branch so that it turns green and the maintainer doesn’t have to do extra work.</p> </div> <div class="paragraph"> <p>You have two main options in order to do this. You can either rebase your branch on top of whatever the target branch is (normally the <code>master</code> branch of the repository you forked), or you can merge the target branch into your branch.</p> </div> <div class="paragraph"> <p>Most developers on GitHub will choose to do the latter, for the same reasons we just went over in the previous section. What matters is the history and the final merge, so rebasing isn’t getting you much other than a slightly cleaner history and in return is <strong>far</strong> more difficult and error prone.</p> </div> <div class="paragraph"> <p>If you want to merge in the target branch to make your Pull Request mergeable, you would add the original repository as a new remote, fetch from it, merge the main branch of that repository into your topic branch, fix any issues and finally push it back up to the same branch you opened the Pull Request on.</p> </div> <div class="paragraph"> <p>For example, let’s say that in the “tonychacon” example we were using before, the original author made a change that would create a conflict in the Pull Request. Let’s go through those steps.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-console" data-lang="console">$ git remote add upstream https://github.com/schacon/blink <b class="conum">(1)</b> $ git fetch upstream <b class="conum">(2)</b> remote: Counting objects: 3, done. remote: Compressing objects: 100% (3/3), done. Unpacking objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0) From https://github.com/schacon/blink * [new branch] master -> upstream/master $ git merge upstream/master <b class="conum">(3)</b> Auto-merging blink.ino CONFLICT (content): Merge conflict in blink.ino Automatic merge failed; fix conflicts and then commit the result. $ vim blink.ino <b class="conum">(4)</b> $ git add blink.ino $ git commit [slow-blink 3c8d735] Merge remote-tracking branch 'upstream/master' \ into slower-blink $ git push origin slow-blink <b class="conum">(5)</b> Counting objects: 6, done. Delta compression using up to 8 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 682 bytes | 0 bytes/s, done. Total 6 (delta 2), reused 0 (delta 0) To https://github.com/tonychacon/blink ef4725c..3c8d735 slower-blink -> slow-blink</code></pre> </div> </div> <div class="colist arabic"> <ol> <li> <p>Add the original repository as a remote named “upstream”</p> </li> <li> <p>Fetch the newest work from that remote</p> </li> <li> <p>Merge the main branch of that repository into your topic branch</p> </li> <li> <p>Fix the conflict that occurred</p> </li> <li> <p>Push back up to the same topic branch</p> </li> </ol> </div> <div class="paragraph"> <p>Once you do that, the Pull Request will be automatically updated and re-checked to see if it merges cleanly.</p> </div> <div id="_pr_merge_fix" class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/pr-02-merge-fix.png" alt="PR fixed"> </div> <div class="title">Figur 98. Pull Request now merges cleanly</div> </div> <div class="paragraph"> <p>One of the great things about Git is that you can do that continuously. If you have a very long-running project, you can easily merge from the target branch over and over again and only have to deal with conflicts that have arisen since the last time that you merged, making the process very manageable.</p> </div> <div class="paragraph"> <p>If you absolutely wish to rebase the branch to clean it up, you can certainly do so, but it is highly encouraged to not force push over the branch that the Pull Request is already opened on. If other people have pulled it down and done more work on it, you run into all of the issues outlined in <a href="/book/sv/v2/ch00/_rebase_peril">Farorna med grenflyttar</a>. Instead, push the rebased branch to a new branch on GitHub and open a brand new Pull Request referencing the old one, then close the original.</p> </div> </div> <div class="sect4"> <h4 id="_references">References</h4> <div class="paragraph"> <p>Your next question may be “How do I reference the old Pull Request?”. It turns out there are many, many ways to reference other things almost anywhere you can write in GitHub.</p> </div> <div class="paragraph"> <p>Let’s start with how to cross-reference another Pull Request or an Issue. All Pull Requests and Issues are assigned numbers and they are unique within the project. For example, you can’t have Pull Request #3 <em>and</em> Issue #3. If you want to reference any Pull Request or Issue from any other one, you can simply put <code>#<num></code> in any comment or description. You can also be more specific if the Issue or Pull request lives somewhere else; write <code>username#<num></code> if you’re referring to an Issue or Pull Request in a fork of the repository you’re in, or <code>username/repo#<num></code> to reference something in another repository.</p> </div> <div class="paragraph"> <p>Let’s look at an example. Say we rebased the branch in the previous example, created a new pull request for it, and now we want to reference the old pull request from the new one. We also want to reference an issue in the fork of the repository and an issue in a completely different project. We can fill out the description just like <a href="/book/sv/v2/ch00/_pr_references">Cross references in a Pull Request.</a>.</p> </div> <div id="_pr_references" class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/mentions-01-syntax.png" alt="PR references"> </div> <div class="title">Figur 99. Cross references in a Pull Request.</div> </div> <div class="paragraph"> <p>When we submit this pull request, we’ll see all of that rendered like <a href="/book/sv/v2/ch00/_pr_references_render">Cross references rendered in a Pull Request.</a>.</p> </div> <div id="_pr_references_render" class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/mentions-02-render.png" alt="PR references rendered"> </div> <div class="title">Figur 100. Cross references rendered in a Pull Request.</div> </div> <div class="paragraph"> <p>Notice that the full GitHub URL we put in there was shortened to just the information needed.</p> </div> <div class="paragraph"> <p>Now if Tony goes back and closes out the original Pull Request, we can see that by mentioning it in the new one, GitHub has automatically created a trackback event in the Pull Request timeline. This means that anyone who visits this Pull Request and sees that it is closed can easily link back to the one that superseded it. The link will look something like <a href="/book/sv/v2/ch00/_pr_closed">Link back to the new Pull Request in the closed Pull Request timeline.</a>.</p> </div> <div id="_pr_closed" class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/mentions-03-closed.png" alt="PR closed"> </div> <div class="title">Figur 101. Link back to the new Pull Request in the closed Pull Request timeline.</div> </div> <div class="paragraph"> <p>In addition to issue numbers, you can also reference a specific commit by SHA-1. You have to specify a full 40 character SHA-1, but if GitHub sees that in a comment, it will link directly to the commit. Again, you can reference commits in forks or other repositories in the same way you did with issues.</p> </div> </div> </div> <div class="sect3"> <h3 id="_github_flavored_markdown">GitHub Flavored Markdown</h3> <div class="paragraph"> <p>Linking to other Issues is just the beginning of interesting things you can do with almost any text box on GitHub. In Issue and Pull Request descriptions, comments, code comments and more, you can use what is called “GitHub Flavored Markdown”. Markdown is like writing in plain text but which is rendered richly.</p> </div> <div class="paragraph"> <p>See <a href="/book/sv/v2/ch00/_example_markdown">An example of GitHub Flavored Markdown as written and as rendered.</a> for an example of how comments or text can be written and then rendered using Markdown.</p> </div> <div id="_example_markdown" class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/markdown-01-example.png" alt="Example Markdown"> </div> <div class="title">Figur 102. An example of GitHub Flavored Markdown as written and as rendered.</div> </div> <div class="paragraph"> <p>The GitHub flavor of Markdown adds more things you can do beyond the basic Markdown syntax. These can all be really useful when creating useful Pull Request or Issue comments or descriptions.</p> </div> <div class="sect4"> <h4 id="_task_lists">Task Lists</h4> <div class="paragraph"> <p>The first really useful GitHub specific Markdown feature, especially for use in Pull Requests, is the Task List. A task list is a list of checkboxes of things you want to get done. Putting them into an Issue or Pull Request normally indicates things that you want to get done before you consider the item complete.</p> </div> <div class="paragraph"> <p>You can create a task list like this:</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-text" data-lang="text">- [X] Write the code - [ ] Write all the tests - [ ] Document the code</code></pre> </div> </div> <div class="paragraph"> <p>If we include this in the description of our Pull Request or Issue, we’ll see it rendered like <a href="/book/sv/v2/ch00/_eg_task_lists">Task lists rendered in a Markdown comment.</a></p> </div> <div id="_eg_task_lists" class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/markdown-02-tasks.png" alt="Example Task List"> </div> <div class="title">Figur 103. Task lists rendered in a Markdown comment.</div> </div> <div class="paragraph"> <p>This is often used in Pull Requests to indicate what all you would like to get done on the branch before the Pull Request will be ready to merge. The really cool part is that you can simply click the checkboxes to update the comment — you don’t have to edit the Markdown directly to check tasks off.</p> </div> <div class="paragraph"> <p>What’s more, GitHub will look for task lists in your Issues and Pull Requests and show them as metadata on the pages that list them out. For example, if you have a Pull Request with tasks and you look at the overview page of all Pull Requests, you can see how far done it is. This helps people break down Pull Requests into subtasks and helps other people track the progress of the branch. You can see an example of this in <a href="/book/sv/v2/ch00/_task_list_progress">Task list summary in the Pull Request list.</a>.</p> </div> <div id="_task_list_progress" class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/markdown-03-task-summary.png" alt="Example Task List"> </div> <div class="title">Figur 104. Task list summary in the Pull Request list.</div> </div> <div class="paragraph"> <p>These are incredibly useful when you open a Pull Request early and use it to track your progress through the implementation of the feature.</p> </div> </div> <div class="sect4"> <h4 id="_code_snippets">Code Snippets</h4> <div class="paragraph"> <p>You can also add code snippets to comments. This is especially useful if you want to present something that you <em>could</em> try to do before actually implementing it as a commit on your branch. This is also often used to add example code of what is not working or what this Pull Request could implement.</p> </div> <div class="paragraph"> <p>To add a snippet of code you have to “fence” it in backticks.</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-text" data-lang="text">```java for(int i=0 ; i < 5 ; i++) { System.out.println("i is : " + i); } ```</code></pre> </div> </div> <div class="paragraph"> <p>If you add a language name like we did there with <em>java</em>, GitHub will also try to syntax highlight the snippet. In the case of the above example, it would end up rendering like <a href="/book/sv/v2/ch00/_md_code">Rendered fenced code example.</a>.</p> </div> <div id="_md_code" class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/markdown-04-fenced-code.png" alt="Rendered fenced code"> </div> <div class="title">Figur 105. Rendered fenced code example.</div> </div> </div> <div class="sect4"> <h4 id="_quoting">Quoting</h4> <div class="paragraph"> <p>If you’re responding to a small part of a long comment, you can selectively quote out of the other comment by preceding the lines with the <code>></code> character. In fact, this is so common and so useful that there is a keyboard shortcut for it. If you highlight text in a comment that you want to directly reply to and hit the <code>r</code> key, it will quote that text in the comment box for you.</p> </div> <div class="paragraph"> <p>The quotes look something like this:</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-text" data-lang="text">> Whether 'tis Nobler in the mind to suffer > The Slings and Arrows of outrageous Fortune, How big are these slings and in particular, these arrows?</code></pre> </div> </div> <div class="paragraph"> <p>Once rendered, the comment will look like <a href="/book/sv/v2/ch00/_md_quote">Rendered quoting example.</a>.</p> </div> <div id="_md_quote" class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/markdown-05-quote.png" alt="Rendered quoting"> </div> <div class="title">Figur 106. Rendered quoting example.</div> </div> </div> <div class="sect4"> <h4 id="_emoji">Emoji</h4> <div class="paragraph"> <p>Finally, you can also use emoji in your comments. This is actually used quite extensively in comments you see on many GitHub Issues and Pull Requests. There is even an emoji helper in GitHub. If you are typing a comment and you start with a <code>:</code> character, an autocompleter will help you find what you’re looking for.</p> </div> <div id="_md_emoji_auto" class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/markdown-06-emoji-complete.png" alt="Emoji autocompleter"> </div> <div class="title">Figur 107. Emoji autocompleter in action.</div> </div> <div class="paragraph"> <p>Emojis take the form of <code>:<name>:</code> anywhere in the comment. For instance, you could write something like this:</p> </div> <div class="listingblock"> <div class="content"> <pre class="highlight"><code class="language-text" data-lang="text">I :eyes: that :bug: and I :cold_sweat:. :trophy: for :microscope: it. :+1: and :sparkles: on this :ship:, it's :fire::poop:! :clap::tada::panda_face:</code></pre> </div> </div> <div class="paragraph"> <p>When rendered, it would look something like <a href="/book/sv/v2/ch00/_md_emoji">Heavy emoji commenting.</a>.</p> </div> <div id="_md_emoji" class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/markdown-07-emoji.png" alt="Emoji"> </div> <div class="title">Figur 108. Heavy emoji commenting.</div> </div> <div class="paragraph"> <p>Not that this is incredibly useful, but it does add an element of fun and emotion to a medium that is otherwise hard to convey emotion in.</p> </div> <div class="admonitionblock note"> <table> <tr> <td class="icon"> <div class="title">Notera</div> </td> <td class="content"> <div class="paragraph"> <p>There are actually quite a number of web services that make use of emoji characters these days. A great cheat sheet to reference to find emoji that expresses what you want to say can be found at:</p> </div> <div class="paragraph"> <p><a href="http://www.emoji-cheat-sheet.com" class="bare">http://www.emoji-cheat-sheet.com</a></p> </div> </td> </tr> </table> </div> </div> <div class="sect4"> <h4 id="_images">Images</h4> <div class="paragraph"> <p>This isn’t technically GitHub Flavored Markdown, but it is incredibly useful. In addition to adding Markdown image links to comments, which can be difficult to find and embed URLs for, GitHub allows you to drag and drop images into text areas to embed them.</p> </div> <div id="_md_drag" class="imageblock"> <div class="content"> <img src="/book/sv/v2/images/markdown-08-drag-drop.png" alt="Drag and drop images"> </div> <div class="title">Figur 109. Drag and drop images to upload them and auto-embed them.</div> </div> <div class="paragraph"> <p>If you look at <a href="/book/sv/v2/ch00/_md_drag">Drag and drop images to upload them and auto-embed them.</a>, you can see a small “Parsed as Markdown” hint above the text area. Clicking on that will give you a full cheat sheet of everything you can do with Markdown on GitHub.</p> </div> </div> </div> <div id="nav"><a href="/book/sv/v2/GitHub-Account-Setup-and-Configuration">prev</a> | <a href="/book/sv/v2/GitHub-Maintaining-a-Project">next</a></div> </div> </div> </div> </div> <footer> <div class="site-source"> <a href="/site">About this site</a><br> Patches, suggestions, and comments are welcome. </div> <div class="sfc-member"> Git is a member of <a href="/sfc">Software Freedom Conservancy</a> </div> </footer> <a href="#top" class="no-js scrollToTop" id="scrollToTop" data-label="Scroll to top"> <img src="/images/icons/chevron-up@2x.png" width="20" height="20" alt="scroll-to-top"/> </a> <script src="/js/jquery-1.7.1.min.js"></script> <script src="/js/jquery-ui-1.8.18.custom.min.js"></script> <script src="/js/jquery.defaultvalue.js"></script> <script src="/js/session.min.js"></script> <script src="/js/application.min.js"></script> </div> </body> </html>