MultiGitRepository
From APIDesign
(→Remember non-Distributed Version Control Systems?) |
(→Remember non-Distributed Version Control Systems?) |
||
| Line 7: | Line 7: | ||
These days we know where the truth is: there is a master repository somewhere and whatever is the tip there, is the truth. There can of course be multiple repositories, people are free to fork [[GitHub]] repositories like crazy, and some may even agree that one of the forks is more important. Yet, unless the fork overtakes the original repository, the truth will always remain in the master repository. | These days we know where the truth is: there is a master repository somewhere and whatever is the tip there, is the truth. There can of course be multiple repositories, people are free to fork [[GitHub]] repositories like crazy, and some may even agree that one of the forks is more important. Yet, unless the fork overtakes the original repository, the truth will always remain in the master repository. | ||
| - | The situation with multiple repositories isn't that different. | + | The situation with multiple repositories isn't that different. The history repeats on a new level. It is just necessary to explain to the poor single [[Mercurial]] and [[Git]] repository users that there is nothing to be afraid of. |
==== Gates for Correctness ==== | ==== Gates for Correctness ==== | ||
Revision as of 08:48, 13 April 2018
Using single Git repository is certainly more comfortable than working with multiple Git repositories. On the other hand, distributed development can hardly be performed in a single repository (unless you believe in a single Blockchain for the whole sourcecode on the planet). How to orchestrate multiple Git repositories to work together? That is the thousands dollar question various teams seek answer to! For example there was a talk at GeeCON 2017 in Prague about that by Robert Munteanu. Let's assume we have a project split into multiple Git repositories. What are the options?
Contents |
Remember non-Distributed Version Control Systems?
There used to be times when people were afraid of distributed version control systems like Mercurial or Git. All the users of CVS or Subversion couldn't understand how one can develop and commit in parallel without integrating into the tip of the development branch! If each developer or team of developers has its own tip, where is the truth?
These days we know where the truth is: there is a master repository somewhere and whatever is the tip there, is the truth. There can of course be multiple repositories, people are free to fork GitHub repositories like crazy, and some may even agree that one of the forks is more important. Yet, unless the fork overtakes the original repository, the truth will always remain in the master repository.
The situation with multiple repositories isn't that different. The history repeats on a new level. It is just necessary to explain to the poor single Mercurial and Git repository users that there is nothing to be afraid of.
Follow
