distributed.html

---
order: 3
section: "about"
subsection: "distributed"
subtitle: "Distributed"
display_class: "one-line"
aliases:
- /about/distributed/index.html
---
  <section class="about" id="distributed">

    <h2>Distributed</h2>

    <p>
    One of the nicest features of any Distributed SCM, Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository.
    </p>
    <h3>Multiple Backups</h3>
    <p>
    This means that even if you're using a centralized workflow, every user essentially has a full backup of the main server. Each of these copies could be pushed up to replace the main server in the event of a crash or corruption. In effect, there is no single point of failure with Git unless there is only a single copy of the repository.
    </p>
    <h3>Any Workflow</h3>
    <p>
    Because of Git's distributed nature and superb branching system, an almost endless number of workflows can be implemented with relative ease.
    </p>
    <h4>Subversion-Style Workflow</h4>
    <p>
    A centralized workflow is very common, especially from people transitioning from a centralized system. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
    </p>
    <p class="center">
    {{< graphviz alt="workflow A" >}}
    digraph dev_workflow {
      layout=neato;
      overlap=false;
      sep="+10";
      node [shape=box, style="filled,rounded", penwidth=0, fontname="Helvetica"];
      edge [penwidth=3, color="gray", arrowsize=0.5, dir=both];

      shared_repo [label="shared repository", fillcolor=teal, fontcolor=white, pos="2,1.5!"];

      developer1 [label="developer", fillcolor=lightblue, pos="0,0!"];
      developer2 [label="developer", fillcolor=lightblue, pos="2,0!"];
      developer3 [label="developer", fillcolor=lightblue, pos="4,0!"];

      developer1 -> shared_repo;
      developer2 -> shared_repo;
      developer3 -> shared_repo;
    }
    {{< /graphviz >}}
    </p>
    <h4>Integration Manager Workflow</h4>
    <p>
    Another common Git workflow involves an integration manager — a single person who commits to the 'blessed' repository. A number of developers then clone from that repository, push to their own independent repositories, and ask the integrator to pull in their changes. This is the type of development model often seen with open source or GitHub repositories.
    </p>
    <p class="center">
    {{< graphviz alt="workflow B" >}}
    digraph workflow {
      layout=neato;
      overlap=false;
      node [shape=box, style="filled,rounded", penwidth=0, fontname="Helvetica"];
      edge [penwidth=3, color="gray", arrowsize=0.5];

      // Nodes
      blessed_repo [label="blessed\nrepository", fillcolor=teal, fontcolor=white, margin="0.3", pos="0,3!"];
      integration_manager [label="integration\nmanager", fillcolor=orange, fontcolor=white, pos="0,1!"];

      dev_pub1 [label="developer\npublic", fillcolor="#CCAA00", fontcolor=black, pos="2,3!"];
      dev_pub2 [label="developer\npublic", fillcolor="#CCAA00", fontcolor=black, pos="4,3!"];

      dev_priv1 [label="developer\nprivate", fillcolor="#CCAA00", fontcolor=black, pos="2,1!"];
      dev_priv2 [label="developer\nprivate", fillcolor="#CCAA00", fontcolor=black, pos="4,1!"];

      // Edges with labels
      dev_priv1 -> dev_pub1;
      dev_priv2 -> dev_pub2;
      integration_manager -> blessed_repo;

      dev_pub1 -> integration_manager [color="lightgray"];
      dev_pub2 -> integration_manager [color="lightgray"];
      blessed_repo -> dev_priv1 [color="lightgray"];
      blessed_repo -> dev_priv2 [color="lightgray"];
    }
    {{< /graphviz >}}
    </p>
    <h4>Dictator and Lieutenants Workflow</h4>
    <p>
    For more massive projects, a development workflow like that of the Linux kernel is often effective.
    In this model, some people ('lieutenants') are in charge of a specific subsystem of the project and they merge in all changes related to that subsystem. Another integrator (the 'dictator') can pull changes from only his/her lieutenants and then push to the 'blessed' repository that everyone then clones from again.
    </p>
    <p class="center">
    {{< graphviz alt="workflow C" >}}
    digraph workflow {
      layout=neato;
      overlap=false;
      node [shape=box, style="filled,rounded", penwidth=0, fontname="Helvetica"];
      edge [penwidth=3, color="gray", arrowsize=0.5];

      // Nodes
      blessed_repo [label="blessed\nrepository", fillcolor=teal, fontcolor=white, margin="0.3", pos="6,4!"];
      dictator [label="dictator", fillcolor=red, fontcolor=white, pos="0,4!"];

      lieutenant1 [label="lieutenant", fillcolor="#CCAA00", fontcolor=white, pos="0,2.5!"];
      lieutenant2 [label="lieutenant", fillcolor="#CCAA00", fontcolor=white, pos="2,3!"];

      developer1 [label="developer", fillcolor=lightblue, fontcolor=black, pos="0,1!"];
      developer2 [label="developer", fillcolor=lightblue, fontcolor=black, pos="2,1!"];
      developer3 [label="developer", fillcolor=lightblue, fontcolor=black, pos="4,1!"];
      developer4 [label="developer", fillcolor=lightblue, fontcolor=black, pos="6,1!"];

      // Edges
      dictator -> blessed_repo;
      lieutenant1 -> dictator;
      lieutenant2 -> dictator;

      developer1 -> lieutenant1;
      developer2 -> lieutenant1;
      developer3 -> lieutenant2;
      developer4 -> lieutenant2;

      blessed_repo -> developer1;
      blessed_repo -> developer2;
      blessed_repo -> developer3;
      blessed_repo -> developer4;
    }
    {{< /graphviz >}}
    </p>
    <div class="bottom-nav" style="display: block;">
      <a href="{{< relurl "about/small-and-fast" >}}" class="previous" data-section-id="small-and-fast">← Small and Fast</a>
      <a href="{{< relurl "about/data-assurance" >}}" class="next" data-section-id="info-assurance">Data Assurance →</a>
    </div>
  </section>