Manage Your File Versioning Like a Programmer With Git
Pinterest Stumbleupon Whatsapp
Advertisement

If you’ve ever worked with colleagues on a document, you know this pain: someone takes the first pass (document.doc), then emails it to everyone. The next person does the same, as does the third, each tacking a revision (document_rev3.doc) to the file’s name. The manager likes what she sees and tags it as complete (document_final.doc)… until last-minute changes come along (document_final_Aaron’s changes_reviewed_by_Bob_now_really_final.doc).

Now imagine changes like this in dozens of source code files. Programmers created version control systems (VCS) to solve this problem. They’re a bit technical in nature, but can be useful for power users as well. Let’s look at the basics of version control using the top system today, Git.

Overview of Version Control in Use

The primary purpose of VCSs is to capture versions (also called revisions) of a file over time. This means not relying on crude methods like the one described above. In these systems, when you access “document.doc” you’re working on the most recent version by default. But you can also go back into the file’s history and retrieve past versions. Systems built specifically to manage file versions began in software development, but have made their way into more “mainstream” applications as well.

The Evolution of Version Control in Software Development

Version control applications originally came about as a way to prevent programmers from breaking each others’ code. The first systems simply allowed users to lock files from other edits, while second-generation systems (such as Subversion How To Control WordPress Versions Using Subversion [Linux] How To Control WordPress Versions Using Subversion [Linux] Most of you probably already know that WordPress powers a large amount of websites that we look at every day. With the large userbase and support, you can do a lot of cool things with... Read More ) added full-project checkout from a central repository.

While these second-gen systems are still widely used, the industry is migrating towards third generation systems. The main characteristic of these systems is that they are distributed, meaning there is no central repository. Rather, each user has their own full copy of the repository (including all past revisions). But any changes (even full revisions) are “local” until he “pushes” them to another repository. That user can then pull a clone in order to make changes and repeat the process.

version control system flow

Current Version Control for Non-Programmers

The ability to capture multiple versions of the same thing is also a common feature for average users too Not Just For Coders: Top Version Control Systems For Writers Not Just For Coders: Top Version Control Systems For Writers The mention of version control or revision control makes it seem like something for geeks. You will be surprised to know that version control systems have their place not only in academic writing but in... Read More . With access to cheaper storage, both on the local machine and via easy-to-use cloud services, users now have the ability to track the history of their files. General-purpose programs do this in a number of ways.

Operating systems can capture a history of files or folders The Ultimate Windows 10 Data Backup Guide The Ultimate Windows 10 Data Backup Guide Windows 10 makes data backups effortless. We have summarized every native backup, restore, recovery, and repair option we could find on Windows 10. Use our simple tips and never despair over lost data again! Read More . This can happen automatically every time a file is saved, or on a regular schedule. Some desktop applications also let you capture versions or snapshots of files. For example, LibreOffice provides the “Save Version” feature (as shown in the top image below) that allows you to save multiple versions of the document in one file. Lastly, web/cloud applications such as Google Drive, ownCloud, etc. will also keep past iterations of a file or document (as shown for Google Docs in the bottom image below), either behind the scenes or at your express command.

version control system lo versions

version control system google docs versions

Why Use Programming-Centric Version Control Then?

Since all these options at the OS or application level already exist, why bother with these nerdy programmer tools? There are a couple of drawbacks to the above methods, including:

version control system dropbox history

If any or all of these issues make you want something more, check out the next section where we solve them with Git.

Version Control With Git

In the following sections we’ll go through each of these steps for a very important project: this very article. We’ll do so using the command line version of Git. Knowing the terminal commands will make it easy enough to find their GUI equivalents, and it’ll guarantee you can use it on every platform.

1. Setting Up the Git Repository

If your machine doesn’t have git installed (Macs do, as do some Linux distributions), you can either grab the Windows installer from the project’s download page or install on Linux with a command (specific to your distro) such as:

sudo apt install git

The next thing we need to do is set up a git repository, which is just a folder holding your project. To take advantage of Git versioning, you need to initialize the folder as a repository. You can do this at a command line with the following command:

git init

git init fileman

You may not see anything once this completes, but enable the “show hidden files” option in your file manager, and you’ll see there’s a new .git folder (as shown in the above image). This is where git keeps all its info so it’s out of your way.

2. Add and Commit Your First File

The next step is to create some content (files) in your project. These can be any type of file, as most programming projects are made up of code (text) and assets like graphics (binary) Everything You Need to Know About File Formats and Their Properties Everything You Need to Know About File Formats and Their Properties We use the word file interchangeably: music, image, spreadsheet, slideshow, and so on. But what makes a file a "file," anyway? Let's try and understand this fundamental part of computing. Read More . Once created, do the following at the command line while still in your project directory:

git status

git status

The first step to a commit is to “stage” the new or updated items. See how the above output lets you know there are “unstaged” changes? You can stage everything in your directory (recursively, i.e. to include sub-folders and their files) with this command:

git -a .

The “-a” flag is for “add,” and the period refers to the current directory. It’s basically saying “add all files to the my commit.” Now to actually make the commit, type the following:

git commit -m "WHOOP, my first commit!"

git add commit

Now when you check the status again, there should be no waiting changes. To see the commit itself, check the git log, using graph mode, with listing cut to one line, and decorated for readability:

git log --all --decorate --oneline --graph

git log

This will show you a nice timeline of your commit, with the most recent on top.

3. Create a Branch to Experiment

As you’re working, you may want to go off in a particular direction, not knowing if it’s going to work out. For this you’ll want to create a branch with the following command:

git branch experiment1
git checkout experiment1

git branch

The second command switches you to the “experiment1” branch. You can switch back by replacing it with “master.” As you start working on your text, note the difference between the same file from each branch. First, the “experiment1” branch with your new text:

git branch experiment1

Compare this to the original:

git branch master

Now after working for a while (ending with a new commit), the best you could come up with is “Lorem ipsum dolor sit amet…?” What is that? It’s nonsense, and should be stricken from your project immediately. You can trash your branch with the following command (“-D” for force delete):

git branch -D experiment1

git branch delete

Now start another branch and add something intelligent, along with some images:

git branch experiment2
git checkout experiment2 git add . git commit -m "More text, added images"

git add commit branch

4. Merge Your Changes

Finally, once you’re happy with the changes in your current branch the following command will merge them with the “master” branch. Provided you haven’t been doing a lot of hopping back and forth between the two, this will result in all your new changes being applied, and a new revision created. The following at the command-line will combine them for you:

git merge experiment2

git post merge

Now you’ll have a revision that combines the latest in “master” with the latest in “experiment2.” At this point you can get rid of the experiment (it was successful after all) with the following:

git branch -d experiment2

Note that you’ll only lose any of the incremental changes you made within that branch if you do so.

5. Push to a Safe Place

Lastly, Git is a distributed system, which means you can have multiple copies of your repository and sync them up. For example, create a new repository on a server you can SSH into How to Remotely Manage a Linux Server with SSH How to Remotely Manage a Linux Server with SSH SSH is very functional, which is why it's a go-to for remote server management. Learn how to remotely manage a Linux server via SSH, from connection, to installing software, and file transfers. Read More with this command:

git init --bare

The “–bare” flag sets it up as a sort of read-only repository, in that you can’t modify the files directly. Then you can set that as a remote copy of your local repository with the following (the first command ensures new local branches are created remotely):

git config push.default matching
git remote add central ssh://[username]@[URL]/path/to/repository git push --set-upstream central master

git remote

Set Up for Versioning and Backup With Git

With the above setup, you can follow a simple process to keep all the work you do on a project not only versioned, but backed up as well.

  1. Make changes to project files.
  2. Issue “git add .” to add all changes to a commit.
  3. Issue “git commit -m [some message]” to commit the changes to your local repository. Repeat from the start.
  4. Issue “git push” to commit the changes to a remote repository at regular intervals.
  5. Issue “git clone ssh://[username]@[URL]/path/to/repository” from some other machine to

Do the benefits of version control systems something that interests you? Or are the non-development backup applications enough for your needs? Let us know your thoughts in the comments below!

Leave a Reply

Your email address will not be published. Required fields are marked *

  1. Leland Kwong
    August 28, 2017 at 7:16 am

    I like the sentiment behind this article, but I can't honestly expect any of my non-programmer friends / family to start using the command line. What we really need are better GUI tools for non-programmers, something like a git-tower for documents.

    • Aaron Peters
      August 28, 2017 at 3:49 pm

      Hi Leland,

      For casual users I agree, although for power users who aren't developers I'd argue that VCS clients integrated with file managers, like the KDE Dolphin screencap I show above, would be all they need. What would help is to replace dev-speak like "commit" or "branch" with more user-friendly words like "take a snapshot" or "create a different version" (if they bother with branches at all).

  2. thatlaxguy
    August 25, 2017 at 11:49 pm

    What is the theme that you are using in those screenshots?

    • Aaron Peters
      August 26, 2017 at 4:42 am

      It's the default Konsole theme that's shipped with KDE Neon... which is the standard one for most distros I think.