Version Control with Git

owlmanatt

Programmer
## Introduction
Version control is the practice of keeping every revision of your source code. Using version control software will allow you to see changes over time and retrieve earlier versions of files.

I'm sure that, before updating something, you've created a something_important.php.bk file that you can quickly restore. Version control allows you to manage this a little bit better -- we'll track every file and every change. If you create a bug and don't notice it for a few weeks, you can go back in time and retrieve an older copy of your code.

This tutorial will explain how to set up SmartGit and create/use a git repository. We won't be using any 3rd party services like Github, Gitlab, or Bitbucket -- instead, our git 'server' will simply be a folder on your computer. Your code won't leave your hard drive.

SmartGit is a graphical interface for managing a git repository. SmartGit is not the only option, though -- you can also check out GitKraken or SouceTree. I do not recommend the GUI that git itself ships with; it's a bit complicated for folks that are new to version control.

I'll include some information about the other things you can do with git at the end of this guide. We're going over a very basic use-case, but it's also a powerful tool for collaborating with other developers.

## Setting Up
Firstly, go and grab SmartGit -- it's free for non-commercial use. Once installed, it'll go right into the setup process.

On the 'User Information' screen, feed in a name and email address. These are used when you 'commit' code to the repository -- it puts you down as the author of the changes. The other settings can be left as-is. Particularly, you want to leave 'Hosting Providers' set to "Don't configure a hosting provider for now" -- we don't want to publish the repository as an open-source project.

After you've finished the setup screen, you'll get another popup asking what you want to do:

opfWgFV.png.fda549d31b3527f9eb35b4ccf046bf1f.png


Select the first option, 'Add blabla OR create a new repository'. This will allow us to initialize git.

On the next screen, navigate to the directory with your source code, select it, and hit OK. The next popup will ask you if you want to initialize or cancel -- hit 'initialize':

CSFrYhP.png.535ee311fd3d795f2fe6c64ab2c86903.png


Initializing a new git repository here won't modify any of your files -- it will just add a folder called '.git'. And, of course, if you don't have any code yet, you can just make a new directory and initialize there -- as soon as you've written some code, you can have git keep track of it!

## Committing Files
Initial setup done, you'll be greeted with a screen showing you all of the files in the folder. You'll notice the 'State' column says 'Untracked' for all of your files. There are a few states things can be in:

- Untracked: git isn't keeping track of changes to this file (yet)
- Modified: git tracks the file, but you've recently made changes that git has not added to its history for the file
- Deleted: you've deleted a file git was tracking
- Staged: by selecting a file & clicking 'Stage', you've queue it up for committing

In order for git to do version control on a file, you have to instruct it to track that file. Similarly, whenever you've finished making changes to a file, you have to tell git that the new copy is ready to be added to the repository. Both of these things are accomplished by 'committing' your changes.

Click on the 'Commit' button up top and we can get the current versions of these files tracked. You'll get a popup with all of the files. First, check off what you want to commit, then type in a 'commit message' -- this is a little note about what/why you changed things. The message will show up in the history, making it easier to find a certain change if you ever have to refer back to it.

f7VHG8V.png.537854fe4833b9756c398e5749901051.png


After committing the files, you'll notice they disappear from SmartSVN's file list. Don't worry; your files haven't gone anywhere. The reason they've disappeared is because git's current version of the file matches what's on your computer -- it only shows files that you might want to commit.

Go and make a change to one of the files you committed. It can be as simple as changing one letter. It'll reappear in the list with the state 'Modified'. If you click on a 'Modified' file, the pane in the middle will show you the differences (or 'diff') between git's version and your new version. Every single line of code you've changed will be highlighted for you, so you'll know exactly what changes were made.

Just as before, you can click 'Commit' to submit the new file to git. Note that if you've got file(s) seletced in the main SmartSVN window, clicking commit will limit it to just those files -- un-highlight them if you want the full list of files in the 'Commit' popup.

From now on, you'll need to remember to commit your changes. It should only take a few moments, but since it's a new habit you have to get into, it might be useful to put a post-it on your monitor reminding you to commit your changes!

## Looking at History
You can look at the diffs for every commit by hitting the 'Log' button. If it's greyed out, click your repository on the left-most pane first.

In the log window, you can see the changes files & their diffs. For the most part, this is probably enough information for you to revert.

However, maybe you don't quite recall when you last changed a file, and you need to look at what the code was like last month. In this case, it would be useful to look at just the log for that file. To do this, press ctrl+1, or click on the white page icon to the right of the 'File Filter'.

Your SmartGit view is now showing you all of the files in your project. Find the one you want to see the history of, right click, and view the log.

## Conclusion
You've now got an idea how to keep track of your changes with git, congratulations!

The setup & process described by this guide is very simple -- you're tracking your own changes, one by one, in a nice neat line. Git is capable of a lot more than this. You can do things like:

- Branch. You can create independent copies of your code to work on. Say you want to start a big project that'll involve updating lots of files. You expect it'll take a month. You could create a branch in git for the new feature & commit changes there. In the mean time, if you need to fix a bug on the live version of your site, you could swap back to your 'master' branch -- it won't have any changes for your new feature yet -- and fix it there. Once you're done with the feature, you'd 'merge' that branch into master and update your site.
- Collaborate. Git allows you to sync your code up with other developers. Services like Github make this even easier with features like pull requests.

Here are some newbie guides that go into more detail than the one simple use-case we've covered.

  1. https://www.atlassian.com/git
  2. http://rogerdudler.github.io/git-guide/
  3. https://help.github.com/articles/git-and-github-learning-resources/
And, finally, you don't have to use git to manage just your code. You can version documents (which is what I did for the screenshots here) or images too!

 
Nice introduction! Should be  a good starting point for people who haven't used version control yet which is definitely recommend for any project that is meant to last longer than a day. :)

 
Another good reason to learn version control is that you have the eventual ability to be able to roll out your code to multiple servers should something take off. The tools are numerous that will deploy from git.

Overall, no matter the project, git repos provide a great storage place for your code and assets, while keeping versioning and history :)

Great write up @owlmanatt!

 
Is it possible to make a tutorial on version control with other free Git software? SmartGit is only free for non-commercial use, and you would have to buy a license to use it if your site ever makes any kind of profit (to avoid termination).

 
I've experimented with using version control recently in the event I bring in another developer to help with coding. The problem I have with using version control is just the fact that if I make a change with the file, I have to save it, commit it, and then push it to the repo for the live website to show the changes. It seems like a really tedious process especially if you have to trial-and-error the code. 

From what I can tell, the solution to this is to have a local server that you can run the scripts on. However, when a script requires the database to connect to, you'd either have to have a local database copy (gotta make sure it's up-to-date) or open MySQL's port and connect remotely. 

I just feel like it's too much hassle just to keep up with version control as compared to the benefits, unless you're a rather large sized project. 

 
Live editing on the server is asking for problems anyway unless you don't care about introducing errors to your production server. For small not as often visited sites probably not a bit deal, but if you have something that players or people are actually using that is something to avoid.

Even if you are able to write perfect code every time (impossible), some features take longer and so are broken during the process. Actually I can't think of many that would not have this issue except very minor edits. Definitely not something I would personally want to have as I want everything working as much as possible on production. My perspective might be different since I have a live games that are businesses. But they are definitely small business, though mid sized projects. 

I personally think version control is only not useful it the project is really small though. But yes there is that initially overhead and learning curve and I personally find git to be a pain. Basics are okay, but it just doesn't always feel intuitive to me once you are dealing with merge conflicts and branching.

As for setting up a local server, there is a bit more setup initially. But I think it's good to have the basic idea anyway myself. For the database there are options to keep your structure in sync, and the data isn't that important to match as long as the base non changing much data is the same (breed base stats as an example). Doesn't hurt to sync up every once in a while, but in general what does it matter if there are x users on production and y locally? 

 
From what I can tell, the solution to this is to have a local server that you can run the scripts on. However, when a script requires the database to connect to, you'd either have to have a local database copy (gotta make sure it's up-to-date) or open MySQL's port and connect remotely. 

I just feel like it's too much hassle just to keep up with version control as compared to the benefits, unless you're a rather large sized project. 
That is the process, you should be doing all your development removed from the production site. It may seem like a lot more work, and initially it probably is. The first time you catch yourself before a bug gets to your live site, it will be worth it. The process has almost become second nature to me.

As for keeping a local database, it doesn't have to be completely up to date. I would argue it shouldn't be. The point of the local database is to allow you to test several different data possibilities and catch those things that should never happen but will.

As a single person, you can argue that it isn't necessary, and nothing keeps you from not using it. I like to use it because it allows me to keep a historical timeline of what I am doing. I can always reference where I was last commit, and go from there. It is also a cheap file backup, or in my case, allows me to work on my code bases across the several computers I use.

These are just my two cents.

 
Visual Studio Code has really good git integration if anyone is interested in a decent, but light IDE: https://code.visualstudio.com

Personally I'm using VS Code and I have Windows Subsystem for Linux setup with some custom scripts and $DISPLAY set to forward windows to Xming. So I get to use gnome-terminal and linux commands right from the comfort of windows. One of which is proper `git` binaries. :D

 
Last edited by a moderator:
Back
Top