While version control used to be reserved for big corporate projects, it is very mainstream these days. You can attribute much of that to Git, the software that has nearly displaced other version control. Git works well, it is versatile, and it scales well. It is easy to use as an individual developer or as part of a worldwide team. But Git is also one of those things that people don’t always study, they just sort of “pick it up” as they go. That motivated [Glasskube] to create “The Guide to Git I Never Had.”
If you are ready to click away because you are not a software person, hang on. Git is actually useful for many different kinds of data, and there are a number of hardware projects that use Git in some form. That’s especially true if the project has some code associated with it, but there are projects that consist of PCBs, reverse engineering documentation, or schematics.
Simplistically, Git tracks a bunch of files and lets you rewind in time to answer the question: what did this look like a month ago? Or a year ago? However, the real power lies in producing and merging branches.
For example, you might be working on a product and decided to add feature “A.” Meanwhile, your partner decides to work on feature “B.” No problem. You can each work in your own separate branch and get everything working. You don’t even have to be connected to a server until the very end.
When either of you are ready, you can merge your branch with the main branch. Often, this can be done automatically, but Git knows when it is in over its head and will ask for help. When you are both done merging, both of your changes are “live.” If you do it right, Git can also help answer the question: why did we make that change two years ago? It is surprising how often that’s important.
If you think Git is just for code, we can show you some strange examples. If you don’t fancy reading a blog post to learn Git, would you like to play a game?
RCS was available to all in the early ’80s, CVS was released in the early ’90s. From my experience, by the mid-90s using revision control was a must-have for any corporate (big or small) or open source project. By 2000 there were open source friendly free hosting options (sourceforge, sourceware and others I forgot). Then there was SVN (2004) , and then there was Git (2005), but I didn’t feel either of these where really driving a adoption of the practice of revision control.
But I may have a very opensource/linux centric path there, and I am curious as to what other folks experienced?
i started using rcs in 2001 at work. by the time git entered my awareness, i had already made some dumb shell or perl scripts scripts to fake git features like simultaneous commits of multiple files and interleaved history of whole directory trees. even using rsync instead of tar to copy around rcs repositories was an unknown yearning for git. rcs and cvs each just leave an enormous field of problems unsolved, and none of the easy hacks were really satisfying.
so yeah i was already using revision control before git but i use it a lot more now. i use it for everything. i use it for a lot of non-code things, like my tax forms, my diary, my presentations. but i’m from the same computer geek background as you are. anecdotally, i had a biologist friend ask for help using git. so i think it genuinely is like latex, one of those obscure computer things that reached at least into some relatively non-technical parts of academia.
I wrote a program for a teacher when I was in high school; he overwrote it. That’s when I started backing up my source. In college I used sccs, then rcs. Professionally, pvcs (barf), Visual Source Safe (double barf), cvs, svn, git. I was hesitant to move to git from svn, but once it clicked, I’ve been very happy.
I’ve been personally using CVS (mid-90′), subversion, svk (offline svn), all on linux, sometimes windows. At work we would use either those, or some proprietary stuff, but source were always controlled.
Now i use mercurial, because it’s just wayyyyyyyy better than anything else. And i use git because i can’t do otherwise on lot of projects :-(
I’m a consultant, lots of my clients are coding firms using git. And it’s a nightmare everywhere. Coders never really understand it, and, more or less, always end removing the directory and checking out again. They avoid branches like plague because they already have a hard time just comitting/updating.
I use git daily. We use branches massively. There are 5 programmers on our team. There are something like 10 branches active right now, one each for every assigned task.
I can’t imagine how you can call yourself a programmer and not be able to manage multiple branches and do commits and updates.
You misread. I don’t call me a programmer. That said, i’m perfectly fluent with git/branches/merges and such.
meanwhile in a dark corner of the city: Me working with incipient python scripts, .ino files and 5 lines bash scripts, shouting out yussshhhh!! every time the code works as intended and saving a copy of my latest code by just adding v1…v2…v3 :) I have a git hub account and I think I committed once not sure…
To me, Mercurial is easier to use and does more or less everything that Git does that is needed if your primary goal is to develop software. I pull a branch, modify something, commit and push the changes back… Merge if necessary. Git offers a lot of opportunities to screw this up, for example by asking me which branch I want to push the changes to – WTF, didn’t I just commit the changes to a branch? Or, why would it be useful to have my head detached? :) That sort of stuff doesn’t exist in Mercurial and in these couple of decades I’ve been using source control I haven’t encountered a case where I would miss it.
And on top of that, there’s TortoiseHG that slays other source control GUIs, it’s so streamlined that everything else I’ve tried (especially for Git) feels at least a bit like working with my hands tied.
My biggest problem with Git is that stuff that should be easy / is likely to be something you’d want to do regularly is often harder than it needs to be while making an absolute mess of things is often very easy indeed.
A lot of that could be solved by a very thin wrapper around it or a decent GUI that makes the right things easy and hides the footguns.
FWIW I still think Git is the “least worst” system we have for this sort of thing.
I use Mercurial with the hg-git plugin as a git client. It works absolutely fine and insulates me from nearly all of the git madness. hg bookmarks map to git branches. It’s good enough to work seamlessly with github, which I need to get stuff done.
I find the hg user interface to be so much better and easier to use. Complex merging becomes trivial because at any point the graph you’re looking at is always the graph that’s there and not git’s strange indirect view of the graph (still haven’t gotten my head around that).
The one downside is that checkouts are slow, as it spends some time migrating all the commits into the hg datamodel. One day I’m wondering if I can write a hg workalike which uses a native git repository…
You clearly haven’t tested mercurial .. !
Fossil is better.
That’s asking for trouble in any version control system.
GUI tools, even if they produce text files, usually can’t handle merges. So in the context of designing hardware, unless you have the thing split into multiple files one of you will end up recreating the other modification by hand or copying from another editor insurance.
Maybe one day someone will fix git submodules.
Never really got why Git was supposedly so much better (than anything in the history of the world, if you are inclined to listen to the hype). I suspect it’s just because it has a certain nerdroticism that others don’t. It’s certainly not because it makes errors less likely (it doesn’t).
git is better because it has more / better features than most others, and is much faster than most others.
its ui has a steep learning curve, though once you get up to speed i think it’s pretty good. but mostly it’s the features and the speed that lets you actually use the features, even on big repositories. it’s kind of stunning how far behind things like svn and hg and bzr are on both features and speed. i thought it would be a six vs half dozen thing but git really is an entire generation ahead of the entire competition on both fronts.
one perspective is that git is the canonical reference implementation of blockchain.
For me as a developer it is quite normal to switch between branches during a day. With git (and probably with mercurial it would be same but I lost the track on mercurial many years ago) I could do that easily and fast.
Let’s see such scenario. I’m in the middle of the development feature A and now something stops working. I could do git stash and check if that was done by my changes in few seconds.
Another scenario: I work on the code for some time but now I discovered the regression. I have no idea what caused that error and it is quite difficult to pinpoint the reason. I’m not even sure if that was done by my changes. git bisect allows quickly find the commit which introduce bug and this is possible because switching between commits is instant.
Last time I used f.e.: svn switching between commits (sorry for incorrect wording, I don’t remembe how it was called in svn) took really long time. It was impossible to be really flexible with the code as git allows that.
It was designed by Linus Torvalds to scratch various itches that the Linux kernel development team had. To the extent your problem resembles distributed development of a large OS kernel, Git is a great solution. If you are doing anything else, it’s basically a cargo cult.
SCons + Hg. It is what Odin used to build the universe.
I also use SCons with git. But git, by itself, really sucks.
“While version control used to be reserved for big corporate projects,”
I have no idea what you are talking about.
In the early naughts I was working at a “big corporation” of 5 people using Subversion. And Subversion I believe was generation 3 of FOSS version control (as in the vcs was FOSS, not that it was only used to produce FOSS). Preceding that were CVS which I had used for personal projects as a college student in the late 90s and RCS which was before my time.
When was this “big corporate projects only” period? The 1970s? Early 1980s?
I had no idea there were big corporate VCSs until my current job at a MickeySoft shop where a MickeySoft VCS is use and that only because no one has wanted to take on the job of trying to convert 20 years of commit history to git. The switch is a ticket we have been pushing to the back burner forever now.
I assumed it was the OSS world that invented the concept of VCS having projects to manage that included such diverse people separated by so much geography and time zones.
Since we’re making a list….
Microsoft Delta (I loved it, but that was 30 years ago), Source Safe (I hated it, even before Microsoft bought ’em), RCS, CVS, Mercurial, PVCS, Perforce, whatever IBM visualage was, and now GIT, I’m sure I missed one or two in there.