TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Abandon Your DVCS and Return to Sanity (2015)

96 点作者 lemming将近 9 年前

22 条评论

rossy将近 9 年前
My number one favourite thing about Git is that is that I have a full copy of the repository history and I can work on it without talking to a central server, or any server. I can do a `git blame` or a `git bisect` without receiving a byte from the network, which is great because my internet connection is horrible. I can work on a train. I can work on an experimental feature in a branch with full history, decide it was a bad idea, delete the branch, and no one has to know about my failure. I can even share that branch between multiple machines in my house without setting up any server infrastructure. I can write shitty commit messages like &#x27;fix the thing for real this time&#x27; and clean them up later with a rebase before I push. I can make a series of commits, convert them to a series of patches and apply them during a build script with `git am`. I can version any folder on my machine just by typing `git init`, which is especially useful for folders of config files.<p>Also, I think Git&#x27;s model of working locally encourages people to think of their commits like their code. Good Git projects have small commits, a clean history and commit messages that are like documentation (which is especially useful, because you can use blame to locally find the change relating to a line.)
评论 #11816365 未加载
评论 #11813254 未加载
评论 #11813738 未加载
ajdlinux将近 9 年前
As a developer on the Linux kernel - the project for which Git was initially designed - I recommend people take a good look at the kernel workflow to appreciate where Git came from, and it&#x27;s a good example of a project where the D in DVCS is so very, very critical.<p>We have a massive codebase (about 20 million LOC), massive repositories (my local copy is 2.8GB), we&#x27;re massively distributed (my local repository currently has 17 remotes and 40 local branches)... and we still use mailing list patches and pull requests, we don&#x27;t use submodules, and we don&#x27;t rely on GitHub as anything more than a plain git server. And things <i>mostly</i> work...<p>It&#x27;s an interesting contrast to the way the average project on GitHub works (of course, the &quot;average GitHub project&quot; is now the primary use case for git...)
评论 #11813140 未加载
qznc将近 9 年前
Is the size of the history&#x2F;repo still an issue? Shallow clones seem to be powerful enough with newer git versions.<p>You can push from a shallow clone since v1.9.0 <a href="http:&#x2F;&#x2F;stackoverflow.com&#x2F;q&#x2F;6900103&#x2F;2361979" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;q&#x2F;6900103&#x2F;2361979</a><p>You can fetch more history on demand <a href="http:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;11834692&#x2F;2361979" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;11834692&#x2F;2361979</a><p>You can fetch the full history on demand since v1.8.3 <a href="http:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;36123631&#x2F;2361979" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;36123631&#x2F;2361979</a><p>You can push&#x2F;pull between shallow clones. This of course fails, if you the repos have no common ancestors.
vikascoder将近 9 年前
Just for the learning part, I moved from CVS to Perforce 10 years ago in a new job and it took me perhaps all of 4 hours to completely understand the work flow and the GUI. Until now when I started to see what Git is all about and after a couple of days and lots of different clients and articles, I am still not sure about my Git skills. It&#x27;s certainly isn&#x27;t as straightforward to learn and use.
评论 #11812308 未加载
评论 #11813655 未加载
评论 #11812408 未加载
lmm将近 9 年前
Blobs <i>are</i> different. You can tell that because even SVN has a flag that marks a file as a blob or not, and treats it differently in history and when merging if it is. We all know that when you have a function that takes a flag to do one of two different things, it&#x27;s probably better to make it two different functions.<p>Missing functionality can be a good thing when that functionality lets you do something stupid. Yes, SVN + discipline about the size of your repos can be as good as git (on that particular aspect). But discipline isn&#x27;t free.<p>DVCS true believers don&#x27;t believe in submodules &#x2F; subrepositories &#x2F; etc. Those things are sops to the big-repository diehards. I&#x27;ve worked on small repositories and I&#x27;ve worked on one of those organization-wide repositories the author talks about; the big repositories aren&#x27;t like that for good reasons, they&#x27;re like that because of dysfunctional organizational politics. Sure, Facebook uses one, but Facebook also uses PHP.<p>You always needed to base your patch on the correct thing when contributing. You don&#x27;t need to make a new local branch - it&#x27;s <i>useful</i> to do so, but not required. Sending a patch email takes longer than pushing a commit to github and making a PR, it just doesn&#x27;t sound like it because the author hasn&#x27;t written &quot;3. Open an email client 4. Click &quot;attach&quot; 5. Browse to the directory where you stored your patch ...&quot;. And you do gain a lot in terms of ability to rebase, which is vital when patches go ignored for as long as they do. A pull request from two years ago is often salvageable; a patchbomb simply isn&#x27;t.
评论 #11812850 未加载
评论 #11813732 未加载
prodigal_erik将近 9 年前
&gt;Facebook and Google know that keeping all your source code in one single repository is good<p>I&#x27;m not sure about Facebook, but Google continually wastes engineers on policing test failures because anyone at any time could have committed a change that breaks your tests for hours (along with all their other dependencies). The cadence of integration should match that of deployment; I don&#x27;t want to test against code that won&#x27;t be in production and I certainly don&#x27;t want to be slowed down over shitty code that <i>obviously can&#x27;t</i> go out.
评论 #11812481 未加载
adrianmsmith将近 9 年前
There&#x27;s one further point the article missed, which is: locking of binary assets.<p>For any file which cannot be merged, you need to have a &quot;lock&#x2F;checkout, edit, commit&quot; workflow.<p>There&#x27;s no point allowing two people to have a PNG file in their checkout, edit it, and commit it, only for one to get the message &quot;sorry, someone else edited it, your edits are now based on an out-of-date version, deal with it&quot;. You need to enforce the &quot;lock, edit, commit&quot; workflow on all files which cannot be merged.<p>Essentially, binary files cannot be merged, and therefore all binary files require this workflow. I&#x27;m sure there are some exceptions, I think Microsoft offers a merge tool for Word files. But I&#x27;ve never seen it hooked up to a VCS. But I suppose in principle it, or a similar merge algorithm for a particular file format, could be. But even then, there&#x27;ll still be all the other binary files, for which no such merge algorithm is configured.<p>All project have some binary files e.g. PNGs. So all projects are affected by this, and require this workflow on those files.<p>Yet a DVCS cannot offer it as there is no central place to maintain the lock.<p>Subversion offers this workflow however it isn&#x27;t enabled by default.<p>A VCS needs to offer this functionality as every project needs it, and it should be enabled by default for all files the VCS doesn&#x27;t know how to merge.
评论 #11813243 未加载
评论 #11812916 未加载
mcguire将近 9 年前
Hahahaha! This is hilarious!<p>Wait, what? He&#x27;s serious? Naw, can&#x27;t be.<p>&quot;<i>You needn’t look further than how many books and websites exist on Git to realize that you are looking at something deeply mucked up. Back in ye days O Subversionne, we just had the Red Book, and it was good, and the people were happy.11 Sure, there were other tutorials that covered some esoteric things that you never needed to do,12 but those were few and far between. The story with CVS was largely the same.</i>&quot;<p>Things like branching and merging. Which you never needed to do because you couldn&#x27;t, unless you have a giant, throbbing Thalosian head. (It&#x27;s not like I was the branch-n-merge guy at the last two jobs...)<p>Let&#x27;s see if I can follow the logic: Git is popular. Therefore, lots of books. Therefore difficult to use. Therefore bad.<p>Then there&#x27;s the part about centralized systems being ok because bandwidth is cheap and easily available, but distributed systems are bad because they use too much space.<p>One leg is now noticeably longer; please pull on the other for a while, dude.<p>Speaking of schlepping patches around, I don&#x27;t suppose the author has ever been told, &quot;Your stuff is good; can you update it for the current head?&quot; and been unable to find a version where the patch applies cleanly? Fun, fun, funfunfun.
mrighele将近 9 年前
The author complains about DVCS in general but in fact it highlights what are mostly issues with the git+github combination.<p>For example, if git blame is slow as hell, I&#x27;m not sure that it would be much different if it was running on a central server<p>The fact that Git has an atrocious UI isn&#x27;t related to it being a DVCS either. For example I find that Mercurial has a nice UI that makes it much easier to use and less error prone than both Git and Subversion.<p>The issues with Github again are not related to being a DVCS. In fact in that case Git is being used more like a centralized repo (push to one central repo, make a pull request from one repo on the server to another). What I miss in fact is an easy way to make a push or pull request directly to someone else. It would be nice to be able to do that from the command line through an IM handle for example.
评论 #11813286 未加载
jasonkester将近 9 年前
I think I&#x27;m one of the few developers who use the &quot;Distributed&quot; bit of DVCS. I do in fact often find myself on a slow boat down the Amazon with laptop in tow for weeks on end, so being able to make disconnected, versioned changes and have them sync back to the mothership when I do get a whiff of wifi is a big step forward.<p>It&#x27;s the branching and merging bit that I could do without.<p>Say what you will about Subversion, but using it is like having a big red &quot;Save&quot; button on you codebase. Click commit and off your changes go to the repository and you can once again safely have your laptop stolen without losing work. I have a few projects still on SVN and it&#x27;s really a breath of fresh air going back to them after a few months of feature branches, pull requests, and merges.
simula67将近 9 年前
&gt; With a DVCS, though, we have a problem. You do have the whole history at any given point, which in turn means you need to have every version of every blob. But because blobs are usually compressed already, they usually don’t compress or diff well at all, and because they tend to be large, this means that your repository can bloat to really huge sizes really fast.<p>You can shallow clone a repository in git. This looks more like &#x27;What should be the default mode for a source control : Centralized or Decentralized ?&#x27;. I think it should be decentralized since it requires more discipline.<p>&gt; Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. It’s so simple that Atlassian and GitHub both felt a need to write their own online tutorials to try to clarify the main Git tutorial on the actual Git website. It’s so transparent that developers routinely tell me that the easiest way to learn Git is to start with its file formats and work up to the commands.<p>This could simply mean that it is am amazing piece of technology that everyone loves to talk about it. It could also mean that it is a bit more complex, but that doesn&#x27;t mean that the complexity is not worth the benefits.<p>&gt; There is one last major argument that I hear all the time about why DVCSes are superior, which is that they somehow enable more democratic code development<p>I think the point that was made was that the issue of commit access goes away : <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=4XpnKHJAok8&amp;t=1139" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=4XpnKHJAok8&amp;t=1139</a> ( actually that whole talk is pretty interesting ).<p>To be perfectly honest, most companies would do fine with subversion and a very good web based user interface. The simplicity and the advantage of not having to teach people set in their ways may work in its favor.
mschuster91将近 9 年前
ad &quot;git is slow&quot;: when comparing SVN diff vs git diff on a SSD MacBookPro git diff is in most cases waaaaay faster than svn diff.<p>Also, the author ignores the biggest advantage of git&#x2F;hg over any centralized system: you can commit stuff without needing to be online! Commits are basically free until you eventually do git push.
评论 #11812491 未加载
chetanahuja将近 9 年前
The fact that git man page generator is so damn good should be a clue or something<p><a href="https:&#x2F;&#x2F;git-man-page-generator.lokaltog.net&#x2F;" rel="nofollow">https:&#x2F;&#x2F;git-man-page-generator.lokaltog.net&#x2F;</a>
lemming将近 9 年前
While I love being able to fix my commits up locally before pushing, it&#x27;s insane that I have to understand how git is actually implemented to use it effectively. Literally no other tool I have ever used has this characteristic. Imagine having to understand the Microsoft word file format in order to edit your documents!
评论 #11812857 未加载
oelmekki将近 9 年前
Oh, I know the feeling :) You explore new techs, everybody tells you you&#x27;re insane trying to do things that complicated, then a few years later they all do it and tell you you&#x27;re a bad programmer if you want to explore any other idea and don&#x27;t think of the current way as absolute. The ruby community is hit hard by this problem currently.<p>That being said, there&#x27;s something I love in DVCS in the way it allows me to work. I&#x27;ll usually make my own things locally, do tons of branches and commits, to have &quot;documented&quot; checkpoints I can quickly throw in and revert to, then squash them into a single entity for publishing that keeps the project history easy to read. I&#x27;ll probably won&#x27;t do that if it meant publishing this info to everybody.<p>But I won&#x27;t say you&#x27;re a bad developer if you don&#x27;t do that :D
bnolsen将近 9 年前
This is why I&#x27;m keen on &quot;fossil scm&quot;, especially for small projects. It uses similar syntax to cvs and subversion, but you have a full local copy of the entire repository. The local repository acts as a buffer between the centralized repository and the living on disk code. Also helps that fossil has very few dependencies and is a single self contained executable for everything. And it uses sqlite as its data store.
B1FF_PSUVM将近 9 年前
The thing with this DVCS debate is that for years people have been going (and going, and going) &quot;Oh, you simply _must_ use this marvelous new shiny swiss-army knife, it is _so_ much better than your beat-up boring old-ass screwdriver!&quot;<p>&quot;No it isn&#x27;t, not if my job is tightening screws ...&quot;<p>You give that talk to a tradesman, you get your block knocked off for your pains, but programmers apparently are more easily intimidated into being fashion victims.
svckr将近 9 年前
Snapshot from April 23:<p><a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20160423035750&#x2F;https:&#x2F;&#x2F;bitquabit.com&#x2F;post&#x2F;unorthodocs-abandon-your-dvcs-and-return-to-sanity&#x2F;" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20160423035750&#x2F;https:&#x2F;&#x2F;bitquabit...</a>
rcthompson将近 9 年前
The article claims that DVCS aren&#x27;t simpler to understand, but I think that&#x27;s very subjective. I really couldn&#x27;t wrap my head around cvs, svn, or hg until I learned git, which, ironically, I avoided until last because it was the &quot;hardest&quot;.
评论 #11812868 未加载
z3t4将近 9 年前
About the work-flow with forks. You could just give each dev it&#x27;s own branch, then restrict push for the other branches.<p>Bob: - &quot;Hey, check out my latest feature!&quot;<p>Alice: - &quot;update Bob&quot; - &quot;Cool! merge Bob&quot;
z3t4将近 9 年前
It&#x27;s kinda stupid that you can&#x27;t just download the latest and make commits on that. I wonder why
评论 #11812822 未加载
bedros将近 9 年前
you can simply use sub repository and don&#x27;t need to sync the whole top level, just the sub repo you&#x27;re working on.
评论 #11812294 未加载