StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<blockquote> <p>Yes, I know, Linus never intended it for that.</p> </blockquote> <p>Actually, Linus argues that centralized systems just can't work. </p> <p>And, what's wrong with the <a href="http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows#Dictator-and-Lieutenants-Workflow" rel="nofollow noreferrer">dictator-and-lieutenants workflow?</a></p> <p><img src="https://git-scm.com/figures/18333fig0503-tn.png" alt="diagram"></p> <p>Remember, git is a <em>distributed</em> system; don't try to use it like a central one.</p> <h3>(updated)</h3> <p>Most of your problems will go away if you don't try to use git as if it was "svn on steroids" (because it's not).</p> <p>Instead of using a bare repository as a central server where everyone can push to (and potentially screw up), setup a few integration managers that handle merges, so that only they can push to the bare repository. </p> <p>Usually these people should be the team leads: each leader integrates his own team's work and pushes it to the blessed repository.</p> <p>Even better, someone else (i.e. dictator) pulls from the team leaders and integrates their changes into the blessed repository.</p> <blockquote> <p>There's nothing wrong with that workflow, but we're an overworked startup and need our tools to substitute for human time and attention; nobody has bandwidth to even do code reviews, let alone be benevolent dictator. </p> </blockquote> <p>If the integrators don't have time to review code, that's fine, but you still need to have people that integrate the merges from everybody.</p> <p>Doing git pulls doesn't take all that much time. </p> <pre><code>git pull A git pull B git pull C </code></pre> <p>git <em>does</em> substitute for human time and attention; that's why it was written in the first place.</p> <blockquote> <ul> <li>The GUI tools aren't mature</li> </ul> </blockquote> <p>The gui tools can handle the basic stuff pretty well. </p> <p>Advanced operations require a coder/nerdy mindset (e.g. I'm comfortable working from the command line). It takes a bit of time to grasp the concepts, but it's not that hard.</p> <blockquote> <ul> <li>Using the command line tools, it's far to easy to screw up a merge and obliterate someone else's changes</li> </ul> </blockquote> <p>This won't be a problem unless you have many incompetent developers with full write access to the "central repository". </p> <p>But, if you set up your workflow so that only a few people (integrators) write to the "blessed" repository, that won't be a problem.</p> <p>Git doesn't make it easy to screw up merges.</p> <p>When there are merge conflicts, git will clearly mark the conflicting lines so you know which changes are yours and which are not.</p> <p>It's also easy to obliterate other people's code with svn or any other (non-dsitributed) tool. In fact, it's way easier with these other tools because you tend to "sit on changes" for a long time and at some point the merges can get horribly difficult.</p> <p>And because these tools don't know how to merge, you end up always having to merge things manually. For example, as soon as someone makes a commit to a file you're editing locally, it will be marked as a conflict that needs to be manually resolved; now <em>that</em> is a maintenance nightmare.</p> <p>With git, most of the time there won't be any merge conflicts because git can actually merge. In the case where a conflict does occur, git will clearly mark the lines for you so you know <em>exactly</em> which changes are yours and which changes are from other people.</p> <p>If someone obliterates other people's changes while resolving a merge conflict, it won't be by mistake: it will either be because it was necessary for the conflict resolution, or because they don't know what they're doing.</p> <blockquote> <ul> <li><p>It doesn't offer per-user repository permissions beyond global read-only or read-write privileges</p></li> <li><p>If you have a permission to ANY part of a repository, you can do that same thing to EVERY part of the repository, so you can't do something like make a small-group tracking branch on the central server that other people can't mess with.</p></li> <li>Workflows other than "anything goes" or "benevolent dictator" are hard to encourage, let alone enforce</li> </ul> </blockquote> <p>These problems will go away when you stop trying to use git as if it was a centralized system.</p> <blockquote> <ul> <li>It's not clear whether it's better to use a single big repository (which lets everybody mess with everything) or lots of per-component repositories (which make for headaches trying to synchronize versions).</li> </ul> </blockquote> <p>Judgment call.</p> <p>What kind of projects do you have? </p> <p>For example: does version x.y of project A depend on exactly version w.z of project B such that <em>every time</em> you check x.y of project A you also have to checkout w.z of project B, otherwise it won't build? If so I'd put both project A and project B in the same repository, since they're obviously two parts of a single project.</p> <p>The best practice here is to <a href="https://stackoverflow.com/questions/406760/whats-your-most-controversial-programming-opinion/406775#406775">use your brain</a></p> <blockquote> <ul> <li>With multiple repositories, it's also not clear how to replicate all the sources someone else has by pulling from the central repository, or to do something like get everything as of 4:30 yesterday afternoon.</li> </ul> </blockquote> <p>I'm not sure what you mean.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload