Does using Git make sense for small internal teams? [closed]

Question

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 ?

Answer 1

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.

Answer 2

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.