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 itself as the de facto standard for version control and software collaboration.
But I'm wondering if, now that we've lived with git for a while, are there any clear alternate approaches we could be considering for what we do in software development. Git is not exactly the easiest thing to not mess up.
But it can be hard to even imagine an alternative to such an ingrained practice, but I'd love to hear any thoughts on the subject at all.
Latest comments (49)
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.
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.
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.
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 :)
YES!
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.
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.
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.
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.
"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.)
;)