分散式版本控制系统如何改善工作流程？

Question

I have really tried to understand how distributed version control systems alter the way we work. I watched a tech talk of Linus Torvalds on git , which is mostly about the power of distributed version control, and he claims that it alters the way in which we work.

Let's consider git. There are plenty of good reasons to love and use git, I am aware of these good reasons. I am also certain that the power of the decentralised model doesn't extend to just efficiency and the ability to make local commits. One of the important points is that it allows developers to synchronise their work. Assuming that the work has not been commited already, I would presume the code to be (potentially) unsuitable for deployment, possibly subject to change (bad if I am hard coupling my dependencies to it), which to me sounds like a world of pain waiting to unfold.

I have a feeling that the decentralised model works brilliantly in the setup that Linus faces, but this is typically uncommon of most setups or needs, and that a centralised setup is essentially what we all want and use within our unified networks (ie the majority of company setups, though I admit this is an assumption on my part). We all push stuff back to a central location so we can share it with others, and this need for centralisation forms the basis of github. We all rely on the integrity of the central location to provide secure access to our work and to back it up for us as well.

Don't regress into answering why git is lovely. It works brilliantly in a centralised model with the bonus of local commits, but I really feel like I have missed the point about decentralised workflows somewhere.... I may have to watch the video again

Update:

Thanks for engaging the question, I don't think I made my point particularly obvious. Basically the issue I face is as follows. Many companies are setup with a central workflow. We work on a unified fast local network. Managing the logistics of a centrally managed configuration are somewhat simpler; we all use the central repository, this is the honey pot we make sure to safeguard against disk failures and fires and anything else you might be paranoid about. Factoring this necessity into your workflow increases the chances that your work, regardless of state, ends up in this safe location. We rely on the network connectivity and availability of this central location for just about everything we share. I first thought that maybe that our love for the central workflow is just our inability to grasp how to use DVCS on the micro scale. Now to say just use git because it's a superset of the centralised variant is ok I guess. However given that I still, in the majority of cases, can't see anything that is intrinsic to the decentralised model, we might be using a more complicated tool to solve a simpler problem. There may be some value in a centralised tool that does what we are already doing.

Answer 1

Git improves workflow because merges are no longer painful things to do.

If you've ever worked with several developers on a single project using a SCM, you should know that merging is THE #1 issue you have to deal with. Assuming you watched the video, you already know that Linus went to some lengths to elaborate on that issue, and why that is the main issue with other SCMs.

I'm going to be restating the example Linus made in the video you said you watched, but here goes:

Say there are 3 developers, including yourself, working on a project that has 3 parts. You are all experts in respect to the parts you're working on. Assuming you've been designated the maintainer of the repository, the other two developers may ask you to merge code into the main branch. BUT! You're not an expert on what they worked on, and you don't necessarily need to understand how their code works... but you trust that the changes they've made are OK. With git, you can shift the responsibility (read: work) of merging to them. Once they've pulled your code, merged theirs into it, and committed it, they can ask you to pull the merged code.

Why is this good? Because they did all the work, and they understood what they were merging. Without git, this process would undoubtedly be very painful and time consuming.

Answer 2

DVCS allows you to do stuff without affecting other people's work until it is ready to.

So you can fix all your mistakes and integration incompatibilities locally, then send it out.

Answer 3

I'll try to answer on asked question

Sort version

Any DVCS does NOT improve workflow by itself. So on question "How?" fast&simple answer is "In no way!"

Longer version

DVCSes have possibilities (due to distributed nature), which can be used to change and evolution workflow and common style of work. But it's always not technical , but managerial, administrative and organizational solution and responsibility: what, how, when, to solve which business-tasks using DVCS is possible and justified.

Immediately at the start I can see one big business advantage of DVCS - it allow P2P communication between developers, decreasing this way wasted in CVCS mode time.

Where it can be useful and requested? Any time, when 2+ developers work on related, but isolated from "mainstream" task. Imagine

• some system with core and frontend and separated responsibility areas (coredev doesn't touch frontend, frontman can't do any with core)
• one repo for core and front, without external repos (all-in-one)
• small job in front require core changes
• front-file is in /views/default/main/lib.js, core-file /core/db/connectors/engine (but locations deep haven't real value in our example)

SVN-version, branch-per-operation mode

• Frontman works with WC, related to branch "branches/lib2-frontend" ( not sparse copy), when "shit happens"
• Coredev create branch "branches/lib2-fixes", successfully perform changes, commit
• Frontman monitor repo and wait final commits from Coredev
• Frontman have to get somehow updated files for his job and. Start mergevoodoo magic
• If all is OK, frontman have to eliminate some way commiting merged from coredev core-file in his commit

DVCS-version

Story is not dramatically shorter and differ in 1 place - when coredev have his finished job, branch delivered to frontman, merged locally. Later merged work can be branched-cleaned-stripped into ready to publish for public form (cherry-picking, history rewrite etc)

Answer 4

I really feel like I have missed the point about decentralised workflows

Wherever I've used Git, both personally(Github) and at $work, it's mainly a centralized model. However, the only advantage I see with the decentralized model is speed. I'm pretty sure it is way faster to commit a few times during the day locally and then trigger a push to the central repo at the end of the day. Compare that (speed) to making multiple commits to a remote repository everyday.

Answer 5

I'm confused, what is it you're trying to understand here? You essentially say "I know why git is great", then proceed to ask "why is git great?" This has the feeling of not really being a question, or at least a question that is rather ambiguous in what is being asked for.

If you're asking specifically how a DVCS improves workflow, then I'd say it does in that every user has their own copy of the repository, and as such can work completely independently, but still retain the ability to merge back with others working on the same repository.

Ex: say Joe is working on "project A", and I am also working on project A. Joe & I can go crazy, doing commits, refactoring, etc, etc, but at the end of the day still combine our code (this is essentially the model of Github -- you fork a project, do crazy stuff, but because your copy is a clone of the original, it's always possible to easily merge your changes back into the original).

But I feel that I've missed what it is you're asking.

You might perhaps also wish to take a look at Version Control By Example which is a free e-book that discusses some various pros and cons of different DVCS's (git just being one). Perhaps the answer you seek is in there.