Reputation: 311275
For someone coming from a more conventional VCS background (CVS/SVN), what are the most compelling reasons to learn and migrate to git?
Please comment upon a team's required technical ability in order to make git work. I've seen smart people climb the learning curve and still lose some hair over it. Can anyone climb this curve, or is git not for all teams?
Of course I also want to hear about functional benefits, tool support, integration other systems (CI, etc)...
(This seems like an obvious question, but I didn't find a duplicate of this despite a few searches)
EDIT Links to good resources also appreciated.
Upvotes: 32
Views: 4975
Reputation: 1328342
On the top of my head:
The main difficulty is to establish a workflow between the different repos, without breaking the history of what has already been published (pushed to a public repo).
(source: infoq.com)
The rebase in particular can be difficult to use correctly at first, since it does rewrite the history of a branch, and that changes the SHA1 which is associated with it: to a public branch, that means lots of merges from the other developers pulling from it.
Upvotes: 19
Reputation: 1034
The story of GIT is a classic in FOSS history. See the history of Git in Wikipedia. Tags for that story: BitKeeper, Andrew Tridgell, Torvalds, Git, self hosted in 2 days.
Well, not an answer, someone with a FOSS/ Hacker attitude would surely love to read it.
Upvotes: 2
Reputation: 13763
I realize this is a question about Git, but the OP should realize that many of the benefits apply to all major distributed version control systems. Git, Mercurial and Bazaar all have their own strengths and disadvantages so you should study all three and decide which one is best suited for the way you work and your projects.
Upvotes: 3
Reputation: 8512
A lot of people talk about how complicated git is to use, but it is worth nothing that if you stick to a very simple usage pattern git isn't any more complicated than say RCS.
Using git for your own locale revision control (for the same kind of things you would have used RCS) is I would argue easier than using RCS.
Of course when you use it for big projects with loads of people and a lot of branching etc then it can get more complicated than traditional revision control systems.
Personally I have used it mostly for personal projects and for having local revision control at work. We use perforce at work and they are pretty strict about the number of branches we can make at what we can check in. We got to check in finished, compile-able, testable chunks of code.
Often I was working on bigger refactoring jobs and doing smaller fixes on the side at the same time. I found that very difficult to juggle with perforce. But with git I was able to have loads of small locale branches for different experiments, refactoring and bug fixing I was doing.
So for me the big selling points of git are:
The reason for the last point is that git keeps all the branches in the same directory so you swap between them with git commands and stay the same place. I like that because it means that I don't have to set up configuration files for my IDE for a new directory each time I branch and I don't waste loads of space from having insane numbers of branches.
Upvotes: 2
Reputation: 1371
Git is extremely fast and stores repositories in a very compact manner (think one tenth to one hundredth the size of the same code base + history in svn). Git (and most distributed VCS) give you cheap branches that are painlessly spawned, worked on and merged. That all happens locally and team members are not distracted by teammates' ongoing work unless there is a proactive effort to share it.
Moving to distributed VCS will lead to some changes in development style which some developers will love, but others may well hate. There's no question that git is a complex beast where there are many paths to the same outcome. In leading a group migration to git you'll need to invest some time in learning those paths and then sketch out a workflow and a cheat sheet of commands for common scenarios.
I'd recommend first getting comfortable with it as a client, talking to github or a similar tool.
On your question about designers and less technical folks using it, I'd say if the workflow and commands are very well documented, then with some training they should be able to get up to speed on it. Whether they'll appreciate it is a whole other question! :-)
One tool worth checking out is review board, it's a fantastic team code review tool and seems to have a git plugin.
Upvotes: 4
Reputation: 10825
Git is deep and can be tricky at first. I would say it's definitely not for everyone, particularly if you have designers or other non-technical folks needing to check in and out. On our current project we run an svn back end and three developers have chosen to use git while two continue to use svn and are perfectly content and productive.
That said, git has a lot to offer. Without getting too deep into git wizardry, you can quickly learn to take advantage of some of its most popular aspects: the ability to check in locally without pushing upstream to the main repo, and almost completely hassle-free branching and merging.
You can have a very satisfying git experience with a basic handful of commands.
Of all the resources out there, Scott Chacon's Getting Git is what sold me on the benefits of git and gave me the motivation to push through the steep part of the learning curve.
Upvotes: 8
Reputation: 5231
I just started using git a month back and love it. Its fast and easy to use for both teams and individuals. It isn't very hard to learn and I needed to learn no new technical skills to use git. I know that it supports migration from CVS/SVN. The best part is that you can still maintain a CVS/SVN style workflow should you want to.
I suggest looking at the git wiki:http://git.or.cz/gitwiki and official website:http://git-scm.com/
I hope this helps and you enjoy using git.
Upvotes: 3