One codebase tracked in revision control, many deploys
Our programs and websites, i.e. all code, are always tracked in a Version Control System (VCS), such as Git, Mercurial, or Subversion. A copy of the revision tracking database is known as a code repository, often shortened to code repo or just repo. A codebase is any single repo (in a centralized revision control system like Subversion), or any set of repos who share a root commit (in a decentralized revision control system like Git).
In layman’s terms this comes down to keeping track of the code including all the changes, versions, made by who and when. This gives us several abilities;
- To maintain versions, live, testing or development
- Keeping track who made changes and thus who and why
- Linking changes to issues
- Backups, every clone is a complete backup
Although there are dozens of version control systems on the market, some of the world’s most renowned projects (like the Linux Kernel, Ruby on Rails, or jQuery) are using Git as their VCS of choice. Here are some of the reasons why.
Git is lightning fast. And although we’re talking about only a few seconds per command, it quickly adds up in your work day. Use your time for something more useful than waiting for your version control system to get back to you.
What if you want to work while you’re on the move? With a centralized VCS like Subversion or CVS, you’re stranded if you’re not connected to the central repository. With Git, almost everything is possible simply on your local machine: make a commit, browse your project’s complete history, merge or create branches… Git let’s you decide where and when you want to work.
People make mistakes. A good thing about Git is that there’s a little “undo” command for almost every situation. Correct your last commit because you forgot to include that small change. Revert a whole commit because that feature isn’t necessary, anymore. And when the going gets tough you can even restore disappeared commits with the Reflog – because, behind the scenes, Git rarely really deletes something. This is peace of mind.
Git gives you the confidence that you can’t screw things up – and this is a great feeling. In Git, every clone of a project that one of your teammates might have on his local computer is a fully usable backup. Additionally, almost every action in Git only adds data (deleting is very rare). That means that losing data or breaking a repository beyond repair is really hard to do.
Don’t Mix Things Up
Separation of concerns is paramount to keeping track of things. While you’re working on feature A, nothing (and no-one) else should be affected by your unfinished code. What if it turns out the feature isn’t necessary anymore? Or if, after 10 commits, you notice that you took a completely wrong approach? Branching is the answer for these problems. And while other version control systems also know branches, Git is the first one to make it work as it should: fast & easy.
Go With the Flow
Only dead fish swim with the stream. And sometimes, clever developers do, too. Git is used by more and more well-known companies and Open Source projects: Ruby On Rails, jQuery, Perl, Debian, the Linux Kernel and many more. A large community often is an advantage by itself because an ecosystem evolves around the system. Lots of tutorials, tools, and services make Git even more attractive.
Git is only the protocol but it needs a central server to sync up all the different places and users, this is where GitLab comes in.
Keeping code indoors!
We prefer to run our own Git servers so we don’t have to place your on to big company servers like GitHub or BitBucket.
Multiple authentication Levels
Set permissions according to people’s role, rather than either read or write access to a repository. Don’t share the source code with people that only need access to the issue tracker.
Group level milestones
View all the issues for the milestone you’re currently working on across multiple projects.
Attachments in issues
In GitLab you can attach any file to any issue or comment.