Programmers that need a good source code repository and versioning system.
Expected Knowledge Level:
Beginner through Advanced. You do not necessarily have to have experience with other version control systems, but it helps, of course. Your knowledge of programming is of minimal importance to this article. But if you’re reading this, you’re most likely a programmer, and that’s all that really matters.
Purpose of this article:
To give you a head start with Git. This is not a complete tutorial. This will give you critical pieces of information that are usually lacking in other documentation that experienced GIT users forget that non Git users don’t already know.
What IS Git?
Git is a source code repository and versioning system. It’s free and open source. It lets you keep track of your source code projects, have them backed up on zero or more remote storage locations, share your source code (if you want), keep track of versions of your source code, branch from your source code to work on special features without interfering with the main branch, merge branches together, provide opportunities to review source before merging it back into an important branch (for teams), allows teams of programmers to easily work on the same project without undue burdens of coordination and synchronization.
What Problems is GIT a Solution For? (Why GIT?)
First, let’s answer what version control systems, in general, solve, not just GIT:
- Provides a backup for your source code.
- Allows collaboration with other programmers.
- Allows keeping track of versions of your source.
- Allows branching and/or forking of your source to work on specific features or bugs or experimental releases without contaminating the main source branch.
- Replication of your source for safety.
- Many other reasons.
So, why GIT in particular? I’m not an advocate for GIT in particular. I like it and I use it. What’s important is that you’re using a modern source code control system and have policies in place to prevent problems and provide standardized solutions. GIT is one of many solutions. However, GIT has risen in popularity and seems to be the defacto go-to source control software these days. And there’s good reason for that. It was created by Linus Torvalds (the creator of Linux) and is actively maintained. GitHub.com, arguably the most popular source code repo on the planet is based on GIT. And like most source control systems, GIT is multi-platform.
Again, I’m not advocating for GIT. I’m writing a quick-start guide with a little bit of background. I’ve written plenty of articles on subversion too. Note also that Mercurial is a Git derivitive, so pretty much everything I cover here applies to Mercurial as well.
Things You Need to Know:
GIT is not easy to get started with if you’re not familiar with it, and by definition, if you’re getting started with it, you’re NOT familiar with it. For one: GIT is not a single product. Since it’s open source, there are MANY products that are GIT compatible and you have options for command line, GUI, embedded into your favorites IDE or source editors, plus multiple server options as well.
- “Repo”: A managed database of a source code project. Unlike other source control solutions like Subversion, where a “repo” is a centralized database where you store all your projects, in GIT, a “repo” is where you store ONE source code project. For example, say you’re writing a game. You’d have a dedicated repo just for that game. On your local machine, you’ll have a complete repo folder named “.get” inside your primary source code folder.
“Project”: A centralized server can host multiple software projects. Each project is generally set up for a single software application being worked on by programmers. Programmers will “clone” or “check out” the project to their local machine, creating a local “repo”.
- “Check Out”: The process of retrieving source code from a branch in a repo. That repo could be a remote repo or your local repo.
- “Clone”: Pretty much the same thing as “Check Out”. In other source code providers, “checking out” a project informs the server that you have it checked out. In GIT, the server is never aware of who has what and doesn’t care and doesn’t need to know. You’ll simply “clone” the project to get a local copy of the database and work on it locally, committing locally, then eventually push your changes back up.
- “Check in”: This is not a term used in the world of GIT.
- “Commit”: The act of submitting your local source code edits into your local repository.
- “Push”: The act of sending all of your commits from one of your local repositories up to a remote server. If someone else committed and pushed code in on any of the same files you worked on, chances are you’ll have a conflict and will be forced to perform a merge.
- “Merge”: The act of you being presented with two conflicting versions of the same source file. You’ll be asked to pick and choose which differing lines from both versions should be merged into a single file version before committing.
- “Pull”: The act of you pulling down the latest changes from a remote repository into your local one. Note that “pull” is in the direction of the machine in which the code is moving to. Whoever triggers a pull, does so from the location of the machine in which the code moves to. For example you “pull” from the server to your local machine. You log onto the server’s web interface and request a “pull request” to move your code into the central repository.
- “Pull Request”: The act of a programmer requesting that their committed and pushed changes be merged with a more important branch. One or more other programmers (frequently the project lead) will review your changes and decided whether or not to allow them to become part of the bigger project. You may be asked to make some minor changes and re-submit your pull request or it may be rejected out-right.
Unlike Subversion and the much older Microsoft Visual SourceSafe, you don’t have 1 server and multiple clients. Instead, GIT has no “real” central server. Though most people use it in a way that sets up one repo as the understood central repo.
You don’t simply check out from the server, edit, then check back in. Instead, your local machine, itself, becomes a server. You become a client to your own server. So, when you check out and commit your code, you’re doing it from and to your local repository. At any time, you can push all your commits from your local repo up to another repo. You can “pull” from a remote repo to yours to get yours up to date.
But while writing code, you’ll create branches locally in your own repo, then checkout from those local branches, edit, commit. You may do this many times. Eventually, you’ll want to push your changes up to the shared repo.
If you’ve ever tried branching in things like subversion, you’re probably aware of how difficult it is and how easy it is to screw things up badly.
SUBVERSION BRANCH: HOW TO
In GIT, it becomes ridiculously easy. It’s so easy, in fact, that branching will become your common, every day practice. Everything you do… every feature you add, every bug you fix, will be done in a branch.
In all fairness though, it’s still hard if you’re not using the right tools. If you’re a command-line junky (which I do not recommend, nor should anyone be impressed by someone insisting on sticking with the command-line), you can implement best-practices like GitFlow. Better yet, are plugins for GitFlow that are made for Visual Studio, GitKraken, and many other Git clients. This removes the complexity of branching and merging down to a couple of clicks and removes the human error component, making your workflow incredibly powerful and easy at the same time.
Make your life much less complicated. Start using the GitFlow best practice. Just because GIT supports branching, doesn’t mean that everyone’s going to do it the same, nor that everyone’s doing it “good”. What’s your policy on how code moves from developers to production? There are just about an infinite amount of hodge-podge plans using GIT to make that happen. GitFlow is a standardized way of doing it. In short (very short) explanation, here it is:
- When you create your project, you create a “main” or “master” branch. The becomes the gold standard for finished, polished code. You will most likely build what’s in there and publish it.
- Create a branch off of “master” called “develop”. This will be the main, working branch where programmers will branch from and merge back into. This isn’t necessarily the “best” version of the code, but it’ll be the “latest” version that all developers use as their developing silver standard.
- If you are tasked with fixing a bug or creating a new feature, you’ll create a new branch derived from the develop branch. You’ll work on your fix or feature until done, then merge it back into develop.
- Some coding shops like to have a “bug fixes” branch, a “features” branch, and “hot fixes” branch from the develop branch. Then the developers never branch directly from the “develop” branch. They’ll instead branch from one of those 3 branches.
Making this happen is a chore if you don’t have tools that are designed for this and you are likely to introduce big mistakes without using GitFlow tools. If you’re using Microsoft Visual Studio, go to the Extensions and search for GitFlow. Install that, then you can very very easily automatically create, pull, and work on a feature or bug or hot fix branch. Then when you’re done, you simply click “finish” and it’ll do all the committing, pushing, and merging for you (except for the merging where human intervention is required). Your F-Up rate will greatly decline and your co-workers will appreciate it!
If you’re using GitKraken, there’s a plugin for GitFlow there too. You can use both Visual Studio’s GitFlow and GitKraken’s GitFlow interchangeably, at the same time, on the same project.
No joke! Go get GitFlow now!
- The base GIT software: https://git-scm.com/downloads
- GIT Bash
- Git Clients
- Git GUIs
- Inside Microsoft Visual Studio
- VS directly supports GIT
- Install the GitFlow extension.
- Android Studio
- Stand-Alone clients
- Git Bash
- GIT Servers
Thank you for sharing this article. See this image?
You’ll find actual working versions of them at the top and bottom of this article. Please click the appropriate buttons in it to let your friends know about this article.