It seems to me that Git was designed for large scale open source projects, with a high number of developers and teams.

I'm wondering if Git is worth it for smaller team (<10) and internal projects (within organisation). I understand that there is a clear performance benefit to having a local copy of the repository (although that's not quite as important when your repository inside your organisation...).

Would you still recommend Git (and the complexity that comes with it) and why ?

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

@Flimzy: I wouldn't say so because Git is really specific. “Should I use Git for small team project” and “Should I use version control” are different questions.
– Dan AbramovJul 4 '11 at 8:05

2

Seems like a factual, constructive question to me. Are there any features of git that make it inappropriate to small internal teams? If you don't know git, it would be very hard to answer this. You'd need to ask someone who does know git. Hey! We should make a web site for that!
– Charlie FlowersJul 5 '11 at 4:43

7 Answers
7

Git is not really that complex. And it is fantastically powerful and precise. I would not use anything else, for a one-person project or a 100,000-person project. I really mean it.

I see why people say it is complex, but that whole thing is overrated. To do everything you need to do, there are maybe 10 commands max you need to work with. And you don't need to understand every option of those 10 ... just a few cookbook-style "recipes".

What you do need to understand is a bit about how Git differs under-the-hood. But that's not because git is complex -- it's because Git is different. You can spend some time over the course of a day or two digging into that info, and you'll be good to go.

Pardon my crudeness, but Git makes the file system its b*tch. You can flip between "alternate realities" of your software project at will. Once you understand where the tool is coming from, you will have complete, almost god-like control over the bits and characters that comprise your software. There are few tools of such power available to software developers, period.

Yes, man, I recommend Git. Do it. You will be so glad you did. Good luck.

Git makes sense for both large and small teams. Yes, git is complex, but that doesn't mean that you always have to deal with that complexity. I use git everyday, and I rarely issue anything other than:

git branch # To remind myself what features I'm working on.
git checkout <name_of_branch> # To switch to whatever I want to work on.
git checkout -b <name_of_new_feature> # To start work on a new branch
git add <name_of_file> # To add it to the list of tracked files.
git commit -m <commit_message> # To checkpoint my work.
git merge <name_of_branch> # To integrate changes back to trunk.
git branch -d <name_of_branch> # To delete a branch after it has been merged.

There are really only a handful of commands you need to remember on a daily basis. For anything more complicated than that, you can always just look it up in the documentation.

One of the things I really love about git and why I would strongly recommend using it is that you can keep your work checkpointed and version controlled, even when it is not yet ready to be committed to the repository. For example, I might use "git commit" many times, locally, before actually showing it to other developers. This has greatly added to my confidence in making changes to code; I can experiment and not worry that my current work will be lost -- I can always revert to a safe version if something goes wrong. This cannot be said of SVN, for example, where any commits will be seen in the main repository.

What did you mean by "committed to the repository"? If Git has no central repository, what repository are you talking about? Git is confusing.
– Bruno SantosSep 26 '14 at 4:24

1

@BrunoSantos even though it is distributed, a project or organization will often have a single repository that reflects the true, official state of the code. Regardless, when I said "committed to the repository", what I meant -- in Git terms -- is that you can make local commits without having to push those changes to a remote repository (whether it is the official repository or some other remote) whereas in other version control mechanisms, you have to use a separate tool to handle local versioning of your changes.
– Michael Aaron SafyanSep 29 '14 at 8:36

setting up several repositories that accumulate different kinds of changes (useful for web projects);

it works via HTTP, SSH, whatever (never have to think how to connect);

once you get used to commit-until-good-then-push workflow, you can't really go back.

The benefits for a smart team are even more obvious:

one can work on a branch for weeks without worrying about having to fix 100 conflicts later;

distributed workflow makes even more sense and also integrates code review in your process.

However if your team is dumb (which may be true sometimes) or biased against Git, I strongly recommend against it because it takes certain effort and programmer curiosity to learn, and not everybody in the world wants to branch, merge, use distributed workflow or anything else Git has to offer, at all.

Even on my own I tend to use git, because of all it's useful features. Not having to hit the network (even en internal) for all but two operations (pushing and pulling) is a huge time saver in the long run. Things like checking out different branches just happens locally, just like reading the log.

Note that even when git is distributed, you can still have central repositories where everybody is pushing to and pulling from. But it is only a central repository by convention.

And the cheap creation of branches is also an advantage. You can easily make a topic branch where you implement some small feature, which you later merge again in the development branch.

Yes, because of how the change tracking works compared to svn. (There is simply less conflicts in large multistep merges.)

Yes, because that you can do small local commits while working and then push complete working changes to the main repository. When you do the push all of your tiny commits are pushed.

Yes, because when you do a pull from the main repository it doesn't merge immediately but rather puts the pulled stuff in branches. Perfect for when you do larger changes and want to delay the update some days on some computers.