Table of Contents
GIT for version control. It's not as confusing or as crazy as it seems. We just pretend it is that way we get paid more.
This post is just a way to break explain the different terms but also to give an idea of a simple easy and handy work flow for using GIT and getting the benefits.
You can get GIT here
Wait! What is GIT
Git is a distributed version-control system for tracking changes in source code during software development. It is designed for coordinating work among programmers or as a solo developer just keeping track of what I am doing.
Every developer should be using some Version control. GIT is just one option that is very popular (at the time of writing)
Changes are you have come across one of the following:
These are hosted sites that offer public / private repositories for storing your code.
I'm not going to go into too much about this part you have plenty of options and they are all fine and will likely do what you want.
What does everything mean
So first off lets start with a crash course in what some of the basic terms mean and what they do because once you have a handle on that the rest is actually really easy.
Term | What it means |
---|---|
Repository | A repository is simply a place where the history of your work is stored. It often lives in a .git subdirectory of your working copy - a copy of the most recent state of the files you're working on. |
Commit | A commit is when you send the changes you are working on into the local repository. So it's simply the first step. After you make some changes you commit them into the repository so a record can be kept of your changes. |
Push | A PUSH takes the changes you have on the local repository (that you have committed) and puts them into a remote repository. This can be online or on another machine on your network. |
Branch | A Branch is when you create another track. All repositories have a default "Master" branch. But you can create another branch if you want for say "Development" or "testing" A branch lives alongside the other branches in the repository. |
Fork | A fork is like a branch but it lives in a different repository. |
Pull Request | When you have code in a branch or fork and want to send it back to the master or another branch you make a pull request. This will allow the owner of the repository to review your changes and then merge them into the branch. |
Merge | A merge is when you take code from two different sources. This could be a pull request or reverting and then merges the changes together to make a new file. GIT gives you the tools to make this really good, you can decide which is the main and then it will take the changes into it. |
Clone | A Clone command is how GIT copies a repository from a remote to your local machine. |
Simple developer flow
So you want to use GIT for version control first thing we do is setup our folder as a GIT repository. That's all a repository is at the end of the day a folder.
So a simple flow I like to use alot is to create a repository out of my project.
From the command line all you have to do is git init
C:\newproject\git init
This will create a GIT repository in that project.
You can also use Githubs Desktop app
Your editor of chose should have a git plugin that as you make changes will allow you to commit your code changes to the repository.
And there you have it very simple but that's version control right there.
- Create a local repository
- Make changes and work
- Commit to the local repository
Going Remote
Now that's just a very simple and local version control but if you want to push those changes into a remote repository it's just 1 extra step.
PUSH
This is the command to push changes from the command line.
git remote add origin [email protected]:projects/app1.git
git push origin master
git remote add origin this allows us to set the remote repository we want to push our changes back to. (To use this command from command line it needs to exist first)
A simpler way if your using Github is Github desktop, "Publish repository". This will create a private or public repository on github and do all the hard work.
Most editors will have GIT integration.
And that's it we have now got a flow that allows us to
- Create a local repository
- Make changes and work
- Commit to the local repository
- PUSH to a remote repository
That's a simple productive flow that gives you a huge amount of the benefits of using GIT for version control.
Summary
I've covered the more common terms here and put down a simple flow for using GIT for version control and I've kept it really simple. But this flow can get you up and running and using something that can really help you. There is no need to over complicate it or to go too far too soon.
As a developer I've used alot of different Version control systems down the years, VSS, Subversion, Mercurial and now GIT.
One great thing about GIT is the tooling we have available you do not have to use the command line all the time you can use the tooling to make it really easy to use.
As with most technology as you get more comfortable you can go further and more.