Once merging is easy, branching doesn't look bad any more. It still looks bad to me. I want 1 codebase, developed linearly. Definitely I can see the appeal of branches for software you ship, where you need to bug fix an old version and release a patched ver etc, but I can't really see the need for web based software, which I think is pretty usually developed linearly without much mess. I much prefer doing branches in the source code If that makes sense.
For example say you have a widget and you want to try a different strategy, create a newWidget in the source, make it so you can swap it in and out of the runtime maybe for testing.
Keep developing it, until you're sure it's cool. When cool, replace widget with newWidget. If it doesn't work out, just delete it. Then, when you merge, the patches will show up all in a row at the point you commit, as if they were all done in a row. Essentially, this is exactly what happens when you are working with subversion for a couple of days and then do several commits at the end.
Except you can trivially have multiple of these things going at a time. I'm going to ask you a question: Have you actually tried git or anything for a significant period of time, like, at least a couple weeks? Not just "yeah, 5 minutes. And if so, you're not doing a great job of showing that you tried it. Yes I tried it for a day Not long I agree. It looked like a reasonably copy of svn, but it didn't offer me anything. Let me restate: I do not like branches and use them very rarely.
So, to the guy who hates branches, what does git offer me over svn Which does all I need at the moment? Yes, I do this with svn easily enough Local install of svn. Simple enough Maybe that's a good selling point for people who aren't connected to the net much though,.
Assuming you want local version control as you seemt o do, since you are locally installing svn you'd maintain a separate local repository, maintain the same project under both, and synch them both when you get back online? And if you had two laptops say apart from the remote server , you'd maintain 3 repositories? It's not really a use case I have. I use branches in Hecl to play around with experimental features. These are things that I want to keep around for a while, hack on, but that are not ready to be in Hecl proper.
This is something I don't fully understand. How does it make merging more easy? I tried mercurial some time ago and it gave me conflicts for very easy merges. While I like it very much as a local version control for myself this merging was really bad. Now its not unlikely that I made a mistake somehow. Before 1. In particular, it could not detect that you merged something already when merging a changeset. Also, the merge command effectively "squashed" everything - you could use svnmerge and co to get something a bit better, but the tools were very poor to say the least.
As for it not being a proposition on the human condition - I mistook what he was saying, but then after it was clarified I understand what was meant. It was unclear to me what was being said - interestingly enough, that is the entire argument being expressed for the reason why git is "hard work". I don't think anyone's said that, or tried to say it least of all me , at any point. You seemed to. You said "intelligence can be expected.
Hard work should be unnecessary". What did you actually mean? I apologise if I misunderstood what you were saying! I'm saying that while it may be valid to assume intelligence on the part of your users, that doesn't make it valid to make them work hard. I'm not saying that intelligence gets you out of hard work, I'm saying that it shouldn't necessarily get you into it - and from where I'm sitting, git requires both where it should only require one.
I'm following you finally. Yes, I agree that unnecessary hard work shouldn't be needed. How many how-tos are there on text editors, programming languages, build systems, deployment systems, unit testing frameworks, frameworks, APIs, libraries, debuggers? I spend at least an order of magnitude, if not several, more time with each of those things than I do with a goddamn version control utility.
I put in effort where it's worth it. Version control doesn't even come close to hitting the top of that list. You build and deploy ten times as often as you commit? Apparently you really don't think version control is worth it!
He said he spends ten times more time on building than on managing revision control. That doesn't mean 10x more deployment or development. On the other hand, I can tell you we have almost 10x more downloads than we have svn commits ;-. There is very little that is hard with managing your source code on your local workstation. To commit any changes, you type in: git commit -a -m "thing that I changed" To branch, it's: git checkout -b newbranch To switch back to the master branch, you just type in: git commit -a -m "changes made on branch" git checkout master To merge in that branch, should you so wish to do so, then you type in: git merge newbranch What is exactly so hard about that?
The thing that people need to get through their head is that distributed version control is a whole different concept. There are some things it is great at. There are some things it sucks at. Centralized version control is great at some other things, and lousy at some other things too. I am thinking for example that if you are going for a PA-DSS-certified application, git, particularly with the ability to rewrite history, is going to be a problem, but dvs generally will provide more problems in assuring the auditor that you can locate, trace, and take corrective action if someone introduces a security issue perhaps intentionally into your application.
I don't see git really working in that environment. On the other hand, if you have a lively project that everyone is experimenting with and you need to merge patches occasionally to create a stable release, yeah, it's much better. Aga on Aug 5, root parent next [—]. Why would dvcs cause problems for auditors?
For any given project, no matter how distributed the development, you will have a "blessed" repository, from which the official releases are made. The history of this "blessed" repository is made not rewritable, even if anyone can push new stuff to it. The config files and hooks can be made writable by only admins. Or you use a maintainer model, where the "blessed" repository is not even pushable. A maintainer or a group of them chooses what he merges in.
I have concerns about git and used distributed version control years before git existed. I use mercurial all the time even when I am forced to interact with git projects thanks hg-git! What I do have problem with is atrocious CLIs that require you to remember cryptic incantations to do the simplest things. Two anecdotes: - Colleague 1 has become sort of comfortable with git but only after heavily customizing gitconfig and setting up a dozen or so aliases for the most common commands.
So you have had good luck with hg-git, then? Does it play well with github? I've read mixed reviews I'm OK with git but am deeply displeased with how difficult the learning curve is for a casual user. I'd much rather that Mercurial won. Here's the thing though. I have been using SVN for years and am not learning Git. For a long time I figured I was just disoriented and eventually it would come.
Now I am less convinced. The article really described my experience pretty well to the point where I am thinking the only sane way to use git is along with subversion In essence, the more I learn, the less I like it, and the more convinced I am that it isn't what I need right now.
Building accounting software there are certain things I need in a revision control system. These are: 1 revision control as audit trail. I need to know who committed a change and I need an audit trail on that.
SVN isn't perfect here. I'd like to be able to audit changes to commit logs too, but that's pretty minor stuff. Folks have pushed git because it makes it easier for users to share modifications with eachother. That's fine, and it's a good point, but it isn't worth getting rid of a clear and reliable audit trail in order to achieve. To this end I suspect we are more likely to pursue a hybrid solution with all the complexity that provides and indeed it is already partly implemented than a pure git solution.
Allowing rewrite of commits is a problem not because developers might do it but rather because you can't show that developers didn't do it. If there is a question about whether a security issue was intentionally added to the code or not you need to have a clear audit trail. A basic principle of any audit trail is that your audit trails may not be overwritten. Git version numbers are actually SHA1 hashes that are based on all the files and the entire history of the project up to there.
If you modify the history in any way, then that will be a new version number and you know something has changed. Just require commits that are signed off with GPG keys.
Then you have a clean, verifiable audit trail through git. Beyond that, you'll have the full development history on your machine, which they can't just arbitrarily change.
Do you think that's more or less complex than just using svn-git to manage the authoritative audit-trail repository? Less, managing two version control systems seems like insanity speaking as one who's had to do it in the past. Having people sign their commits is dead simple in Git, and you could setup hooks to make sure every commit is signed before you accept it.
This actually is the usage scenario for which Fossil[1] was created in fact DRH made it to be in accordance to some aviation industry norms, don't remember details. Furthermore, one of the ideas behind Fossil's design was to minimize the learning curve for someone who already knows SVN.
Disclosure: I occasionally committed something to Fossil. Fossil looks promising. I have bookmarked it. Of course there was a typo in my previous post. I am "now" learning git, not "not" learning git.
I disagree with the very first thing you said. I don't think it's fair to say they've equivalent. Even as a fairly long-time user who is quite comfortable with git, it is sometimes overwhelming. With svn, I basically had to know what a revision was, and maybe a branch, and that's about it. To use git effectively, I have to know about commits and their graph-y nature , remotes, the concepts of pushing and pulling, rebasing vs merging, and if I'm reading the documentation, I am rapidly going to begin running into concepts like "refs".
Of course the rabbit hole keeps going deeper, but a lot of that stuff you won't really need to know. Personally I know what all these things are, and again I'm quite comfortable with them at this point, but there was absolutely a learning curve, and I'm reminded of it every time I start explaining something to a more novice coworker. Also, for the record I like git a lot. But it's not immune from criticism. I would further argue that 10 is wrong.
He compares commits to a project you own to contributing to a project you don't own. If you don't have commit access to a svn server you are for the most part out of luck. Emailing the patch to a mailinglist or some dude is about the best option and even then it has a good chance of either not making it in or taking a very long time.
So meanwhile you want to keep your changes going, how do you do that? A bunch of patches you apply every time you svn update? Run your own svn server, import their code and apply patches on that? What about merge hell time? Perhaps you do want commit access to the svn server.
Just first mail this form via the post office to me or maybe fax the form and then after that first contribute perfect patches and maybe then we will give you commit access. Nothing against learning new things, but why defend user interfaces or workflows that are needlessly complex or unintuitive? DCVS is certainly a significant advance over centralized VCS, but that doesn't mean Git couldn't be made significantly more accessible.
More readable documentation alone would have made learning git a great deal easier for me. SiVal on Aug 5, parent prev next [—]. The whole post is about a system that is badly designed or implemented, making it unnecessarily complicated to learn and use. Not wanting to have to deal with unnecessary complications is not the same as not wanting to deal with necessary complications.
People unfamiliar with good UX design can't tell the former from the latter. If you find yourself confused and frustrated like the author, here's how to make git make sense: 1. Temporarily forget everything you know about every other system, and imagine they didn't exist, and that you have to solve this problem yourself.
How might you do it? Read it very carefully - the minute you start skimming, you'll start filling in gaps using your Subversion knowledge and be lost again. If you really want to understand, read this aloud. Couldn't disagree more. Git throws too many unnecessary things at a beginner to learn. Sure you could read every damn book about git and learn it. But why should you in the first place? I don't know what it is with this attitude amongst so many nerds that "oh it's hard?
This is absurd. It is a tool to aid the development of software. If you can learn a goddamn language, you can spare 20 minutes to figure out the extra couple of steps git can add. I can tell you it took me a lot longer than 20 minutes to master working with git. Sure, you can tell someone how to clone, branch, commit and push in 20 minutes, but that's not really understanding.
For example, last month I was at a meetup, and had to help someone who was contributing to an open-source project. She had been following the project's instructions on using git, but was stuck. It turned out that she had hit a snag in the middle of a multi-commit patch that was applied with "git am" and as a result, her repository was in an intermediate state and the usual commit, add, reset etc.
I helped her back out to a clean state, but it took me several minutes of scouring documentation to do it, and I consider myself proficient with git. If I hadn't been there, I expect she would have given up on the whole thing, and all because git has some bizarre interactive processes that leave your repository unusable while in progress.
I think it's undeniable that git is unfriendly and obtuse at times, and the people who think otherwise are just examining it too close. They have mastered it, they see all of the justifications for each quirk, and because of that they can't see the big picture, which is that it is extraordinarily difficult for a new programmer to pick it up and be proficient. So what? A goddamn language is easy compared to git - they all mostly work in the same way. I don't understand this attitude.
Why can't our tools be so easy to use that you don't need to read the instruction manual? Conceptually, there's nothing that difficult about using git. I have some files that I want to be versioned. Yet, the commands are inconsistent and any non trivial operation requires consultation of a variety of tutorials. Why do we have to settle for this? Why can't the tool be internally consistent? Not in my experience. If you need safe Git history, you're supposed to sign your commits with GPG.
Git has built-in tools for that. Linux kernel and many other major projects use signed commits. In addition to keeping the repository safe from changes in the history, it will also protect you when your git server gets hacked where Subversion will fail. If I read one more blog post that brings this up, I will cry. If you push a revision that doesn't build, you'll have a harder time doing "git bisect" you can skip broken builds, though. It's a good idea to squash and rebase before commit to master.
Use git merge --no-ff if you want a merge commit in. Git is alright. You can learn it just like anything else. Yeah, it could have been simpler. It comes from Linus, who judging only from the talks I've seen online --don't know him personally, can be very opinionated and "asshole-ish" at times.
My pet peeve with Git is that it stopped once it supported Linux kernel-type projects. If you are working on anything other than that it is likely that you are going to run into all manner of non-text resource files and Git sucks at helping you maintain these. Case in point: Graphically intensive iOS apps. RivieraKid on Aug 5, parent prev next [—]. The point of the article was, that git's UX sucks.
People complaining is by definition bad UX. Experience, which people complain about, is not good. And that does confuse a lot! I believe in the power of user interfaces, and I believe tools should be as easy to use as possible, and I dislike the "I don't like to learn new things" argument because actually, yes, your tools should make you learn as little as necessary to use them.
This is the bread and butter of VCS: checking out a repository, committing changes, and getting updates. What I'm saying is, I think I'd rephrase Number are mostly "I don't want to learn new things" to Number are mostly "I'm going to blame my tool for me refusing to do the bare minimum to learn how to use it". Git can be made simpler. Ignore them at your own peril. Which is the case here. Have people done hallway usability testing on git? I think this would definitely turn up some tasks within it that are way harder than they need to be.
Do people really feel confident that learning git is a smooth process, not involving a lot of swearing? The answer you mostly hear when complaining about programming tools is that you need to toughen up - yet startups are founded on the idea of not doing this to their clients. Making processes super easy for clients is a good thing, and we should gather information, find the common problem spots, and fix them for our own tools!
We shouldn't just keep insisting that the customer programmers needs to toughen up and learn as the default answer, anyway; some things really are hard Why isn't there user feedback tool for man pages, where it asks "Was this information helpful to you? I bet the success rate would be pretty low. In general why isn't there any information about which man pages are good and which are terrible?
They just seem frozen in time. Compared to the analytics startups get about their customers, info about man pages is nonexistent. DeepDuh on Aug 5, parent next [—]. I think you bring up some good points of open source projects vs. In open source projects, most of the time when seeing critical feedback by users you see those "it's open source, just change it the way you want" comments.
No one makes money, therefore no one depends on users being happy about the software. Maybe we should invent a new model that combines open source with paid incentives for user desired changes. Let's say User A uses Gimp, sees something that could be simplified or added. He can't program it himself but what he can do is describing the feature he wants, possibly with screenshots or even an interface prototype.
He then auctions this on a marketplace website. Other users can upvote or even chip in to A's auction such that the probability of a good developer implementing it rises. Developers have their profile with reputation, possibly linked with their stackoverflow reputation. The change gets implemented within a branch of gimp, installable by anyone using a modified package manager. If the maintainers of gimp like the change, they can merge it in such that everyone profits - the number of user downloads being a good indicator that the change is desired.
I agree with you. Unfortunately one thing I keep seeing in the developer community that frustrates me is this competition-like demand for learning new things. Sure I love learning new things. But I don't like learning new things just for the sake of learning things. You look around forums and websites, every time someone's asking for help and is confused about something, the average response roughly says "you are a lazy ass and you should feel bad about yourself because you didn't read the 60 pages of manual someone else wrote, oh you are also not smart enough, go learn new things, look at all these command line arguments that I have memorised There's two basic types of commercial software yes over-simplification turn-key or custom.
I work for a shop that does the latter. If I brought software to our clients with the explanation: "toughen up, read the manuals, we adhered to your spec!
If some part of Office was a usability nightmare most people would simply avoid it. That is a trite example but the analogy isn't that far off base. I will caveat everything by saying I have drank the Hg kool-aid and will be drunk for some considerable time. It wasn't that it was SVN-like, but as I explore more complex features on my own, my hand isn't slapped in the process.
I've hosed repositories in Hg and SVN. I've fixed Hg repositories from codeplex that seem eternally broken given that is the "authoritative master". It didn't take any research at the time but I couldn't recall if the knowledge was entirely latent i.
I'm of the notion that if you can jump to any DVCS for the most part you're doing an excellent job. It doesn't hurt that there's hgsubversion or hg-git to make transitions easy but even the more obscure DVCS' are a leg up.
I don't bash Git on some crusade, as I look at OSS projects and realize if they use it I probably should too at some point but the barrier to entry is inherently steep. I look to articles like this posted to hopefully stir interest in fixing the usability problem and it's extremely comforting to know that so many people share that it most definitely has a usability problem. I really want to learn Git but I definitely do not want to be tasked as the Git-guru of my small developer team.
We use a paid hosting firm that only has svn or git to choose from and I can get away with pushing people towards Hg with hgsubversion much easier than playing tech support. Interestingly, in my experiance the chances that a random CS undergrad is comfortable with git is much higher than the chances of a random dev who has been in industry for a while being so. I read this post and see a number of ideas that could be turned into products by someone enterprising enough to do it, and who honestly believes such a market for them exists.
I've felt like this for so long. There is essentially no distinction between implementation detail and user interface. Its weakness is the complexity of simple tasks. I swear, someone needs to invent a Git-wizard program. Interactive with a wizard-like interface, it will walk you through all the common kinds of tasks, even if they're fairly advanced, explaining all the ramifications along the way. I haven't seen any programs like this -- all the GUI interfaces to git basically just translate to command-line commands, instead of trying to help you intelligently manage your workflow.
I don't think it would be easy to write a wizard interface like this -- it's a UI designer's worst nightmare -- but it would certainly help. Sounds like a great idea for making one type of workflow easy. The great part about Git not having an abstraction is that it supports almost any workflow. You can choose what flow is right for your project. Which is, by the way, why the documentation is not task-oriented, it's data-model oriented. The same command might be used for two completely different tasks in two different processes.
Other tools that aim to make the basics for committing easy do so at the expense of implicitly supporting only certain workflows. Think of something like Perforce. You don't enforce your process with Perforce, you choose your process so that it will work with Perforce. That's why I said it's a UI designer's worst nightmare.
Because there are a lot of different kinds of workflows, and I don't even know how you'd begin to organize them. I mean, maybe it's not even possible.
It would just be nice if it were more possible to "ease into" Git, rather than feel like you have to go through the equivalent of a college semester learning it. It's been 4 years now and I feel like a complete novice, but I rarely need to do anything other than 1 synching local with remote repo, 2 committing a change, and 3 using a feature branch. Then maybe there should be tools that use git to create a specific workflow. What I have now is a text file with all the git commands I need to follow the chosen workflow.
I don't have that for any other command line tools I use. Just because something is very flexible and supports many ways of doing something doesn't mean it has good UI and doesn't mean it has good discoverability.
I don't understand where you think I said it did. I specifically said it was a great idea to slap a better UI on git, but mentioned the caveat that to do a good job, the interface would have to be geared to a specific work flow. It's a workflow level abstraction over git operations. CognitiveLens on Aug 5, root parent next [—]. Upvoted because git-flow does address many of the points in the OP, but it's also an opinionated add-on that pushes users toward a particular workflow model that may not suit all applications.
In my usage of git-flow, I've found that I still need to be pretty comfortable with the "raw" git interface in order to effectively manage everything, so it also doesn't really get around the weaknesses of git itself. Exactly I feel the same way But the mere fact that there are so many How-to's on Git is an indication that is not an easy to learn system. But it should be since is one of the basic tools of a programmer. Or for a car mechanic how many manuals are there on how to use a wrench?
For a doctor how many books are there on how to use a stethoscope? As a counter-example, my great-grandfather, Morris William Travers, was the first director of the Indian Institute of Sciences in Bangalore and I gather that he said that he had to design the engineering curriculum there with a significant emphasis on learning how to use things like screw drivers and wrenches because the upper-caste Hindus were not familiar with these details of manual labor.
So I don't think that you can discount the cultural factors for our familiarity with hand tools. Certainly even in India, even in , you wouldn't have had to teach a repair man how to use a wrench. But you would have to teach the engineering student. That's a bit of a humbling thought. RasputinJones2 on Aug 5, parent prev next [—]. Git is far from perfect. But, there's roughly half bullshit, half "yes but is it really an issue?
It's a fad, and programmers are not impervious to fads - despite the many oppositions to this thought. Like everyone else in this world, everyone wants the shiny new toy Git. Git may be good - or even great to some people - but it's never been better than SVN when thinking objectively. This question was recently put on hold as primarily opinion based.
That classification is wrong; note that the question was open for a long time; that there are many questions about the virtues of DVCS, and that the question doesn't ask whether it's better opinion , but what it does better. The differences are not opinion but whether the overall product is - that's tricky but not the point of this question. Show 9 more comments. Active Oldest Votes. Subversion is a central repository While many people will want to have distributed repositories for the obvious benefits of speed and multiple copies, there are situations where a central repository is more desirable.
Subversion is conventional wisdom This is to say that many people especially managers and bosses have the usual way to number the versions and seeing the development as a "single line" along time hardcoded into their brain. Subversion does it one way, and nothing else SVN is a version control system. Improve this answer. In my current job, my boss, who claims not to have trust issues, configured the server to require locking. No merging happens in our system. Files are locked on the repository and nobody else can write them without the lock.
Top-down control, for those whose constitutions demand it, is definitely something svn does better than git. One advantage of the central repository is ease of backups. If all the checked in code is in one place, and that one place has off-site backup, you don't lose everything if your office burns down.
With a DVCS, unless you do off-site backups of the developer's machines, you lose everything that hasn't been pushed to the server that's backed up off-site. Why can't git be used in a centralized manner? Just have one central repository, and your devs can clone and pull and push like they checkout and update and commit.
PaulTomblin - Depending on workflow, Git can provide better backups. For instance, we use private github repos and I frequently push my code up to feature branches. If my coworkers do git fetch origin , each of them has a backup of my code, along with whatever backup Github itself provides. We regularly prune merged branches, both locally and on Github. You seem to imply that central is more secure for large companies or governmental work.
This is simply not true. If you have a copy of the code on your computer, you have a copy of the code. It doesn't matter if it came from a central server or a central file system holding a DVCS repository.
Show 25 more comments. Point taken, empty directories are nice, but not necessary either and can be worked around. If git submodules and git subtree were less confusing there would be nothing holding many people back from migrating to GIT.
The other advantages some people mentioned boil down to developer mentality. I wouldn't have any work for you though. It's funny how these are the only kinds of things that can be argued in favour of SVN and other centralized version control — dukeofgaming.
Why is it funny? There's even a benefit with RCS over git: The history files can easily be edited by hand and you can have per-file branches.
But eolution involves that features are lost I heard of a games company that uses SVN over GIT for exactly this reason - when your talking about a repository many GB in size, it suddenly becomes important! As of git version 1. Last subversion advantage bites the dust : Details here: github. Show 5 more comments. This isn't to say we aren't moving all development over to Mercurial. Being easier to grok is an important advantage, since that makes it more likely to be used.
SVN is certainly way better than no version control, and if someone is stubborn about old ways then maybe SVN is the best choice for them. It brings to mind the old story about NASA spending millions of dollars developing a pen that can write in 0g.
The cosmonauts on the other hand made due with pencils. Easily grokked is highly subjective, and is largely based on how you try to fit the new knowledge into what you already may know. It also makes a great deal of difference what your source of learning is. If you are going by man pages, good luck. If you are being taught by a good teacher who already groks it, you've got it made. I found git made tremendous sense after watching several good videos on YouTube.
If you get your understanding from someone who has already distilled it down to the simple core, then anything is easier to understand. Show 7 more comments. Doesn't break your brain? Wanna teach me how to easily merge branches with conflicts in SVN? Tools improve on both sides. None of us know what tools will be available several years from now. That assessment 10 months ago might easily change over time, and might be stale now.
I would prefer to see substantive answers. Tree conflicts? Yes or no to all options? Svn is designed to infuriate. Clean working copy command? Revert cannot clean unversioned files. Deleting everything and checking out again will clean unversioned files. I love your last idea, Git broke my brain :' — Luke. Regardless of the requirement to use svn for organizational reasons, I implore all svn users not to let their logical mind construct a false belief that more modern VCSes are only useful for large open-source projects.
Regardless of the nature of your development work, if you are a programmer, you will be a more effective programmer if you learn how to use better-designed VCSes, whether it be Git, Mercurial, Darcs, or many others. Subversion is very easy to use. I have never found in the last years a problem or that something doesn't work as expected.
With Git you get a more flexible VCS. You can use it the same way like SVN with a remote repository where you commit all changes. But you can also use it mostly offline and only push the changes from time to time to the remote repository. But Git is more complex and has a steeper learning curve. I found myself in the first time committing to wrong branches, creating branches indirectly or get error messages with not much informations about the mistake and where I must search with Google to get better informations.
If you work mostly offline with your local repository you have no backup if something is lost on your local machine. With SVN you are mostly working with a remote repository which is also the same time your backup on another server Git can work in the same way but this was not the main goal of Linus to have something like SVN2.
It was designed for the Linux kernel developers and the needs of a distributed version control system. Is Git better then SVN? Developers which needs only some version history and a backup mechanism have a good and easy life with SVN. Developers working often with branches, testing more versions at the same time or working mostly offline can benefit from the features of Git.
There are some very useful features like stashing not found with SVN which can make the life easier. But on the other side not all people will need all features.
So I cannot see the dead of SVN. Git needs some better documentation and the error reporting must be more helpful. Also the existing useful GUIs are only rarely. Eric Sink from SourceGear wrote series of articles on differences between distributed and nondistributed version controls systems.
He compares pros and cons of most popular version control systems. Very interesting reading. Articles can be found on his blog, www. Read the Diffs.
Git is the C of Version Control Tools. Why is Git so Fast? Mercurial, Subversion, and Wesley Snipes. I think it's fairly safe to say that amongst developers, the SVN Vs. Git argument has been raging for some time now, with everyone having their own view on which is better. This was even brought up in the of the questions during our Webinar on Subversion in and Beyond. Have a watch of his video and let us know what you think by either commenting on this blog, or by posting in our forums. Registration is simple and will only take a moment!
I have been dwelling in Git land lately, and I like it for personal projects, but I wouldn't be able to switch work projects to it yet from Subversion given the change in thinking of required from staff, without no pressing benefits. Moreover the biggest project we run in-house is extremely dependent on svn:externals which, from what I've seen so far, does not work so nicely and seamlessly in Git. First, concurrent version control seems like an easy problem to solve.
It's not at all. SVN is quite non-intuitive. Git is even worse. SVN supporters think they don't need a distributed version-control system. I thought that too. But now that we use Git exclusively, I'm a believer. When I need a branch, I branch. Sometimes it's a branch that has a corresponding branch on the server, and sometimes it does not.
Not to mention all the other advantages that I'll have to go study up on thanks in part to the arcane and absurd lack of UI that is a modern version control system. Why I think Subversion is better than Git at least for the projects I work on , mainly due to its usability, and simpler workflow:.
Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Why is Git better than Subversion? Ask Question. Asked 13 years, 3 months ago. Active 10 years ago. Viewed k times.
Active Oldest Votes. Git is not better than Subversion. But is also not worse. It's different. This looks good at first, but just keep in mind the added complexity to this approach. A Ferrari is not better than a Hyundai. Don't stare ME this way Did I say something wrong? No, you didn't. A Ferrari is impractical, expensive, thirsty, and will not get you better from A to B if you live in a city like New York or Paris - I'd prefer a Hyundai for many places, also because a scratch is much less severe.
But to each his own - a Ferrari has very few advantages as well Distribution is not the only difference between Subversion and Git.
It also doesn't add any complexity unless you use multiple repositories. There are many advantages of using Git instead of Subversion, but only a few mostly insignificant disadvantages. Git is used because it's good, not shiny.
My experiences with git aren't exactly a "Life changing revelation". I consider it a great tool when it works, when when it doesn't then it feels rather unpolished.
I wasn't too impressed debugging stuff like Question , and even though that is clearly an RTFM Problem: I do consider git and any other distributed vcs to be more complicated than centralized ones, and I would consider using it in centralized environments. But then again, i'm mainly a Windows developer, and the tools are still immature on Windows compared to SVN.
You only analyse the distribution aspect in the comparison. I'll tell you why. Because you only want to share code. Git and SVN are more than that, have you ever tagged, branched, merged, resolved conflicts, copy patches among branches?
I think your analysis is just flawed. In those aspects, git is a MUCH powerful tool. Not to mention things that git can, and SVN can't, like squashing, disecting, ammending, rebasing, cherry-picking, and much more things.
Show 17 more comments. With Git, you can do practically anything offline, because everybody has their own repository. Making branches and merging between branches is really easy.
Drawbacks of Git: it's much harder to learn, because Git has more concepts and more commands. Although learning all of Git would be much harder, the basics are almost identical. The learning scope isn't really that steep until you get into the more advanced stuff, which SVN is simply not capable of anyway. I think a lot of developers forget that git is lacking something like TortoiseSVN, and that not only developers use version control.
I love git, but it took me about six months of daily use to really use it effectively. That being said, I use a combination of the git shell command prompt from msysgit, git gui and gitk from msysgit, and TortoiseGit.
0コメント