gitworkflows.html

   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 10.2.0" />
   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 overridden 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>seen</em> (patches seen by the maintainer) is an integration branch for
 836   things that are not quite ready for inclusion yet (see "Integration
 837   Branches" 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>seen</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>seen</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_seen_after_a_feature_release">Branch management for next and seen 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 switch -C next master</code>
1035 </p>
1036 </li>
1037 <li>
1038 <p>
1039 <code>git merge ai/topic_in_next1</code>
1040 </p>
1041 </li>
1042 <li>
1043 <p>
1044 <code>git merge ai/topic_in_next2</code>
1045 </p>
1046 </li>
1047 <li>
1048 <p>
1049 &#8230;
1050 </p>
1051 </li>
1052 </ul></div>
1053 </div></div>
1054 <div class="paragraph"><p>The advantage of doing this is that the history of <em>next</em> will be
1055 clean. For example, some topics merged into <em>next</em> may have initially
1056 looked promising, but were later found to be undesirable or premature.
1057 In such a case, the topic is reverted out of <em>next</em> but the fact
1058 remains in the history that it was once merged and reverted. By
1059 recreating <em>next</em>, you give another incarnation of such topics a clean
1060 slate to retry, and a feature release is a good point in history to do
1061 so.</p></div>
1062 <div class="paragraph"><p>If you do this, then you should make a public announcement indicating
1063 that <em>next</em> was rewound and rebuilt.</p></div>
1064 <div class="paragraph"><p>The same rewind and rebuild process may be followed for <em>seen</em>. A public
1065 announcement is not necessary since <em>seen</em> is a throw-away branch, as
1066 described above.</p></div>
1067 </div>
1068 </div>
1069 </div>
1070 <div class="sect1">
1071 <h2 id="_distributed_workflows">DISTRIBUTED WORKFLOWS</h2>
1072 <div class="sectionbody">
1073 <div class="paragraph"><p>After the last section, you should know how to manage topics.  In
1074 general, you will not be the only person working on the project, so
1075 you will have to share your work.</p></div>
1076 <div class="paragraph"><p>Roughly speaking, there are two important workflows: merge and patch.
1077 The important difference is that the merge workflow can propagate full
1078 history, including merges, while patches cannot.  Both workflows can
1079 be used in parallel: in <code>git.git</code>, only subsystem maintainers use
1080 the merge workflow, while everyone else sends patches.</p></div>
1081 <div class="paragraph"><p>Note that the maintainer(s) may impose restrictions, such as
1082 "Signed-off-by" requirements, that all commits/patches submitted for
1083 inclusion must adhere to.  Consult your project&#8217;s documentation for
1084 more information.</p></div>
1085 <div class="sect2">
1086 <h3 id="_merge_workflow">Merge workflow</h3>
1087 <div class="paragraph"><p>The merge workflow works by copying branches between upstream and
1088 downstream.  Upstream can merge contributions into the official
1089 history; downstream base their work on the official history.</p></div>
1090 <div class="paragraph"><p>There are three main tools that can be used for this:</p></div>
1091 <div class="ulist"><ul>
1092 <li>
1093 <p>
1094 <a href="git-push.html">git-push(1)</a> copies your branches to a remote repository,
1095   usually to one that can be read by all involved parties;
1096 </p>
1097 </li>
1098 <li>
1099 <p>
1100 <a href="git-fetch.html">git-fetch(1)</a> that copies remote branches to your repository;
1101   and
1102 </p>
1103 </li>
1104 <li>
1105 <p>
1106 <a href="git-pull.html">git-pull(1)</a> that does fetch and merge in one go.
1107 </p>
1108 </li>
1109 </ul></div>
1110 <div class="paragraph"><p>Note the last point.  Do <em>not</em> use <em>git pull</em> unless you actually want
1111 to merge the remote branch.</p></div>
1112 <div class="paragraph"><p>Getting changes out is easy:</p></div>
1113 <div class="exampleblock">
1114 <div class="title">Recipe: Push/pull: Publishing branches/topics</div>
1115 <div class="content">
1116 <div class="paragraph"><p><code>git push &lt;remote&gt; &lt;branch&gt;</code> and tell everyone where they can fetch
1117 from.</p></div>
1118 </div></div>
1119 <div class="paragraph"><p>You will still have to tell people by other means, such as mail.  (Git
1120 provides the <a href="git-request-pull.html">git-request-pull(1)</a> to send preformatted pull
1121 requests to upstream maintainers to simplify this task.)</p></div>
1122 <div class="paragraph"><p>If you just want to get the newest copies of the integration branches,
1123 staying up to date is easy too:</p></div>
1124 <div class="exampleblock">
1125 <div class="title">Recipe: Push/pull: Staying up to date</div>
1126 <div class="content">
1127 <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>
1128 </div></div>
1129 <div class="paragraph"><p>Then simply fork your topic branches from the stable remotes as
1130 explained earlier.</p></div>
1131 <div class="paragraph"><p>If you are a maintainer and would like to merge other people&#8217;s topic
1132 branches to the integration branches, they will typically send a
1133 request to do so by mail.  Such a request looks like</p></div>
1134 <div class="listingblock">
1135 <div class="content">
1136 <pre><code>Please pull from
1137     &lt;URL&gt; &lt;branch&gt;</code></pre>
1138 </div></div>
1139 <div class="paragraph"><p>In that case, <em>git pull</em> can do the fetch and merge in one go, as
1140 follows.</p></div>
1141 <div class="exampleblock">
1142 <div class="title">Recipe: Push/pull: Merging remote topics</div>
1143 <div class="content">
1144 <div class="paragraph"><p><code>git pull &lt;URL&gt; &lt;branch&gt;</code></p></div>
1145 </div></div>
1146 <div class="paragraph"><p>Occasionally, the maintainer may get merge conflicts when they try to
1147 pull changes from downstream.  In this case, they can ask downstream to
1148 do the merge and resolve the conflicts themselves (perhaps they will
1149 know better how to resolve them).  It is one of the rare cases where
1150 downstream <em>should</em> merge from upstream.</p></div>
1151 </div>
1152 <div class="sect2">
1153 <h3 id="_patch_workflow">Patch workflow</h3>
1154 <div class="paragraph"><p>If you are a contributor that sends changes upstream in the form of
1155 emails, you should use topic branches as usual (see above).  Then use
1156 <a href="git-format-patch.html">git-format-patch(1)</a> to generate the corresponding emails
1157 (highly recommended over manually formatting them because it makes the
1158 maintainer&#8217;s life easier).</p></div>
1159 <div class="exampleblock">
1160 <div class="title">Recipe: format-patch/am: Publishing branches/topics</div>
1161 <div class="content">
1162 <div class="ulist"><ul>
1163 <li>
1164 <p>
1165 <code>git format-patch -M upstream..topic</code> to turn them into preformatted
1166   patch files
1167 </p>
1168 </li>
1169 <li>
1170 <p>
1171 <code>git send-email --to=&lt;recipient&gt; &lt;patches&gt;</code>
1172 </p>
1173 </li>
1174 </ul></div>
1175 </div></div>
1176 <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>
1177 manpages for further usage notes.</p></div>
1178 <div class="paragraph"><p>If the maintainer tells you that your patch no longer applies to the
1179 current upstream, you will have to rebase your topic (you cannot use a
1180 merge because you cannot format-patch merges):</p></div>
1181 <div class="exampleblock">
1182 <div class="title">Recipe: format-patch/am: Keeping topics up to date</div>
1183 <div class="content">
1184 <div class="paragraph"><p><code>git pull --rebase &lt;URL&gt; &lt;branch&gt;</code></p></div>
1185 </div></div>
1186 <div class="paragraph"><p>You can then fix the conflicts during the rebase.  Presumably you have
1187 not published your topic other than by mail, so rebasing it is not a
1188 problem.</p></div>
1189 <div class="paragraph"><p>If you receive such a patch series (as maintainer, or perhaps as a
1190 reader of the mailing list it was sent to), save the mails to files,
1191 create a new topic branch and use <em>git am</em> to import the commits:</p></div>
1192 <div class="exampleblock">
1193 <div class="title">Recipe: format-patch/am: Importing patches</div>
1194 <div class="content">
1195 <div class="paragraph"><p><code>git am &lt; patch</code></p></div>
1196 </div></div>
1197 <div class="paragraph"><p>One feature worth pointing out is the three-way merge, which can help
1198 if you get conflicts: <code>git am -3</code> will use index information contained
1199 in patches to figure out the merge base.  See <a href="git-am.html">git-am(1)</a> for
1200 other options.</p></div>
1201 </div>
1202 </div>
1203 </div>
1204 <div class="sect1">
1205 <h2 id="_see_also">SEE ALSO</h2>
1206 <div class="sectionbody">
1207 <div class="paragraph"><p><a href="gittutorial.html">gittutorial(7)</a>,
1208 <a href="git-push.html">git-push(1)</a>,
1209 <a href="git-pull.html">git-pull(1)</a>,
1210 <a href="git-merge.html">git-merge(1)</a>,
1211 <a href="git-rebase.html">git-rebase(1)</a>,
1212 <a href="git-format-patch.html">git-format-patch(1)</a>,
1213 <a href="git-send-email.html">git-send-email(1)</a>,
1214 <a href="git-am.html">git-am(1)</a></p></div>
1215 </div>
1216 </div>
1217 <div class="sect1">
1218 <h2 id="_git">GIT</h2>
1219 <div class="sectionbody">
1220 <div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
1221 </div>
1222 </div>
1223 </div>
1224 <div id="footnotes"><hr /></div>
1225 <div id="footer">
1226 <div id="footer-text">
1227 Last updated
1228  2021-12-10 14:52:02 PST
1229 </div>
1230 </div>
1231 </body>
1232 </html>