|
|
|
|
|
|
by davnicwil
2491 days ago
|
|
|
On the github point, agree that I've never come across a non centralised workflow with git - what are the decentralised git workflows? The issues involved with everyone pulling from everyone, dealing with merge conflicts, etc in a distributed way with no agreed upon, central, source of truth seems fairly implausible for any reasonably sized team but I'd love to know if there are gitflow style workflows for this that make it easier than it first appears. |
|
|
Even in centralized workflows, the decentralized core of Git makes things better.
You've never had a central repository go down and then pulled from the person sitting next to you? At the last organization I worked with, this happened multiple times. And when Microsoft bought Github and a bunch of people panicked, a lot of them were able to move to Gitlab (even without deleting their Github repos) specifically because the technology behind Git allowed you to add multiple remotes.
The article makes the point:
> No system is simply decentralized, full-stop. We shouldn’t expect any to be.
Git is the same way. Even with Linux, where patches are sent around using Email and there is no central repository that has every in-progress effort, there's still ultimately one person signing off on the final release. But that doesn't mean that there aren't decentralized parts of Git that are very, very useful, specifically because they are decentralized or because they allow you to fall back to decentralized workflows when necessary.
One of the things this article is getting at is that people treat decentralized as a binary state -- you either have one source of truth that coordinates everything, or you have complete chaos. Most decentralized systems are in the middle; they allow centralization, but also support fallbacks for when that centralization fails.
Git's branch strategy is another good example of this. Most Git systems use a master branch. But the value of branching is that you can have diverging code states that aren't yet centralized into a single location. You can fork off of master and have a completely parallel codebase, if for some reason you need to. You can have your release in a decentralized state for a week, where multiple people are working on separate branches and there is no single branch that has everyone's changes, and then you can re-centralize everything to master or a staging once you feel comfortable with the features you want.