"Fossies" - the Fresh Open Source Software Archive

Member "gitworkflows.html" (15 Dec 2018, 39895 Bytes) of package /linux/misc/git-htmldocs-2.20.1.tar.xz:


As a special service "Fossies" has tried to format the requested source page into HTML format using (guessed) HTML source code syntax highlighting (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 <?xml version="1.0" encoding="UTF-8"?>
    2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
    3     "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
    4 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
    5 <head>
    6 <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
    7 <meta name="generator" content="AsciiDoc 8.6.10" />
    8 <title>gitworkflows(7)</title>
    9 <style type="text/css">
   10 /* Shared CSS for AsciiDoc xhtml11 and html5 backends */
   11 
   12 /* Default font. */
   13 body {
   14   font-family: Georgia,serif;
   15 }
   16 
   17 /* Title font. */
   18 h1, h2, h3, h4, h5, h6,
   19 div.title, caption.title,
   20 thead, p.table.header,
   21 #toctitle,
   22 #author, #revnumber, #revdate, #revremark,
   23 #footer {
   24   font-family: Arial,Helvetica,sans-serif;
   25 }
   26 
   27 body {
   28   margin: 1em 5% 1em 5%;
   29 }
   30 
   31 a {
   32   color: blue;
   33   text-decoration: underline;
   34 }
   35 a:visited {
   36   color: fuchsia;
   37 }
   38 
   39 em {
   40   font-style: italic;
   41   color: navy;
   42 }
   43 
   44 strong {
   45   font-weight: bold;
   46   color: #083194;
   47 }
   48 
   49 h1, h2, h3, h4, h5, h6 {
   50   color: #527bbd;
   51   margin-top: 1.2em;
   52   margin-bottom: 0.5em;
   53   line-height: 1.3;
   54 }
   55 
   56 h1, h2, h3 {
   57   border-bottom: 2px solid silver;
   58 }
   59 h2 {
   60   padding-top: 0.5em;
   61 }
   62 h3 {
   63   float: left;
   64 }
   65 h3 + * {
   66   clear: left;
   67 }
   68 h5 {
   69   font-size: 1.0em;
   70 }
   71 
   72 div.sectionbody {
   73   margin-left: 0;
   74 }
   75 
   76 hr {
   77   border: 1px solid silver;
   78 }
   79 
   80 p {
   81   margin-top: 0.5em;
   82   margin-bottom: 0.5em;
   83 }
   84 
   85 ul, ol, li > p {
   86   margin-top: 0;
   87 }
   88 ul > li     { color: #aaa; }
   89 ul > li > * { color: black; }
   90 
   91 .monospaced, code, pre {
   92   font-family: "Courier New", Courier, monospace;
   93   font-size: inherit;
   94   color: navy;
   95   padding: 0;
   96   margin: 0;
   97 }
   98 pre {
   99   white-space: pre-wrap;
  100 }
  101 
  102 #author {
  103   color: #527bbd;
  104   font-weight: bold;
  105   font-size: 1.1em;
  106 }
  107 #email {
  108 }
  109 #revnumber, #revdate, #revremark {
  110 }
  111 
  112 #footer {
  113   font-size: small;
  114   border-top: 2px solid silver;
  115   padding-top: 0.5em;
  116   margin-top: 4.0em;
  117 }
  118 #footer-text {
  119   float: left;
  120   padding-bottom: 0.5em;
  121 }
  122 #footer-badges {
  123   float: right;
  124   padding-bottom: 0.5em;
  125 }
  126 
  127 #preamble {
  128   margin-top: 1.5em;
  129   margin-bottom: 1.5em;
  130 }
  131 div.imageblock, div.exampleblock, div.verseblock,
  132 div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
  133 div.admonitionblock {
  134   margin-top: 1.0em;
  135   margin-bottom: 1.5em;
  136 }
  137 div.admonitionblock {
  138   margin-top: 2.0em;
  139   margin-bottom: 2.0em;
  140   margin-right: 10%;
  141   color: #606060;
  142 }
  143 
  144 div.content { /* Block element content. */
  145   padding: 0;
  146 }
  147 
  148 /* Block element titles. */
  149 div.title, caption.title {
  150   color: #527bbd;
  151   font-weight: bold;
  152   text-align: left;
  153   margin-top: 1.0em;
  154   margin-bottom: 0.5em;
  155 }
  156 div.title + * {
  157   margin-top: 0;
  158 }
  159 
  160 td div.title:first-child {
  161   margin-top: 0.0em;
  162 }
  163 div.content div.title:first-child {
  164   margin-top: 0.0em;
  165 }
  166 div.content + div.title {
  167   margin-top: 0.0em;
  168 }
  169 
  170 div.sidebarblock > div.content {
  171   background: #ffffee;
  172   border: 1px solid #dddddd;
  173   border-left: 4px solid #f0f0f0;
  174   padding: 0.5em;
  175 }
  176 
  177 div.listingblock > div.content {
  178   border: 1px solid #dddddd;
  179   border-left: 5px solid #f0f0f0;
  180   background: #f8f8f8;
  181   padding: 0.5em;
  182 }
  183 
  184 div.quoteblock, div.verseblock {
  185   padding-left: 1.0em;
  186   margin-left: 1.0em;
  187   margin-right: 10%;
  188   border-left: 5px solid #f0f0f0;
  189   color: #888;
  190 }
  191 
  192 div.quoteblock > div.attribution {
  193   padding-top: 0.5em;
  194   text-align: right;
  195 }
  196 
  197 div.verseblock > pre.content {
  198   font-family: inherit;
  199   font-size: inherit;
  200 }
  201 div.verseblock > div.attribution {
  202   padding-top: 0.75em;
  203   text-align: left;
  204 }
  205 /* DEPRECATED: Pre version 8.2.7 verse style literal block. */
  206 div.verseblock + div.attribution {
  207   text-align: left;
  208 }
  209 
  210 div.admonitionblock .icon {
  211   vertical-align: top;
  212   font-size: 1.1em;
  213   font-weight: bold;
  214   text-decoration: underline;
  215   color: #527bbd;
  216   padding-right: 0.5em;
  217 }
  218 div.admonitionblock td.content {
  219   padding-left: 0.5em;
  220   border-left: 3px solid #dddddd;
  221 }
  222 
  223 div.exampleblock > div.content {
  224   border-left: 3px solid #dddddd;
  225   padding-left: 0.5em;
  226 }
  227 
  228 div.imageblock div.content { padding-left: 0; }
  229 span.image img { border-style: none; vertical-align: text-bottom; }
  230 a.image:visited { color: white; }
  231 
  232 dl {
  233   margin-top: 0.8em;
  234   margin-bottom: 0.8em;
  235 }
  236 dt {
  237   margin-top: 0.5em;
  238   margin-bottom: 0;
  239   font-style: normal;
  240   color: navy;
  241 }
  242 dd > *:first-child {
  243   margin-top: 0.1em;
  244 }
  245 
  246 ul, ol {
  247     list-style-position: outside;
  248 }
  249 ol.arabic {
  250   list-style-type: decimal;
  251 }
  252 ol.loweralpha {
  253   list-style-type: lower-alpha;
  254 }
  255 ol.upperalpha {
  256   list-style-type: upper-alpha;
  257 }
  258 ol.lowerroman {
  259   list-style-type: lower-roman;
  260 }
  261 ol.upperroman {
  262   list-style-type: upper-roman;
  263 }
  264 
  265 div.compact ul, div.compact ol,
  266 div.compact p, div.compact p,
  267 div.compact div, div.compact div {
  268   margin-top: 0.1em;
  269   margin-bottom: 0.1em;
  270 }
  271 
  272 tfoot {
  273   font-weight: bold;
  274 }
  275 td > div.verse {
  276   white-space: pre;
  277 }
  278 
  279 div.hdlist {
  280   margin-top: 0.8em;
  281   margin-bottom: 0.8em;
  282 }
  283 div.hdlist tr {
  284   padding-bottom: 15px;
  285 }
  286 dt.hdlist1.strong, td.hdlist1.strong {
  287   font-weight: bold;
  288 }
  289 td.hdlist1 {
  290   vertical-align: top;
  291   font-style: normal;
  292   padding-right: 0.8em;
  293   color: navy;
  294 }
  295 td.hdlist2 {
  296   vertical-align: top;
  297 }
  298 div.hdlist.compact tr {
  299   margin: 0;
  300   padding-bottom: 0;
  301 }
  302 
  303 .comment {
  304   background: yellow;
  305 }
  306 
  307 .footnote, .footnoteref {
  308   font-size: 0.8em;
  309 }
  310 
  311 span.footnote, span.footnoteref {
  312   vertical-align: super;
  313 }
  314 
  315 #footnotes {
  316   margin: 20px 0 20px 0;
  317   padding: 7px 0 0 0;
  318 }
  319 
  320 #footnotes div.footnote {
  321   margin: 0 0 5px 0;
  322 }
  323 
  324 #footnotes hr {
  325   border: none;
  326   border-top: 1px solid silver;
  327   height: 1px;
  328   text-align: left;
  329   margin-left: 0;
  330   width: 20%;
  331   min-width: 100px;
  332 }
  333 
  334 div.colist td {
  335   padding-right: 0.5em;
  336   padding-bottom: 0.3em;
  337   vertical-align: top;
  338 }
  339 div.colist td img {
  340   margin-top: 0.3em;
  341 }
  342 
  343 @media print {
  344   #footer-badges { display: none; }
  345 }
  346 
  347 #toc {
  348   margin-bottom: 2.5em;
  349 }
  350 
  351 #toctitle {
  352   color: #527bbd;
  353   font-size: 1.1em;
  354   font-weight: bold;
  355   margin-top: 1.0em;
  356   margin-bottom: 0.1em;
  357 }
  358 
  359 div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
  360   margin-top: 0;
  361   margin-bottom: 0;
  362 }
  363 div.toclevel2 {
  364   margin-left: 2em;
  365   font-size: 0.9em;
  366 }
  367 div.toclevel3 {
  368   margin-left: 4em;
  369   font-size: 0.9em;
  370 }
  371 div.toclevel4 {
  372   margin-left: 6em;
  373   font-size: 0.9em;
  374 }
  375 
  376 span.aqua { color: aqua; }
  377 span.black { color: black; }
  378 span.blue { color: blue; }
  379 span.fuchsia { color: fuchsia; }
  380 span.gray { color: gray; }
  381 span.green { color: green; }
  382 span.lime { color: lime; }
  383 span.maroon { color: maroon; }
  384 span.navy { color: navy; }
  385 span.olive { color: olive; }
  386 span.purple { color: purple; }
  387 span.red { color: red; }
  388 span.silver { color: silver; }
  389 span.teal { color: teal; }
  390 span.white { color: white; }
  391 span.yellow { color: yellow; }
  392 
  393 span.aqua-background { background: aqua; }
  394 span.black-background { background: black; }
  395 span.blue-background { background: blue; }
  396 span.fuchsia-background { background: fuchsia; }
  397 span.gray-background { background: gray; }
  398 span.green-background { background: green; }
  399 span.lime-background { background: lime; }
  400 span.maroon-background { background: maroon; }
  401 span.navy-background { background: navy; }
  402 span.olive-background { background: olive; }
  403 span.purple-background { background: purple; }
  404 span.red-background { background: red; }
  405 span.silver-background { background: silver; }
  406 span.teal-background { background: teal; }
  407 span.white-background { background: white; }
  408 span.yellow-background { background: yellow; }
  409 
  410 span.big { font-size: 2em; }
  411 span.small { font-size: 0.6em; }
  412 
  413 span.underline { text-decoration: underline; }
  414 span.overline { text-decoration: overline; }
  415 span.line-through { text-decoration: line-through; }
  416 
  417 div.unbreakable { page-break-inside: avoid; }
  418 
  419 
  420 /*
  421  * xhtml11 specific
  422  *
  423  * */
  424 
  425 div.tableblock {
  426   margin-top: 1.0em;
  427   margin-bottom: 1.5em;
  428 }
  429 div.tableblock > table {
  430   border: 3px solid #527bbd;
  431 }
  432 thead, p.table.header {
  433   font-weight: bold;
  434   color: #527bbd;
  435 }
  436 p.table {
  437   margin-top: 0;
  438 }
  439 /* Because the table frame attribute is overriden by CSS in most browsers. */
  440 div.tableblock > table[frame="void"] {
  441   border-style: none;
  442 }
  443 div.tableblock > table[frame="hsides"] {
  444   border-left-style: none;
  445   border-right-style: none;
  446 }
  447 div.tableblock > table[frame="vsides"] {
  448   border-top-style: none;
  449   border-bottom-style: none;
  450 }
  451 
  452 
  453 /*
  454  * html5 specific
  455  *
  456  * */
  457 
  458 table.tableblock {
  459   margin-top: 1.0em;
  460   margin-bottom: 1.5em;
  461 }
  462 thead, p.tableblock.header {
  463   font-weight: bold;
  464   color: #527bbd;
  465 }
  466 p.tableblock {
  467   margin-top: 0;
  468 }
  469 table.tableblock {
  470   border-width: 3px;
  471   border-spacing: 0px;
  472   border-style: solid;
  473   border-color: #527bbd;
  474   border-collapse: collapse;
  475 }
  476 th.tableblock, td.tableblock {
  477   border-width: 1px;
  478   padding: 4px;
  479   border-style: solid;
  480   border-color: #527bbd;
  481 }
  482 
  483 table.tableblock.frame-topbot {
  484   border-left-style: hidden;
  485   border-right-style: hidden;
  486 }
  487 table.tableblock.frame-sides {
  488   border-top-style: hidden;
  489   border-bottom-style: hidden;
  490 }
  491 table.tableblock.frame-none {
  492   border-style: hidden;
  493 }
  494 
  495 th.tableblock.halign-left, td.tableblock.halign-left {
  496   text-align: left;
  497 }
  498 th.tableblock.halign-center, td.tableblock.halign-center {
  499   text-align: center;
  500 }
  501 th.tableblock.halign-right, td.tableblock.halign-right {
  502   text-align: right;
  503 }
  504 
  505 th.tableblock.valign-top, td.tableblock.valign-top {
  506   vertical-align: top;
  507 }
  508 th.tableblock.valign-middle, td.tableblock.valign-middle {
  509   vertical-align: middle;
  510 }
  511 th.tableblock.valign-bottom, td.tableblock.valign-bottom {
  512   vertical-align: bottom;
  513 }
  514 
  515 
  516 /*
  517  * manpage specific
  518  *
  519  * */
  520 
  521 body.manpage h1 {
  522   padding-top: 0.5em;
  523   padding-bottom: 0.5em;
  524   border-top: 2px solid silver;
  525   border-bottom: 2px solid silver;
  526 }
  527 body.manpage h2 {
  528   border-style: none;
  529 }
  530 body.manpage div.sectionbody {
  531   margin-left: 3em;
  532 }
  533 
  534 @media print {
  535   body.manpage div#toc { display: none; }
  536 }
  537 
  538 
  539 </style>
  540 <script type="text/javascript">
  541 /*<![CDATA[*/
  542 var asciidoc = {  // Namespace.
  543 
  544 /////////////////////////////////////////////////////////////////////
  545 // Table Of Contents generator
  546 /////////////////////////////////////////////////////////////////////
  547 
  548 /* Author: Mihai Bazon, September 2002
  549  * http://students.infoiasi.ro/~mishoo
  550  *
  551  * Table Of Content generator
  552  * Version: 0.4
  553  *
  554  * Feel free to use this script under the terms of the GNU General Public
  555  * License, as long as you do not remove or alter this notice.
  556  */
  557 
  558  /* modified by Troy D. Hanson, September 2006. License: GPL */
  559  /* modified by Stuart Rackham, 2006, 2009. License: GPL */
  560 
  561 // toclevels = 1..4.
  562 toc: function (toclevels) {
  563 
  564   function getText(el) {
  565     var text = "";
  566     for (var i = el.firstChild; i != null; i = i.nextSibling) {
  567       if (i.nodeType == 3 /* Node.TEXT_NODE */) // IE doesn't speak constants.
  568         text += i.data;
  569       else if (i.firstChild != null)
  570         text += getText(i);
  571     }
  572     return text;
  573   }
  574 
  575   function TocEntry(el, text, toclevel) {
  576     this.element = el;
  577     this.text = text;
  578     this.toclevel = toclevel;
  579   }
  580 
  581   function tocEntries(el, toclevels) {
  582     var result = new Array;
  583     var re = new RegExp('[hH]([1-'+(toclevels+1)+'])');
  584     // Function that scans the DOM tree for header elements (the DOM2
  585     // nodeIterator API would be a better technique but not supported by all
  586     // browsers).
  587     var iterate = function (el) {
  588       for (var i = el.firstChild; i != null; i = i.nextSibling) {
  589         if (i.nodeType == 1 /* Node.ELEMENT_NODE */) {
  590           var mo = re.exec(i.tagName);
  591           if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") {
  592             result[result.length] = new TocEntry(i, getText(i), mo[1]-1);
  593           }
  594           iterate(i);
  595         }
  596       }
  597     }
  598     iterate(el);
  599     return result;
  600   }
  601 
  602   var toc = document.getElementById("toc");
  603   if (!toc) {
  604     return;
  605   }
  606 
  607   // Delete existing TOC entries in case we're reloading the TOC.
  608   var tocEntriesToRemove = [];
  609   var i;
  610   for (i = 0; i < toc.childNodes.length; i++) {
  611     var entry = toc.childNodes[i];
  612     if (entry.nodeName.toLowerCase() == 'div'
  613      && entry.getAttribute("class")
  614      && entry.getAttribute("class").match(/^toclevel/))
  615       tocEntriesToRemove.push(entry);
  616   }
  617   for (i = 0; i < tocEntriesToRemove.length; i++) {
  618     toc.removeChild(tocEntriesToRemove[i]);
  619   }
  620 
  621   // Rebuild TOC entries.
  622   var entries = tocEntries(document.getElementById("content"), toclevels);
  623   for (var i = 0; i < entries.length; ++i) {
  624     var entry = entries[i];
  625     if (entry.element.id == "")
  626       entry.element.id = "_toc_" + i;
  627     var a = document.createElement("a");
  628     a.href = "#" + entry.element.id;
  629     a.appendChild(document.createTextNode(entry.text));
  630     var div = document.createElement("div");
  631     div.appendChild(a);
  632     div.className = "toclevel" + entry.toclevel;
  633     toc.appendChild(div);
  634   }
  635   if (entries.length == 0)
  636     toc.parentNode.removeChild(toc);
  637 },
  638 
  639 
  640 /////////////////////////////////////////////////////////////////////
  641 // Footnotes generator
  642 /////////////////////////////////////////////////////////////////////
  643 
  644 /* Based on footnote generation code from:
  645  * http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
  646  */
  647 
  648 footnotes: function () {
  649   // Delete existing footnote entries in case we're reloading the footnodes.
  650   var i;
  651   var noteholder = document.getElementById("footnotes");
  652   if (!noteholder) {
  653     return;
  654   }
  655   var entriesToRemove = [];
  656   for (i = 0; i < noteholder.childNodes.length; i++) {
  657     var entry = noteholder.childNodes[i];
  658     if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
  659       entriesToRemove.push(entry);
  660   }
  661   for (i = 0; i < entriesToRemove.length; i++) {
  662     noteholder.removeChild(entriesToRemove[i]);
  663   }
  664 
  665   // Rebuild footnote entries.
  666   var cont = document.getElementById("content");
  667   var spans = cont.getElementsByTagName("span");
  668   var refs = {};
  669   var n = 0;
  670   for (i=0; i<spans.length; i++) {
  671     if (spans[i].className == "footnote") {
  672       n++;
  673       var note = spans[i].getAttribute("data-note");
  674       if (!note) {
  675         // Use [\s\S] in place of . so multi-line matches work.
  676         // Because JavaScript has no s (dotall) regex flag.
  677         note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1];
  678         spans[i].innerHTML =
  679           "[<a id='_footnoteref_" + n + "' href='#_footnote_" + n +
  680           "' title='View footnote' class='footnote'>" + n + "</a>]";
  681         spans[i].setAttribute("data-note", note);
  682       }
  683       noteholder.innerHTML +=
  684         "<div class='footnote' id='_footnote_" + n + "'>" +
  685         "<a href='#_footnoteref_" + n + "' title='Return to text'>" +
  686         n + "</a>. " + note + "</div>";
  687       var id =spans[i].getAttribute("id");
  688       if (id != null) refs["#"+id] = n;
  689     }
  690   }
  691   if (n == 0)
  692     noteholder.parentNode.removeChild(noteholder);
  693   else {
  694     // Process footnoterefs.
  695     for (i=0; i<spans.length; i++) {
  696       if (spans[i].className == "footnoteref") {
  697         var href = spans[i].getElementsByTagName("a")[0].getAttribute("href");
  698         href = href.match(/#.*/)[0];  // Because IE return full URL.
  699         n = refs[href];
  700         spans[i].innerHTML =
  701           "[<a href='#_footnote_" + n +
  702           "' title='View footnote' class='footnote'>" + n + "</a>]";
  703       }
  704     }
  705   }
  706 },
  707 
  708 install: function(toclevels) {
  709   var timerId;
  710 
  711   function reinstall() {
  712     asciidoc.footnotes();
  713     if (toclevels) {
  714       asciidoc.toc(toclevels);
  715     }
  716   }
  717 
  718   function reinstallAndRemoveTimer() {
  719     clearInterval(timerId);
  720     reinstall();
  721   }
  722 
  723   timerId = setInterval(reinstall, 500);
  724   if (document.addEventListener)
  725     document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false);
  726   else
  727     window.onload = reinstallAndRemoveTimer;
  728 }
  729 
  730 }
  731 asciidoc.install();
  732 /*]]>*/
  733 </script>
  734 </head>
  735 <body class="manpage">
  736 <div id="header">
  737 <h1>
  738 gitworkflows(7) Manual Page
  739 </h1>
  740 <h2>NAME</h2>
  741 <div class="sectionbody">
  742 <p>gitworkflows -
  743    An overview of recommended workflows with Git
  744 </p>
  745 </div>
  746 </div>
  747 <div id="content">
  748 <div class="sect1">
  749 <h2 id="_synopsis">SYNOPSIS</h2>
  750 <div class="sectionbody">
  751 <div class="verseblock">
  752 <pre class="content">git *</pre>
  753 <div class="attribution">
  754 </div></div>
  755 </div>
  756 </div>
  757 <div class="sect1">
  758 <h2 id="_description">DESCRIPTION</h2>
  759 <div class="sectionbody">
  760 <div class="paragraph"><p>This document attempts to write down and motivate some of the workflow
  761 elements used for <code>git.git</code> itself.  Many ideas apply in general,
  762 though the full workflow is rarely required for smaller projects with
  763 fewer people involved.</p></div>
  764 <div class="paragraph"><p>We formulate a set of <em>rules</em> for quick reference, while the prose
  765 tries to motivate each of them.  Do not always take them literally;
  766 you should value good reasons for your actions higher than manpages
  767 such as this one.</p></div>
  768 </div>
  769 </div>
  770 <div class="sect1">
  771 <h2 id="_separate_changes">SEPARATE CHANGES</h2>
  772 <div class="sectionbody">
  773 <div class="paragraph"><p>As a general rule, you should try to split your changes into small
  774 logical steps, and commit each of them.  They should be consistent,
  775 working independently of any later commits, pass the test suite, etc.
  776 This makes the review process much easier, and the history much more
  777 useful for later inspection and analysis, for example with
  778 <a href="git-blame.html">git-blame(1)</a> and <a href="git-bisect.html">git-bisect(1)</a>.</p></div>
  779 <div class="paragraph"><p>To achieve this, try to split your work into small steps from the very
  780 beginning. It is always easier to squash a few commits together than
  781 to split one big commit into several.  Don&#8217;t be afraid of making too
  782 small or imperfect steps along the way. You can always go back later
  783 and edit the commits with <code>git rebase --interactive</code> before you
  784 publish them.  You can use <code>git stash push --keep-index</code> to run the
  785 test suite independent of other uncommitted changes; see the EXAMPLES
  786 section of <a href="git-stash.html">git-stash(1)</a>.</p></div>
  787 </div>
  788 </div>
  789 <div class="sect1">
  790 <h2 id="_managing_branches">MANAGING BRANCHES</h2>
  791 <div class="sectionbody">
  792 <div class="paragraph"><p>There are two main tools that can be used to include changes from one
  793 branch on another: <a href="git-merge.html">git-merge(1)</a> and
  794 <a href="git-cherry-pick.html">git-cherry-pick(1)</a>.</p></div>
  795 <div class="paragraph"><p>Merges have many advantages, so we try to solve as many problems as
  796 possible with merges alone.  Cherry-picking is still occasionally
  797 useful; see "Merging upwards" below for an example.</p></div>
  798 <div class="paragraph"><p>Most importantly, merging works at the branch level, while
  799 cherry-picking works at the commit level.  This means that a merge can
  800 carry over the changes from 1, 10, or 1000 commits with equal ease,
  801 which in turn means the workflow scales much better to a large number
  802 of contributors (and contributions).  Merges are also easier to
  803 understand because a merge commit is a "promise" that all changes from
  804 all its parents are now included.</p></div>
  805 <div class="paragraph"><p>There is a tradeoff of course: merges require a more careful branch
  806 management.  The following subsections discuss the important points.</p></div>
  807 <div class="sect2">
  808 <h3 id="_graduation">Graduation</h3>
  809 <div class="paragraph"><p>As a given feature goes from experimental to stable, it also
  810 "graduates" between the corresponding branches of the software.
  811 <code>git.git</code> uses the following <em>integration branches</em>:</p></div>
  812 <div class="ulist"><ul>
  813 <li>
  814 <p>
  815 <em>maint</em> tracks the commits that should go into the next "maintenance
  816   release", i.e., update of the last released stable version;
  817 </p>
  818 </li>
  819 <li>
  820 <p>
  821 <em>master</em> tracks the commits that should go into the next release;
  822 </p>
  823 </li>
  824 <li>
  825 <p>
  826 <em>next</em> is intended as a testing branch for topics being tested for
  827   stability for master.
  828 </p>
  829 </li>
  830 </ul></div>
  831 <div class="paragraph"><p>There is a fourth official branch that is used slightly differently:</p></div>
  832 <div class="ulist"><ul>
  833 <li>
  834 <p>
  835 <em>pu</em> (proposed updates) is an integration branch for things that are
  836   not quite ready for inclusion yet (see "Integration Branches"
  837   below).
  838 </p>
  839 </li>
  840 </ul></div>
  841 <div class="paragraph"><p>Each of the four branches is usually a direct descendant of the one
  842 above it.</p></div>
  843 <div class="paragraph"><p>Conceptually, the feature enters at an unstable branch (usually <em>next</em>
  844 or <em>pu</em>), and "graduates" to <em>master</em> for the next release once it is
  845 considered stable enough.</p></div>
  846 </div>
  847 <div class="sect2">
  848 <h3 id="_merging_upwards">Merging upwards</h3>
  849 <div class="paragraph"><p>The "downwards graduation" discussed above cannot be done by actually
  850 merging downwards, however, since that would merge <em>all</em> changes on
  851 the unstable branch into the stable one.  Hence the following:</p></div>
  852 <div class="exampleblock">
  853 <div class="title">Rule: Merge upwards</div>
  854 <div class="content">
  855 <div class="paragraph"><p>Always commit your fixes to the oldest supported branch that requires
  856 them.  Then (periodically) merge the integration branches upwards into each
  857 other.</p></div>
  858 </div></div>
  859 <div class="paragraph"><p>This gives a very controlled flow of fixes.  If you notice that you
  860 have applied a fix to e.g. <em>master</em> that is also required in <em>maint</em>,
  861 you will need to cherry-pick it (using <a href="git-cherry-pick.html">git-cherry-pick(1)</a>)
  862 downwards.  This will happen a few times and is nothing to worry about
  863 unless you do it very frequently.</p></div>
  864 </div>
  865 <div class="sect2">
  866 <h3 id="_topic_branches">Topic branches</h3>
  867 <div class="paragraph"><p>Any nontrivial feature will require several patches to implement, and
  868 may get extra bugfixes or improvements during its lifetime.</p></div>
  869 <div class="paragraph"><p>Committing everything directly on the integration branches leads to many
  870 problems: Bad commits cannot be undone, so they must be reverted one
  871 by one, which creates confusing histories and further error potential
  872 when you forget to revert part of a group of changes.  Working in
  873 parallel mixes up the changes, creating further confusion.</p></div>
  874 <div class="paragraph"><p>Use of "topic branches" solves these problems.  The name is pretty
  875 self explanatory, with a caveat that comes from the "merge upwards"
  876 rule above:</p></div>
  877 <div class="exampleblock">
  878 <div class="title">Rule: Topic branches</div>
  879 <div class="content">
  880 <div class="paragraph"><p>Make a side branch for every topic (feature, bugfix, &#8230;). Fork it off
  881 at the oldest integration branch that you will eventually want to merge it
  882 into.</p></div>
  883 </div></div>
  884 <div class="paragraph"><p>Many things can then be done very naturally:</p></div>
  885 <div class="ulist"><ul>
  886 <li>
  887 <p>
  888 To get the feature/bugfix into an integration branch, simply merge
  889   it.  If the topic has evolved further in the meantime, merge again.
  890   (Note that you do not necessarily have to merge it to the oldest
  891   integration branch first.  For example, you can first merge a bugfix
  892   to <em>next</em>, give it some testing time, and merge to <em>maint</em> when you
  893   know it is stable.)
  894 </p>
  895 </li>
  896 <li>
  897 <p>
  898 If you find you need new features from the branch <em>other</em> to continue
  899   working on your topic, merge <em>other</em> to <em>topic</em>.  (However, do not
  900   do this "just habitually", see below.)
  901 </p>
  902 </li>
  903 <li>
  904 <p>
  905 If you find you forked off the wrong branch and want to move it
  906   "back in time", use <a href="git-rebase.html">git-rebase(1)</a>.
  907 </p>
  908 </li>
  909 </ul></div>
  910 <div class="paragraph"><p>Note that the last point clashes with the other two: a topic that has
  911 been merged elsewhere should not be rebased.  See the section on
  912 RECOVERING FROM UPSTREAM REBASE in <a href="git-rebase.html">git-rebase(1)</a>.</p></div>
  913 <div class="paragraph"><p>We should point out that "habitually" (regularly for no real reason)
  914 merging an integration branch into your topics&#8201;&#8212;&#8201;and by extension,
  915 merging anything upstream into anything downstream on a regular basis&#8201;&#8212;&#8201;is frowned upon:</p></div>
  916 <div class="exampleblock">
  917 <div class="title">Rule: Merge to downstream only at well-defined points</div>
  918 <div class="content">
  919 <div class="paragraph"><p>Do not merge to downstream except with a good reason: upstream API
  920 changes affect your branch; your branch no longer merges to upstream
  921 cleanly; etc.</p></div>
  922 </div></div>
  923 <div class="paragraph"><p>Otherwise, the topic that was merged to suddenly contains more than a
  924 single (well-separated) change.  The many resulting small merges will
  925 greatly clutter up history.  Anyone who later investigates the history
  926 of a file will have to find out whether that merge affected the topic
  927 in development.  An upstream might even inadvertently be merged into a
  928 "more stable" branch.  And so on.</p></div>
  929 </div>
  930 <div class="sect2">
  931 <h3 id="_throw_away_integration">Throw-away integration</h3>
  932 <div class="paragraph"><p>If you followed the last paragraph, you will now have many small topic
  933 branches, and occasionally wonder how they interact.  Perhaps the
  934 result of merging them does not even work?  But on the other hand, we
  935 want to avoid merging them anywhere "stable" because such merges
  936 cannot easily be undone.</p></div>
  937 <div class="paragraph"><p>The solution, of course, is to make a merge that we can undo: merge
  938 into a throw-away branch.</p></div>
  939 <div class="exampleblock">
  940 <div class="title">Rule: Throw-away integration branches</div>
  941 <div class="content">
  942 <div class="paragraph"><p>To test the interaction of several topics, merge them into a
  943 throw-away branch.  You must never base any work on such a branch!</p></div>
  944 </div></div>
  945 <div class="paragraph"><p>If you make it (very) clear that this branch is going to be deleted
  946 right after the testing, you can even publish this branch, for example
  947 to give the testers a chance to work with it, or other developers a
  948 chance to see if their in-progress work will be compatible.  <code>git.git</code>
  949 has such an official throw-away integration branch called <em>pu</em>.</p></div>
  950 </div>
  951 <div class="sect2">
  952 <h3 id="_branch_management_for_a_release">Branch management for a release</h3>
  953 <div class="paragraph"><p>Assuming you are using the merge approach discussed above, when you
  954 are releasing your project you will need to do some additional branch
  955 management work.</p></div>
  956 <div class="paragraph"><p>A feature release is created from the <em>master</em> branch, since <em>master</em>
  957 tracks the commits that should go into the next feature release.</p></div>
  958 <div class="paragraph"><p>The <em>master</em> branch is supposed to be a superset of <em>maint</em>. If this
  959 condition does not hold, then <em>maint</em> contains some commits that
  960 are not included on <em>master</em>. The fixes represented by those commits
  961 will therefore not be included in your feature release.</p></div>
  962 <div class="paragraph"><p>To verify that <em>master</em> is indeed a superset of <em>maint</em>, use git log:</p></div>
  963 <div class="exampleblock">
  964 <div class="title">Recipe: Verify <em>master</em> is a superset of <em>maint</em></div>
  965 <div class="content">
  966 <div class="paragraph"><p><code>git log master..maint</code></p></div>
  967 </div></div>
  968 <div class="paragraph"><p>This command should not list any commits.  Otherwise, check out
  969 <em>master</em> and merge <em>maint</em> into it.</p></div>
  970 <div class="paragraph"><p>Now you can proceed with the creation of the feature release. Apply a
  971 tag to the tip of <em>master</em> indicating the release version:</p></div>
  972 <div class="exampleblock">
  973 <div class="title">Recipe: Release tagging</div>
  974 <div class="content">
  975 <div class="paragraph"><p><code>git tag -s -m "Git X.Y.Z" vX.Y.Z master</code></p></div>
  976 </div></div>
  977 <div class="paragraph"><p>You need to push the new tag to a public Git server (see
  978 "DISTRIBUTED WORKFLOWS" below). This makes the tag available to
  979 others tracking your project. The push could also trigger a
  980 post-update hook to perform release-related items such as building
  981 release tarballs and preformatted documentation pages.</p></div>
  982 <div class="paragraph"><p>Similarly, for a maintenance release, <em>maint</em> is tracking the commits
  983 to be released. Therefore, in the steps above simply tag and push
  984 <em>maint</em> rather than <em>master</em>.</p></div>
  985 </div>
  986 <div class="sect2">
  987 <h3 id="_maintenance_branch_management_after_a_feature_release">Maintenance branch management after a feature release</h3>
  988 <div class="paragraph"><p>After a feature release, you need to manage your maintenance branches.</p></div>
  989 <div class="paragraph"><p>First, if you wish to continue to release maintenance fixes for the
  990 feature release made before the recent one, then you must create
  991 another branch to track commits for that previous release.</p></div>
  992 <div class="paragraph"><p>To do this, the current maintenance branch is copied to another branch
  993 named with the previous release version number (e.g. maint-X.Y.(Z-1)
  994 where X.Y.Z is the current release).</p></div>
  995 <div class="exampleblock">
  996 <div class="title">Recipe: Copy maint</div>
  997 <div class="content">
  998 <div class="paragraph"><p><code>git branch maint-X.Y.(Z-1) maint</code></p></div>
  999 </div></div>
 1000 <div class="paragraph"><p>The <em>maint</em> branch should now be fast-forwarded to the newly released
 1001 code so that maintenance fixes can be tracked for the current release:</p></div>
 1002 <div class="exampleblock">
 1003 <div class="title">Recipe: Update maint to new release</div>
 1004 <div class="content">
 1005 <div class="ulist"><ul>
 1006 <li>
 1007 <p>
 1008 <code>git checkout maint</code>
 1009 </p>
 1010 </li>
 1011 <li>
 1012 <p>
 1013 <code>git merge --ff-only master</code>
 1014 </p>
 1015 </li>
 1016 </ul></div>
 1017 </div></div>
 1018 <div class="paragraph"><p>If the merge fails because it is not a fast-forward, then it is
 1019 possible some fixes on <em>maint</em> were missed in the feature release.
 1020 This will not happen if the content of the branches was verified as
 1021 described in the previous section.</p></div>
 1022 </div>
 1023 <div class="sect2">
 1024 <h3 id="_branch_management_for_next_and_pu_after_a_feature_release">Branch management for next and pu after a feature release</h3>
 1025 <div class="paragraph"><p>After a feature release, the integration branch <em>next</em> may optionally be
 1026 rewound and rebuilt from the tip of <em>master</em> using the surviving
 1027 topics on <em>next</em>:</p></div>
 1028 <div class="exampleblock">
 1029 <div class="title">Recipe: Rewind and rebuild next</div>
 1030 <div class="content">
 1031 <div class="ulist"><ul>
 1032 <li>
 1033 <p>
 1034 <code>git checkout next</code>
 1035 </p>
 1036 </li>
 1037 <li>
 1038 <p>
 1039 <code>git reset --hard master</code>
 1040 </p>
 1041 </li>
 1042 <li>
 1043 <p>
 1044 <code>git merge ai/topic_in_next1</code>
 1045 </p>
 1046 </li>
 1047 <li>
 1048 <p>
 1049 <code>git merge ai/topic_in_next2</code>
 1050 </p>
 1051 </li>
 1052 <li>
 1053 <p>
 1054 &#8230;
 1055 </p>
 1056 </li>
 1057 </ul></div>
 1058 </div></div>
 1059 <div class="paragraph"><p>The advantage of doing this is that the history of <em>next</em> will be
 1060 clean. For example, some topics merged into <em>next</em> may have initially
 1061 looked promising, but were later found to be undesirable or premature.
 1062 In such a case, the topic is reverted out of <em>next</em> but the fact
 1063 remains in the history that it was once merged and reverted. By
 1064 recreating <em>next</em>, you give another incarnation of such topics a clean
 1065 slate to retry, and a feature release is a good point in history to do
 1066 so.</p></div>
 1067 <div class="paragraph"><p>If you do this, then you should make a public announcement indicating
 1068 that <em>next</em> was rewound and rebuilt.</p></div>
 1069 <div class="paragraph"><p>The same rewind and rebuild process may be followed for <em>pu</em>. A public
 1070 announcement is not necessary since <em>pu</em> is a throw-away branch, as
 1071 described above.</p></div>
 1072 </div>
 1073 </div>
 1074 </div>
 1075 <div class="sect1">
 1076 <h2 id="_distributed_workflows">DISTRIBUTED WORKFLOWS</h2>
 1077 <div class="sectionbody">
 1078 <div class="paragraph"><p>After the last section, you should know how to manage topics.  In
 1079 general, you will not be the only person working on the project, so
 1080 you will have to share your work.</p></div>
 1081 <div class="paragraph"><p>Roughly speaking, there are two important workflows: merge and patch.
 1082 The important difference is that the merge workflow can propagate full
 1083 history, including merges, while patches cannot.  Both workflows can
 1084 be used in parallel: in <code>git.git</code>, only subsystem maintainers use
 1085 the merge workflow, while everyone else sends patches.</p></div>
 1086 <div class="paragraph"><p>Note that the maintainer(s) may impose restrictions, such as
 1087 "Signed-off-by" requirements, that all commits/patches submitted for
 1088 inclusion must adhere to.  Consult your project&#8217;s documentation for
 1089 more information.</p></div>
 1090 <div class="sect2">
 1091 <h3 id="_merge_workflow">Merge workflow</h3>
 1092 <div class="paragraph"><p>The merge workflow works by copying branches between upstream and
 1093 downstream.  Upstream can merge contributions into the official
 1094 history; downstream base their work on the official history.</p></div>
 1095 <div class="paragraph"><p>There are three main tools that can be used for this:</p></div>
 1096 <div class="ulist"><ul>
 1097 <li>
 1098 <p>
 1099 <a href="git-push.html">git-push(1)</a> copies your branches to a remote repository,
 1100   usually to one that can be read by all involved parties;
 1101 </p>
 1102 </li>
 1103 <li>
 1104 <p>
 1105 <a href="git-fetch.html">git-fetch(1)</a> that copies remote branches to your repository;
 1106   and
 1107 </p>
 1108 </li>
 1109 <li>
 1110 <p>
 1111 <a href="git-pull.html">git-pull(1)</a> that does fetch and merge in one go.
 1112 </p>
 1113 </li>
 1114 </ul></div>
 1115 <div class="paragraph"><p>Note the last point.  Do <em>not</em> use <em>git pull</em> unless you actually want
 1116 to merge the remote branch.</p></div>
 1117 <div class="paragraph"><p>Getting changes out is easy:</p></div>
 1118 <div class="exampleblock">
 1119 <div class="title">Recipe: Push/pull: Publishing branches/topics</div>
 1120 <div class="content">
 1121 <div class="paragraph"><p><code>git push &lt;remote&gt; &lt;branch&gt;</code> and tell everyone where they can fetch
 1122 from.</p></div>
 1123 </div></div>
 1124 <div class="paragraph"><p>You will still have to tell people by other means, such as mail.  (Git
 1125 provides the <a href="git-request-pull.html">git-request-pull(1)</a> to send preformatted pull
 1126 requests to upstream maintainers to simplify this task.)</p></div>
 1127 <div class="paragraph"><p>If you just want to get the newest copies of the integration branches,
 1128 staying up to date is easy too:</p></div>
 1129 <div class="exampleblock">
 1130 <div class="title">Recipe: Push/pull: Staying up to date</div>
 1131 <div class="content">
 1132 <div class="paragraph"><p>Use <code>git fetch &lt;remote&gt;</code> or <code>git remote update</code> to stay up to date.</p></div>
 1133 </div></div>
 1134 <div class="paragraph"><p>Then simply fork your topic branches from the stable remotes as
 1135 explained earlier.</p></div>
 1136 <div class="paragraph"><p>If you are a maintainer and would like to merge other people&#8217;s topic
 1137 branches to the integration branches, they will typically send a
 1138 request to do so by mail.  Such a request looks like</p></div>
 1139 <div class="listingblock">
 1140 <div class="content">
 1141 <pre><code>Please pull from
 1142     &lt;url&gt; &lt;branch&gt;</code></pre>
 1143 </div></div>
 1144 <div class="paragraph"><p>In that case, <em>git pull</em> can do the fetch and merge in one go, as
 1145 follows.</p></div>
 1146 <div class="exampleblock">
 1147 <div class="title">Recipe: Push/pull: Merging remote topics</div>
 1148 <div class="content">
 1149 <div class="paragraph"><p><code>git pull &lt;url&gt; &lt;branch&gt;</code></p></div>
 1150 </div></div>
 1151 <div class="paragraph"><p>Occasionally, the maintainer may get merge conflicts when they try to
 1152 pull changes from downstream.  In this case, they can ask downstream to
 1153 do the merge and resolve the conflicts themselves (perhaps they will
 1154 know better how to resolve them).  It is one of the rare cases where
 1155 downstream <em>should</em> merge from upstream.</p></div>
 1156 </div>
 1157 <div class="sect2">
 1158 <h3 id="_patch_workflow">Patch workflow</h3>
 1159 <div class="paragraph"><p>If you are a contributor that sends changes upstream in the form of
 1160 emails, you should use topic branches as usual (see above).  Then use
 1161 <a href="git-format-patch.html">git-format-patch(1)</a> to generate the corresponding emails
 1162 (highly recommended over manually formatting them because it makes the
 1163 maintainer&#8217;s life easier).</p></div>
 1164 <div class="exampleblock">
 1165 <div class="title">Recipe: format-patch/am: Publishing branches/topics</div>
 1166 <div class="content">
 1167 <div class="ulist"><ul>
 1168 <li>
 1169 <p>
 1170 <code>git format-patch -M upstream..topic</code> to turn them into preformatted
 1171   patch files
 1172 </p>
 1173 </li>
 1174 <li>
 1175 <p>
 1176 <code>git send-email --to=&lt;recipient&gt; &lt;patches&gt;</code>
 1177 </p>
 1178 </li>
 1179 </ul></div>
 1180 </div></div>
 1181 <div class="paragraph"><p>See the <a href="git-format-patch.html">git-format-patch(1)</a> and <a href="git-send-email.html">git-send-email(1)</a>
 1182 manpages for further usage notes.</p></div>
 1183 <div class="paragraph"><p>If the maintainer tells you that your patch no longer applies to the
 1184 current upstream, you will have to rebase your topic (you cannot use a
 1185 merge because you cannot format-patch merges):</p></div>
 1186 <div class="exampleblock">
 1187 <div class="title">Recipe: format-patch/am: Keeping topics up to date</div>
 1188 <div class="content">
 1189 <div class="paragraph"><p><code>git pull --rebase &lt;url&gt; &lt;branch&gt;</code></p></div>
 1190 </div></div>
 1191 <div class="paragraph"><p>You can then fix the conflicts during the rebase.  Presumably you have
 1192 not published your topic other than by mail, so rebasing it is not a
 1193 problem.</p></div>
 1194 <div class="paragraph"><p>If you receive such a patch series (as maintainer, or perhaps as a
 1195 reader of the mailing list it was sent to), save the mails to files,
 1196 create a new topic branch and use <em>git am</em> to import the commits:</p></div>
 1197 <div class="exampleblock">
 1198 <div class="title">Recipe: format-patch/am: Importing patches</div>
 1199 <div class="content">
 1200 <div class="paragraph"><p><code>git am &lt; patch</code></p></div>
 1201 </div></div>
 1202 <div class="paragraph"><p>One feature worth pointing out is the three-way merge, which can help
 1203 if you get conflicts: <code>git am -3</code> will use index information contained
 1204 in patches to figure out the merge base.  See <a href="git-am.html">git-am(1)</a> for
 1205 other options.</p></div>
 1206 </div>
 1207 </div>
 1208 </div>
 1209 <div class="sect1">
 1210 <h2 id="_see_also">SEE ALSO</h2>
 1211 <div class="sectionbody">
 1212 <div class="paragraph"><p><a href="gittutorial.html">gittutorial(7)</a>,
 1213 <a href="git-push.html">git-push(1)</a>,
 1214 <a href="git-pull.html">git-pull(1)</a>,
 1215 <a href="git-merge.html">git-merge(1)</a>,
 1216 <a href="git-rebase.html">git-rebase(1)</a>,
 1217 <a href="git-format-patch.html">git-format-patch(1)</a>,
 1218 <a href="git-send-email.html">git-send-email(1)</a>,
 1219 <a href="git-am.html">git-am(1)</a></p></div>
 1220 </div>
 1221 </div>
 1222 <div class="sect1">
 1223 <h2 id="_git">GIT</h2>
 1224 <div class="sectionbody">
 1225 <div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
 1226 </div>
 1227 </div>
 1228 </div>
 1229 <div id="footnotes"><hr /></div>
 1230 <div id="footer">
 1231 <div id="footer-text">
 1232 Last updated
 1233  2018-12-10 16:43:18 JST
 1234 </div>
 1235 </div>
 1236 </body>
 1237 </html>