Timeline for Why does everyone use Git in a centralized manner?
Current License: CC BY-SA 3.0
24 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 6, 2018 at 18:34 | comment | added | haelix | Downvoted. This answer is misleading in suggesting foremost that git, by design, offers an advantage when it comes to avoiding merge conflicts. | |
| S Apr 20, 2016 at 10:29 | history | notice removed | CommunityBot | ||
| S Apr 20, 2016 at 10:29 | history | unlocked | CommunityBot | ||
| S Apr 13, 2016 at 10:17 | history | notice added | yannis | Comments only | |
| S Apr 13, 2016 at 10:17 | history | locked | yannis | ||
| Apr 13, 2016 at 10:16 | comment | added | yannis | Since several people ignored my comment about taking the conversation to chat, I'm afraid I'll have to lock the answer. | |
| S Apr 12, 2016 at 14:35 | history | mod moved comments to chat | |||
| S Apr 12, 2016 at 14:35 | comment | added | yannis | Comments are not for extended discussion; this conversation has been moved to chat. | |
| Apr 10, 2016 at 18:14 | comment | added | Lightness Races in Orbit | Ben's right. An SVN repo managed properly, and used by a team that has been properly educated in how to develop software, should effectively never have merge conflicts on trunk. You'll only get them when someone's done something wrong and needs to be fired (:P). inb4 it's easier when you don't have to educate people how to use their tools. Yeah, well, there's a lot more to teach about Git than there is about SVN! | |
| Apr 10, 2016 at 17:27 | comment | added | Ben Voigt | @Luaan: Sounds like you aren't applying the feature branch strategy correctly. The merging process is supposed to go as follows: (1) Commit all local work into the feature branch. (2) Merge all trunk commits between the last sync point and trunk HEAD into the feature branch (this does not block trunk) (3) commit to feature branch (4) if trunk has advanced during 2, repeat 2-3 (5) conflict-free merge from feature branch into trunk. Using this pattern, your local changes are never blocked from being merged, and conflicts occur only to the developer who owns one of the involved branches. | |
| Apr 10, 2016 at 16:35 | vote | accept | gardenhead | ||
| Apr 10, 2016 at 16:35 | comment | added | gardenhead | I'm going to accept this answer because it does the best job of answering my original question, although every answer gave good advice and perspective on the topic. I think the fact that everyone has their own complete and independent repo, even if that repo is not the source of truth, makes the best argument for why decentralized version control is much easier to work with. | |
| S Apr 10, 2016 at 13:19 | history | suggested | bignose | CC BY-SA 3.0 | re-phrase a confusing double negative |
| Apr 10, 2016 at 13:11 | comment | added | anaximander | @aroth It's also noticeable when you take a company laptop with you on a business trip, or to work from home. With a centralised VCS, you'd have to set up a VPN just to get at the source. With Git, you just keep working as normal, and push when you get back to the office. | |
| Apr 10, 2016 at 11:49 | comment | added | sleske | @BenVoigt: Yes, they can, but not into the branch you're merging into. When you develop on trunk, and merge a feature branch into trunk, the problem Michael describes can occur. | |
| Apr 10, 2016 at 11:44 | comment | added | aroth | I tend to agree with @BenVoigt that the main difference, in practice, is that git and similar tools are much better at dealing with intermittent or nonexistent network connectivity. With tools that rely on a central repo, losing access to that repo is at best a moderate setback and at worst a complete blocker. Git sidesteps that issue (almost) entirely. Although I think the point about merge conflicts is overstated. If those happen frequently, the problem is in your task allocation. You don't want two people changing the same file at the same time, regardless of what VCS tool you use. | |
| Apr 10, 2016 at 5:34 | review | Suggested edits | |||
| S Apr 10, 2016 at 13:19 | |||||
| Apr 10, 2016 at 1:49 | comment | added | Ben Voigt | No, people can definitely keep committing into the branch you're merging changes from, without interrupting your workflow. | |
| Apr 10, 2016 at 1:47 | comment | added | Michael Hampton | @BenVoigt Oh, it's work stopping all right. Remember you have to svn up be up to date with the repo before you can check in. When others continue checking in while you're trying to resolve merge conflicts, and give you another set of merge conflicts... you either put a stop to that or you lose what's left of your sanity. | |
| Apr 10, 2016 at 1:42 | comment | added | Ben Voigt | Well, that still doesn't affect everyone, because conflict resolution is done in the working copy of the one person responsible for the merge. That's true of both SVN and GIT. | |
| Apr 10, 2016 at 1:40 | comment | added | Michael Hampton | @BenVoigt I'm pretty sure I didn't make myself clear enough. I'm referring to merging branches, which svn seems to have a lot of trouble with. | |
| Apr 10, 2016 at 1:37 | comment | added | Ben Voigt | I find the main difference, when a central server exists, to be that GIT allows ongoing local versioning while the network is down, and SVN doesn't (some other version control systems are even worse, and stop all work when the network is unreachable, because they don't let you change a file until you check it out). | |
| Apr 10, 2016 at 1:36 | comment | added | Ben Voigt | SVN merges also only affect the developers involved with conflicting changes. One commit makes it into the repo, no conflicting merge can go into the repo until the conflicts are resolved (you can also commit in parallel to a separate branch/path, but that doesn't actually conflict now does it?) | |
| Apr 9, 2016 at 23:24 | history | answered | Michael Hampton | CC BY-SA 3.0 |