What is Distributed Workflow in Git? Explained

The distributed aspect of Git's approach, one which inherits from its spiritual progenitor, the open-source content management system BitKeeper, is one of its most essential features. In BitKeeper and Git, after a change to a tree has been made, the entire tree is replaced with the new version. 

However, this replacement happens independently in each copy of the tree. This makes changes to a repository appear as though they happen instantaneously everywhere.

It is called distributed Git because every Git working directory contains a full-fledged repository containing a complete history of the tree. This also means that you actually do not need network access for development because your tree can essentially be the master tree.

The distributed nature of Git, in contrast to centralized version control systems (CVCSs), allows you to be significantly more flexible in how engineers collaborate on projects. In centralized systems, each developer is a node that collaborates with the central hub on a more or less equal basis. 

In Git, however, every developer has the ability to be both a node and a hub, meaning that they can both contribute code to other repositories and maintain a public repository on which others can base their work and contribute. 

There are no dedicated servers, and you can use Git in a disconnected state by having multiple copies of the repository on your computer. This is not to be confused with the centralized mode, in which all working copies have to be connected to the server at some point. The system works like this:

Every Git directory is a branch (or "working copy") of the full repository, containing an entire history of commits, branches, and tags. This means that you can work on your local machine without being connected to the network, and you can still push changes upstream (to the main repository) when you're ready.

After a while of using Git on your own, you might desire to contribute to someone else's project. Or perhaps you'd want to take inspiration from someone else's project. Forking is the term for this process.

Making a "fork" is the process of making a personal replica of someone else's work. Forks serve as a link between the original repository and your private copy. You can submit pull requests to contribute to the improvement of other people's projects by submitting your changes to the original project. At Git, forking is at the heart of social coding. 

This might sound strange at first because it’s not what most people would expect from a centralized version control system! But it turns out that distributed VCSes are extremely useful when many people want to work independently on the same project; they even let you work offline without disrupting anyone else’s work or requiring special permissions or coordination.

You'll very certainly need to know how to maintain a project in addition to knowing how to contribute well to one. Accepting and applying patches generated by format-patch and emailed to you, or merging changes in remote branches for repositories you've added as remotes to your project, are examples of this. 

Whether you manage a canonical repository or simply wish to assist by verifying or approving changes, you must know how to accept work in a way that is both transparent to other contributors and long-term sustainable for you.