Git was invented by the Linux project in order to move beyond the crappy solutions they had in place before, and since then it has established itse...
For further actions, you may consider blocking this person and/or reporting abuse
Git is the classic example of something that was invented to solve one problem, but ended up solving a different, more important problem along the way. For that reason, I do think that Git could (nay, will) eventually be supplanted by something better, something that directly addresses the more important problem that Git solved by accident.
To be more specific: when Linus created Git, his goal was to create a version control system that would be fully distributed. You have to understand, he was targeting the Linux kernel, a project which is extremely widely distributed and for which there are many "sources of truth". In other words, the goal was that the Linux Foundation could host a Git server with history, branches, and tags for the "official" Linux kernel, but RedHat or Canonical or Debian might also host Git servers with their own branches, history, and tags for kernels that are just as complete as the "official" version.
Most teams, however, don't have more than one "source of truth". Every time you see people complain that "GitHub is down", what they're really saying is "even though Git is fully distributed and capable of supporting multiple 'authoritative' nodes, we've agreed on using GitHub as the de facto central repository we all depend on".
Why is it, then, that so many people use a version control system when they're not interested in its raison d'être? Because along the way Linus solved a smaller, but much more valuable, issue: local versioning.
Young coders may not remember, but back in the bad ol' days of Subversion, if you wanted to save something you were working on so that you could move on to something else, your choices were: a.) save the file locally, then try and walk back the changes when it came time to
svn commit, or b.) make sure you are connected to the Subversion server,svn commit, and pray there are no conflicts with anything anyone else was working on.Actually, there was a 3rd option known as "SVK". On the surface,
svkworked much likegitdoes today: you would keep a copy of the Subversion repository locally, to which you could commit as needed, and periodically you wouldsvk syncwith the main Subversion repository.So, I honestly believe that Git "won" not because it is completetly distributed, but merely because it allows developers to work locally at will, and synchronize centrally only as needed. Really, this is a natural progression from the earliest version control systems where you would have to actually lock a file on the central server before you could edit it, to Subversion which did away with locks but still required access to the central server in order to version changes. Some new system that focused more on the local developer experience, and simplified the "central repository" situation (since the vast majority of teams will only ever have one central repository), could easily eat Git's lunch.
Great reply
Subversion... I used to dream of Subversion. I had to use CVS.
But anyway - Subversion did something truly amazing. People had used CVS - which is itself based around RCS - for so long that it'd somehow become a fact of life that version control systems were too difficult to write.
Even BitKeeper was itself based on RCS. And of course BitMover forbid anyone using BitKeeper - paid or not - if they worked on any other version control system.
Once Subversion proved that version control systems were, in fact, things which ordinary mortals could write, then suddenly everyone was writing them.
The distinction between a different branches and repositories is what makes git so genius. There is none. Just because you call your local branch master and I call my local branch master doesn't mean we are both on the same branch. Rebases and merges work the same when performed against local branches and remote branches. The use of a cryptographic content addressed object store is what makes this work. Syncing is as simple as exchanging read only objects.
So, even though teams don't necessarily use many remotes, they do use loads of branches, which is why they need Git. There are at least n+1 branches where n is the number of people plus whatever feature, production, developmnent, etc. branches people create. On my team that means well over a thousand in the past six months. Some branches are long lived, some are short lived.
Github is just a convenient way to synchronize change. Most teams use it incorrectly by allowing multiple individuals to write to the same repository instead of cloning and creating pull requests.
There is still plenty of room for improvement. Git is not very usable for non experts. A lot of the complexity has to do with dealing with the many ways merges and rebases can fail to work as expected. One limitation here is that a merge commit typically has only two ancestors. Git actually allows for more than two but the porcelain just does not use this. There have been some alternatives where this is used to track changes from multiple branches.
Another area where Git is struggling is larger code bases. The linux kernel is not small but there are examples of big companies where git just isn't good enough for tracking everything they have in one repository. E.g. Google does this (not using git for that). So scale is an issue. Then even though git is distributed, it is not sharded. This imposes upper limits on what can be in a single git repository. The model has always been that you need the entire repository locally to be able to work with it. Wouldn't it be nice if you'd only need a subset of that to be able to work.IPFS copies some of the design for git and stores content addressed objects in a distributed FS. Wouldn't it be nice if somebody rebuilt git on top of that?
So, there's plenty of room for improvement in the Git world.
Unless I'm misunderstanding, Microsoft actually built an implementation to allow working with a subset of files in a repo. They called it Git Virtual File System in case you want to check it out!
Here is an article about changes MS had to do to Git, interesting read
arstechnica.com/information-techno...
Well i know it's not Sharding. but if you need a Subset of a git repo you can do a shallow clone.
I find that useful for Repo's that are very large.
This is a good response, though I think it is missing one fairly important point in the why git was created portion. Bitkeeper, the original VCS for linux, originally had extremely restrictive licensing, but was free (money) for open source projects. Then in 2005, changed the licensing to start charging open source projects too. Most developers in the project would be able to purchase the software, but due to a separate project being worked on by the OSDL (Linux foundation now) that infringed on the restrictive licensing made it so that anyone working for the OSDL (Linus Torvalds) couldn't use the software.
Linus, in his typical Linus-y way, flipped Bitmover a bird and built his own, git, "the stupid content tracker". Bitkeeper was distributed and had most of the features necessary, but was too restrictive.
I used to just keep a copy of the entire Subversion checkout in another directory, then diff -qr them and rsync them as needed if I wanted to work on a local branch. I'm pretty sure that was common practice and it's basically just a manual way of doing what git does.
Git made it easier by reducing the friction and fragility of local history management, and Github made it "win" because the interface was so much prettier than WebSvn and because it was entirely hosted and mostly gratis.
I don't know anyone working in a company who has a second "source of truth" beyond GitHub, Bitbucket, or their local machine these days.
Sorry sir, what do 'authoritative' nodes mean?
I think there's some definite value to something like this if you get the right buy-in and do it the right way. I think that's a pretty herculean task, but I wouldn't be surprised if something like that could get some legs if executed on right.
Could there be another solution that optimizes in the other direction: Like, not caring as much about scalability, but focusing on productivity and safety at the early stages? Maybe with a built-in path to git when the time comes?
Here's an article I read awhile ago: hackernoon.com/where-do-we-go-afte...
I would be interested to see some Dropbox + Git combination.
I think Git is simple enough to create tools over it (like Github) in order to extend it.
Example: Pull Requests aren't a feature of Git, but nobody would use a version control platform (Github, Gitlab, etc.) without that feature which was built upon Git branches.
So instead of doing Git again from the ground I think is better to just improve tools built upon Git, maybe simplify the flow to avoid messing it up.
That's reasonable. Git could be a bit like the assembly language for version control. Regardless of abstractions you build, it compiles to git for compatibility and leverage the immense work put into it.
Git Flow, anyone?
Oh nice, I remember this but had forgotten about where I read it.
Fossil looks interesting. It was created by Richard Hipp who also runs the sqlite project.
Here's a talk about the problems he sees with GIT:
I love Fossil. It has its quirks, as do the alternatives (Git, Mercurial, et cetera), but it provides what I need much more effectively and with far less hassle than those alternatives. In fact, I've been doing more and more of my work in Fossil, and I host my open source Fossil repositories on the web. I'm not sure I'll ever create another repository in Git that isn't a clone of a Fossil repository again, except when I'm somehow required by someone else (e.g. an employer) to do so.
Speaking of clones, I wrote a fairly simple tool in Ruby, called FossGit (
gem install fossgit), to mirror my work in Fossil repositories on GitHub. The GitHub network effect is too valuable to ignore, at this point.That's awesome, Chad. Thanks for sharing.
Git is, in my opinion, one of the most brilliant pieces of software ever written (I'd go as far as saying it's Linus' biggest achievement, rather than Linux). It's an example of software that's so well designed that it keeps surprising you (well me, at least) by its versatility and performance.
By now there aren't any serious competitors left and maybe that's what's triggering you to ask "aren't there alternatives". In other areas (backend frameworks, frontend frameworks, operating systems, etc etc etc) there are dozens of alternatives with none of them clearly superior, but Git is indeed dominant, but I'm saying deservedly so.
For me it's a breath of fresh air to have at least one area where I'm not bogged down by too many choices with no clear added value.
Add to that the huge installed based (just Github alone but also in enterprises) and the huge boost which Git (and Github) are for OSS and "social coding" (sharing, contributing) - then the conclusion for me is that any alternative has to be clearly superior, not like 50% or 100% "better" but an order of magnitude better, otherwise it won't stand a chance.
That's a very good take.
would just like to mention Mercurial (HG), it's still alive and well and is often much easier to use. Pair it with BitBucket (again has some nice things github doesn't) with it's unlimited repos and a bunch of nice clients (if cli isn't your thing) makes Mercurial a great git alternative.
Both came around after Subversion, but git won the popularity contest for variety of reasons.
HG all the way for me!!! I used HG for my team for about 4+ years and only in the last year moved to GIT as my team merged with a larger group and GIT was the main used by all teams merged. I still love HG's simplicity and paired with BitBucket was awesome.
Personally, I prefer either Mercurial (hg) or Bazaar (bzr). However, since GitHub is the place to do open-source development, if you're going to play in that arena, you've got to be at least familiar.
(There's probably an interesting thought there, something about superior tooling around acceptable-quality software being a killer combo, but my employer would probably rather me philosophize when I'm not on their dime.)
It's the GitHub pull request. That's the killer feature of Git, even though it's not a feature of Git itself.
I really hope not. It has great features but a terrible interface. The command-line is a chaotic mess of inconsistent names and patterns. There are numerous ways of doing certain things, yet there is a lack of orthogonality, meaning things like syntax referring to a remote differs depending on the command.
Using git feels like navigating planks laid across a swamp. One wrong move and you've screwed something up. This is not exactly inspiring for version control.
I prefer the consistency (and UI tools for that matter) of bzr. It's much harder to screw things up, and I don't find myself constantly looking for references online. Granted, I tend not to do as much in bzr than git, but still, it just feels easier.
Curious about what alternatives already exists right now? I've only used git. Is there any other version control system in use today? If there are, what are the differences?
If you could change anything about the way git works right now, what would it be? Looking at the OP, I suppose you would like it to be more beginner-friendly?
There's Mercurial aka hg. I started with it about 7 years ago because git was "too hard". I couldn't find explanations about what "origin" or "HEAD" are and it all looked like a mess. So hg was much better (read: simpler) for me at the time. I don't quite remember the details but eventually I started looking at git and GitHub was also gaining popularity. It never had Mercurial support unlike BitBucket which I think I used back then. I sorted out all the essential knowledge about remotes, refs, commit hashes (instead of monotonically increasing revision numbers in hg) and switched in the end.
I never looked back.
"It's hard to imagine an alternative..." because our (relative short) professional experience (1-5-20yrs), but things are evolving very fast.
I think Git is not used as intended 99% of cases, we use it in SVN style, 1 central server with 1 main branch, so we may have a Git alternative that simplifies Git in the way we are using it. It's just a thought.
Git doesn't solve all the problems, and has big issues keeping up with the big projects
Other industries uses other versioning systems
Git exposes too powerful functions, so any contributor can use one of them in a wrong way, maybe a future simplified and modified alternative will be more successful.
For developers new to Git, I like to tell them that Git is not a version control system at all.
It's a set of tools with which one can build a number of different, and largely interoperable, version control systems.
Github, for example, is one such, as is Gitlab. The way I work with Git locally doesn't really match Github or Gitlab, but this doesn't matter much because I can export data between them easily enough. There really is no wrong way to use Git. Well, not true - you can shoot yourself in the foot with Git if you so desire - but any workflow you like is just fine. It does not impose any particular workflow on the developer.
It's easy to forget that Git was designed exactly like this, as a set of low-level primitives that people would glue together any old how. There was a strict division between "plumbing" and "porcelain" that probably only exists now in the minds of the Git developers themselves.
The other way that Git broke the mould was that it was built to be a mutable history. That in itself ran against everything that a version control system should be, many thought - and the rebase/squash/split workflow is certainly that hardest to get to grips with. But this opens up vast possibilities for workflows that nobody could have considered before.
Because of these two factors, I don't see Git being supplanted - it's simply built in such a way that it can incorporate many new ideas without drastic rearchitecting.
But it is always a good idea to look at other systems to harvest other good ideas. Git is flexible enough, after all, to integrate some pretty funky workflows.
As a first step, you should go look at Monotone. Monotone is Git's spiritual father - it's driven by a classical database (sqlite, as I recall), but is otherwise fairly similar to a typical version control system build with git. It has branches, SHA hashing, no version numbering, etc. It goes a little further in terms of security (though Git has caught up), but crucially, these are the guys that invented many of the concepts, like a Directed Acyclic Graph for versions, that Linus then used much more efficiently in Git.
The Monotone project came up with some wonderfully byzantine ideas. For example, to fix a bug, you identify when the bug was introduced, and branch there. You then fix the bug in this new branch, and then merge the result to any downstream branches of the commit the bug was introduced in. Now, you can identify the revisions in which the bug is present by where the bug-fix branch is not yet merged. The basic idea of using branches very fluidly is certainly prominent in most Git workflows, but the notion of using them directly as bug tracking is definitely a new concept.
By reading the comments it seems to be that just going through git documentation with a fine tooth comb, gathering feedback from devs and non-devs and rebuilding the UX with a tool on top of git would already be a great enhancement.
What I miss in all those revision control system discussions is a statement about how easy/hard it is for a given RCS to meet the requirements of software development maturity assessments, such as CMM, SPICE, Automotive Spice and so on. While many active members of this community might be lucky enough to develop software in an open source context, as a hobby or in other non-highly industrialized contexts, the majority of developers probably are not as lucky. I was part of teams preparing for such assessments and especially in the category of configuration management, the chosen RCS is cruicial if you want to convince people that you are doing it right.
As for git, with me coming from originally VSS (exclusive checkouts YAY!) over subversion (at least the 1 truth location and no discussion about what the official sources are), I find git particularly imposing on an organizations workflow. Teams, developing in tight, planned loops with customers (e.g. supplier and OEM in automotive), according to assessment-driven workflows are in dire need of RCS features, hardly ever discussed in public. And with GIT, I would not even know how to make it work.
I've been meaning to try Plastic SCM someday, which focuses on highlighting semantic changes in its diffs instead of doing a simple line-by-line comparison.
I don't know much more about it other than the elevator pitch for it, though. Tracking semantic changes rather than line-by-line changes seems like a natural evolution of where we are now, though.
The things that made Git so popular are who wrote it and the fact someone built GitHub, which re-centralized things (unfortunately) to make it easier to collaborate (fortunately) via forks and pull requests. It's not like there weren't other distributed version control systems that provided much the same benefits as Git, in some cases actually doing it better for some use cases. Fossil and Mercurial had better built-in, default "developer ergonomics", for instance, and Fossil came with other benefits like an issue tracker system that gets distributed with the versioned source, an incredibly easy built-in deployment mechanism, ACID compliant version history, and so on.
In short, the GitHub pull request is the killer feature of Git relative to other DVCSes (it's certainly not the rest of GitHub, which tends toward some mediocrity of delivered value). The benefits of DVCSes themselves, absent the GitHub pull request, are of course centered around the ability to work independently and keep local versions before synchronizing with upstream.
Whatever comes along to unseat the current DVCS approach probably needs to combine integrated GitHub-like (or even better) pull request functionality directly in the developer's tooling, build on Fossil's idea of making more of the complete toolset distributed in the same way, and provide at least the independent working capabilities of current DVCSes. Add to that a new "killer feature", and see what happens.
I just don't know what that new "killer feature" would be. I kinda hope it's some kind of fully distributed routing/indexing system with BitTorrent-like shared access for cloning. While it's not distributedness per se that made Git popular, I quite like the subtly subversive character of the distributedness of DVCSes, incidentally giving rise to benefits that even centralized dev shops need so that the distributedness sneaks into everything. Empowering a greater diversity of innovation seems, to me, like a clear win.
I do not think Git will be the premier SCM solution forever, but I think it is the best of the 3 that I know of and have worked with (Git, Subversion, Mercurial).
The CLI API is complex enough that it allows for segmentation of operational tasks (adding files per-commit, committing and pushing without having to commit/vice versa, directory structure-agnosticity), but is also simple enough and helpful enough that a beginner could learn it in short order using an existing project/directory.
Despite personal preference, Git appears to have won the sprint, however, considering the propagation of the SCM in the open source community.
Git gave us a lot of brilliant concepts, translates into a really good team flow, could have a better execution.
Let's say I'm midway through a large change, someone walks up and asks me to do a quick fix in another branch - with TFS, I don't have to do anything with my pending changes, I just open the other branch in another IDE instance, make the changes and check-in. Not so easy with Git. I don't have a problem having branches separate in the filesystem.
Another one is version control curation. Although not much you can do in TFS, it was never much of an issue because the UI made it pretty regardless. But vim is terrible. Notepad is one of the most important applications ever written and we shouldn't forget the advanced UI concepts it introduced to us.
Nothing is the "be all and end all" of anything. Git's fantastic, but I'm a strong believer in "every tool has its use" - so Mercurial and (gasp) [probably] Subversion still have their place, albeit shrinking.
Then again, let's face it: in a decade's time (or sooner), Git will have been supplanted for the "best" VCS by something entirely.
I think git is just as much the be-all and end-all of version control as Altavista is the be-all and end-all of search engines. Meaning: the moment something better comes along (like, I don't know, google?) we will all drop it like we did with cvs.
That said, Linus Torvalds' weekend project seems to have an impact like his experiment trying out the 386 architecture in 1991. So that moment when we drop git may well be many years into the future, so for now it is just as well that it is the de-facto standard.
TFS is pretty easy to use for those of us in the Microsoft world. But if I'm doing anything else (even .net core) git is my go-to.
And even TFS has Git built in now which I believe is the recommended setting for new TFS installs.
Run away from TFS version control. It's a trap! :-)
Actually, there are. You should look to dark (or darc?) and pijul for something totally different, mercurial for something similar.
You were looking for
darcsThanks :)
"Git is not exactly the easiest thing to not mess up."
Double negative. Kinda hard to understand.
Well, we can cancel them out...
"Git is exactly the easiest thing to mess up."
You're right - that's way more clear! :)
(This is a light-hearted dig at git's complexity, not your comment about Ben's wording.)
;)
YES!