Conservative. Idaho. Software engineer. Historian. Trying to prevent Idiocracy from becoming a documentary.
Email complaints/requests about copyright infringement to clayton @ claytoncramer.com. Reminder: the last copyright troll that bothered me went bankrupt.
"And we know that all things work together for good to them that love God, to them who are the called according to his purpose." -- Rom. 8:28
Basically, it's a very good distributed version control system for people who are willing to learn, and remember, totally obscure details and inappropriate names for things. If you don't do that, then you had better find a documented workflow that covers every case you care about.
Put another way, it is nerd heaven - sort of like Unix command line knowledge but far harder to learn.
My own experience is one of significant frustration, because I'm not interested in memorizing arcana. I use git for my personal and consulting VCS, starting about a year ago (after using SVN and before that, CVS, and before that, a home grown wrapper for SCCS).
Where I run into trouble is using a remote repository - which is the main reason for using git in the first place. I have several times tried to push my local changes to github or another repository on another machine, only to have extremely cryptic messages pop up.
Most recently, I created a major branch in my Android app. I pushed it up to my other local machine first - no problem. I gave up trying to push it to the github repository after that. I ended up having to create a new github repository and pushing to that. I am simply not going to ever again to try push it to my local backup repository. YMMV.
Note that I gave up on using the git included in Eclipse, because that added one more layer of complexity in trying to solve problems. Instead, I use it from the Unix command line (Max OSX or Windows+Cygwin).
On the positive side, it is nice to have a very network-efficient way of sending and receiving repository changes or even full repositories. When it works...
As I understand it, if you do find a workflow that is appropriate, it is quite good. If you do that (and I think I've found one for my use), the it reportedly works quickly and doesn't screw up.
Maybe someone more expert will show up to comment. I'm interested to hear - the usual thing you get when asking questions (say, StackOverflow) are answera to the effect: "you idiot."
Not bad, though it took a little practice before the process became habitual.
Git runs a local repository on your machine, which can be synchronized to an outside repository. This allows you to branch on the local machine, or pull down a branch created elsewhere. It also allows you to switch between branches without pulling data from the central server.
Other than that, it's mostly a normal source-control system. Forks, tags, revision history, and logs are all baked in. It even comes with "blame" built into it.
I've used Git for personal and professional projects. I've also used Subversion/SVN when I worked for a previous employer.
What I like about Git is the distributed nature of their VCS. When I used Subversion I felt like I was walking on eggshells when I made a commit because of the fear that I would clobber someone else's changes. (The mantra I learned at that job was, "Update broadly, commit specifically".)
With Git, every working copy is its own repository, so when you make commits you make them to your local repository. I don't claim to fully understand the inner workings of git (this Stack Overflow question is helpful), but the main point is that commits are cheap and branching is cheap.
There is a learning curve with Git and distributed version control but neither are terrible as long as you aren't getting into anything truly arcane like submodules or rebasing. It doesn't work well with version-controlling binary files. And make sure that you've committed all changes to a working copy before you bring in changes from an external repo (e.g. make a merge or rebase).
Git is what's known as a DVCS (Distributed Version Control System). In other words, there's no reliance on a central server - each local repository is a full-fledged repository in and of itself. I personally happen to prefer another DVCS, Mercurial. Both have some pros and cons. Git is more popular, but some of the commands can be confusing and overly complex. Mercurial has a friendlier set of commands and better Windows support. Both work great for offline development and in larger teams.
Both Git and Mercurial are a vast improvement over pretty much any other version control system out there, with a few minor caveats (they both struggle a bit with very large binary files). Totally worth learning how to use them. Lots of documentation and tutorials available for both.
Forgot to say: my current use of Git is in conjunction with Gerrit code-review, which simplifies things on the central-repository side of things.
The code-review process keeps the central server from having any complex forks in its tree, but it allows me to play with branch, rebase, merge, edit, etc., on my own copy.
IMHO, if you're not a Linux kernel engineer, the primary reason to choose Git over Mercurial is because you want to share your project on Github (in which case you should download their GUI to simplify the syncing process). Both have IDE plugins for things like Eclipse, Visual Studio, Netbeans, etc.
My personal preference is Mercurial, because it has better conversion tools and interoperability, and it's easy to customize in Python.
Although I've found it challenging to come to terms with Git (the type that StormCchaser pointed out), I nonetheless find that I like it a lot. I particularly like being able to branch and merge quickly; I've gotten into the habit of branching whenever I need to do something new, and then merging things back into the main branch when I'm done. Git makes this easy; hitting a big merge conflict can be painful, though, and it can be very bothersome to hit one of the more arcane portions of Git.
While I'm aware of the various GUI tools out there, I particularly prefer the command line (I even like using "git log lots-of-options-I-never-remember-I-really-should-alias-this" to gitk. (I've even aliased it at one point, but that was at home, not at work...)
I also like how "git bash" can give you Bash for Windows, although I don't like how I can't even install "GNU screen" in that bash.
Take my review with a bit of a grain of salt: I have very minimal experience with SVN, although I have seen second-hand how rigid working with SVN can be, and how fragile branching can be; before that, I wrote my dissertation using "Roman Numeral" Version Control: when I reached a certain stage, I'd copy all my files, appending -IX (or whatever version I was on at the time) to the end of them. Using *any* VCS after that is great!
And from what I understand of the issues involved, I would take distributed over central any day, because distributed systems simplify branching and merging considerably.
It's a little harder to learn than SVN, although that's less of a problem in the Windows ecosystem (where TortoiseSVN and TortoiseGIT are wonderful helpful things). For small person or one-man projects, and excluding odd scenarios like a developer with sporadic internet access, I'd probably use SVN just for the slight extra simplicity, but modern GIT is robust and reliable enough for pretty much any environment.
Basically, it's a very good distributed version control system for people who are willing to learn, and remember, totally obscure details and inappropriate names for things. If you don't do that, then you had better find a documented workflow that covers every case you care about.
ReplyDeletePut another way, it is nerd heaven - sort of like Unix command line knowledge but far harder to learn.
My own experience is one of significant frustration, because I'm not interested in memorizing arcana. I use git for my personal and consulting VCS, starting about a year ago (after using SVN and before that, CVS, and before that, a home grown wrapper for SCCS).
Where I run into trouble is using a remote repository - which is the main reason for using git in the first place. I have several times tried to push my local changes to github or another repository on another machine, only to have extremely cryptic messages pop up.
Most recently, I created a major branch in my Android app. I pushed it up to my other local machine first - no problem. I gave up trying to push it to the github repository after that. I ended up having to create a new github repository and pushing to that. I am simply not going to ever again to try push it to my local backup repository. YMMV.
Note that I gave up on using the git included in Eclipse, because that added one more layer of complexity in trying to solve problems. Instead, I use it from the Unix command line (Max OSX or Windows+Cygwin).
On the positive side, it is nice to have a very network-efficient way of sending and receiving repository changes or even full repositories. When it works...
As I understand it, if you do find a workflow that is appropriate, it is quite good. If you do that (and I think I've found one for my use), the it reportedly works quickly and doesn't screw up.
Maybe someone more expert will show up to comment. I'm interested to hear - the usual thing you get when asking questions (say, StackOverflow) are answera to the effect: "you idiot."
I love git. I really like Veracity too. Svn? GREAT!! Serena tools like PVCS and Dimensions (Dementians)? Total suckage.
ReplyDeleteI've used Git for a work project.
ReplyDeleteNot bad, though it took a little practice before the process became habitual.
Git runs a local repository on your machine, which can be synchronized to an outside repository. This allows you to branch on the local machine, or pull down a branch created elsewhere. It also allows you to switch between branches without pulling data from the central server.
Other than that, it's mostly a normal source-control system. Forks, tags, revision history, and logs are all baked in. It even comes with "blame" built into it.
An alternative worth a look is Mercurial. See Joel Spolsky's tutorial at http://hginit.com for a great description of key concepts.
ReplyDeleteI've used Git for personal and professional projects. I've also used Subversion/SVN when I worked for a previous employer.
ReplyDeleteWhat I like about Git is the distributed nature of their VCS. When I used Subversion I felt like I was walking on eggshells when I made a commit because of the fear that I would clobber someone else's changes. (The mantra I learned at that job was, "Update broadly, commit specifically".)
With Git, every working copy is its own repository, so when you make commits you make them to your local repository. I don't claim to fully understand the inner workings of git (this Stack Overflow question is helpful), but the main point is that commits are cheap and branching is cheap.
There is a learning curve with Git and distributed version control but neither are terrible as long as you aren't getting into anything truly arcane like submodules or rebasing. It doesn't work well with version-controlling binary files. And make sure that you've committed all changes to a working copy before you bring in changes from an external repo (e.g. make a merge or rebase).
Good luck!
Git is what's known as a DVCS (Distributed Version Control System). In other words, there's no reliance on a central server - each local repository is a full-fledged repository in and of itself. I personally happen to prefer another DVCS, Mercurial. Both have some pros and cons. Git is more popular, but some of the commands can be confusing and overly complex. Mercurial has a friendlier set of commands and better Windows support. Both work great for offline development and in larger teams.
ReplyDeleteBoth Git and Mercurial are a vast improvement over pretty much any other version control system out there, with a few minor caveats (they both struggle a bit with very large binary files). Totally worth learning how to use them. Lots of documentation and tutorials available for both.
Using it now, still getting used to it but generally happy.
ReplyDeleteYou may want to look at the 'git-flow' plugin which streamlines a particular approach to workflow.
-Zach
Forgot to say: my current use of Git is in conjunction with Gerrit code-review, which simplifies things on the central-repository side of things.
ReplyDeleteThe code-review process keeps the central server from having any complex forks in its tree, but it allows me to play with branch, rebase, merge, edit, etc., on my own copy.
IMHO, if you're not a Linux kernel engineer, the primary reason to choose Git over Mercurial is because you want to share your project on Github (in which case you should download their GUI to simplify the syncing process). Both have IDE plugins for things like Eclipse, Visual Studio, Netbeans, etc.
ReplyDeleteMy personal preference is Mercurial, because it has better conversion tools and interoperability, and it's easy to customize in Python.
-j
I hear it works just fine; I mean, works well enough for the Linux kernel source, which is pretty punishing.
ReplyDeleteWe use mercurial (hg) here, which is also just fine.
Although I've found it challenging to come to terms with Git (the type that StormCchaser pointed out), I nonetheless find that I like it a lot. I particularly like being able to branch and merge quickly; I've gotten into the habit of branching whenever I need to do something new, and then merging things back into the main branch when I'm done. Git makes this easy; hitting a big merge conflict can be painful, though, and it can be very bothersome to hit one of the more arcane portions of Git.
ReplyDeleteWhile I'm aware of the various GUI tools out there, I particularly prefer the command line (I even like using "git log lots-of-options-I-never-remember-I-really-should-alias-this" to gitk. (I've even aliased it at one point, but that was at home, not at work...)
I also like how "git bash" can give you Bash for Windows, although I don't like how I can't even install "GNU screen" in that bash.
Take my review with a bit of a grain of salt: I have very minimal experience with SVN, although I have seen second-hand how rigid working with SVN can be, and how fragile branching can be; before that, I wrote my dissertation using "Roman Numeral" Version Control: when I reached a certain stage, I'd copy all my files, appending -IX (or whatever version I was on at the time) to the end of them. Using *any* VCS after that is great!
And from what I understand of the issues involved, I would take distributed over central any day, because distributed systems simplify branching and merging considerably.
It's a little harder to learn than SVN, although that's less of a problem in the Windows ecosystem (where TortoiseSVN and TortoiseGIT are wonderful helpful things). For small person or one-man projects, and excluding odd scenarios like a developer with sporadic internet access, I'd probably use SVN just for the slight extra simplicity, but modern GIT is robust and reliable enough for pretty much any environment.
ReplyDelete