MultiGitRepository
From APIDesign
(→Remember non-Distributed Version Control Systems?) |
(→Gates for Correctness) |
||
| Line 11: | Line 11: | ||
==== Gates for Correctness ==== | ==== Gates for Correctness ==== | ||
| - | [[ | + | Typical [[GitHub]] workflow uses pull requests and some integration with [[Travis]] or other form of [[ContinuousIntegration]] which is usually well integrated with the review tool. As soon as one creates a [[PR]], the continuous builder runs the tests and marks the [[PR]] as valid or broken. This greatly contributes to the stability of the '''master''' branch - it is almost impossible to break it by merging in [[PR]]s. |
| + | |||
| + | On the other hand please note that before your [[PR]] gets merged it may contain as many ''broken'' (e.g. not fully correct) commits as you wish. It is quite common one makes changes to the system, pushes them on a branch of own repository fork, creates a [[PR]] just to find out that while the functionality is OK, there are other things that need to be polished (formatting and proper spacing being my ''favorite''). One then adds few more commits to polish the non-semantical problems of the code. | ||
| + | |||
| + | What [[I]]'d like to point out is: It is absolutely OK to have commits which are ''broken'' if they get fixed before merging into '''master''' branch. We are going to transplant this observation to the [[MultiGitRepository]] case. | ||
==== Single Integration Repository ==== | ==== Single Integration Repository ==== | ||
Revision as of 09:07, 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.
Gates for Correctness
Typical GitHub workflow uses pull requests and some integration with Travis or other form of ContinuousIntegration which is usually well integrated with the review tool. As soon as one creates a PR, the continuous builder runs the tests and marks the PR as valid or broken. This greatly contributes to the stability of the master branch - it is almost impossible to break it by merging in PRs.
On the other hand please note that before your PR gets merged it may contain as many broken (e.g. not fully correct) commits as you wish. It is quite common one makes changes to the system, pushes them on a branch of own repository fork, creates a PR just to find out that while the functionality is OK, there are other things that need to be polished (formatting and proper spacing being my favorite). One then adds few more commits to polish the non-semantical problems of the code.
What I'd like to point out is: It is absolutely OK to have commits which are broken if they get fixed before merging into master branch. We are going to transplant this observation to the MultiGitRepository case.
Follow
