Before we dive into Git and GitHub, let’s talk about how we typically manage versions of our work without using version control software.
Imagine you’re developing an app on your computer...
- First you create a folder for the project's files, your
working directorywhere you store all the files for your project. - You will likely be in the habit of implementing version control manually by saving a copy of your work frequently; For example, you might add a new feature, test it, and if successful save it again. If it fails then reload the previous version.
Bad practice can result in messy files & folders, like these mortal sins:
- Copying files into new folders:
- Using dates in filenames:
You start with one version...then make a copy...and another...and before you know it, you’ve got a folder full of files!
- Which one is the latest?
- What if you need to undo a change?
- Wait, I've realised I'm down a rabbit hole, I need to go back three steps - which file name was that again?
Have you ever done something like this with a project or an assignment?
It gets messy fast.
- As the application and codebase grows, and multiple developers may be working upon it independently, and each saving their own versions locally, then tracking them is difficult.
- If multiple people are editing the same file - whose version is the right one?
- Individual changes may not be brought together for testing the combined functionality very often, therefore when they are, and it inevitably fails, which of all of the new features is causing the bug(s)?
Without a structured way to track and merge updates, finding the source of a problem is like searching for a needle in a haystack!
We need version control!
As a solo developer, working on your own computer, you can probably implement a suitable system, as long as you keep it up. But what happens when you're working in an organisation, as part of a team.
This is where version and source control tools become invaluable.
Be aware that the terms 'source control' and 'version control' are often used interchangeably, however,
version controlis a general term which can be applied to any collection of files or documents, whereassource controlis specifically related to the source code for applications. This means that source control has specialist tools and processes which are very powerful, such as Git, but may not be of any use when it comes to tracking something like evolving legal documents, where 'version control' is what you require.
Source Control is the management and tracking of changes made to files and data, or more specifically, the code and assets which make up our applications and projects. It provides a logical way to record, track, visualize and alter all historic changes made to a document by all contributors.
Source control provides a complete long-term change history of every tracked file.Instead of manually saving multiple local copies, every change is automatically recorded, stored centrally, and can be accessed at any time.
Some more advantages include:
- Allowing teams to work concurrently, even on the same file, with features like
branchingandmergingused to avoid conflicts. - The ability to trace each change made to the software, and connect it to project management and bug tracking software tools.
- Clarity for developers, they should easily be able to find and work upon the correct branch of the code.
One more key advantage is the flexibility of source code management systems to inter-connect with other applications and tools, facilitating the automation of processes like testing, staging, and deployment. This is the basis of a CI/CD Pipeline.
A common example of version control can also be seen with familiar platforms such as Google Workspace.
Often slides or documents will be worked on by multiple people simultaneously, you may have done this already when creating presentations for team work tasks, each person can be making slides or editing at the same time.
- Let's say you're collaborating upon a huge document - such as a service contract, and following a bit of debate you decide a minor change to the working needs to be reverted.
- Maybe you want to see a history of changes to the contract, to identify every stakeholder who edited the document and made those changes?
Google Docs/Slides has a form of version control built-in to help with this.
The image below is of two colleagues working on a presentation, if I wanted to see what was changed last and when you can the rewind clock icon.
You'll see a list of versions, who changed the document, what was changed, and the date and time it was changed. You can see that Ant edited the document most recently on July 31, 2024 at 11:58AM. Jess last edited the slides on March 27, 2024 at 11:01AM.
In addition to these edits, you can also see a history of edits to the slides overtime by all contributors. If you click on a specific entry you will see all of the changes by scrolling through the slides, they'll usually be highlighted in purple.:
If someone is unhappy with an edit, for example Jess is not happy with Ant's edits (because she wants them to include Weasley and Noche, not Frankie and Scout), different versions can be restored by clicking the Restore this version button (circled red above).
The above example is essentially how version control works in Git too. Rather than relying upon manual processes, Git can track and access the different versions, show changes over time, and easily revert to any previous versions if necessary.
When working with code and a new feature causes your code to crash, rather than spending time bug-fixing, you can simply revert back to a new version and restore functionality in seconds.
..then you identify the person who added the feature, and give them an ear-full for pushing to
productionon a Friday afternoon - never push toprodon a Friday afternoon!!!.
Git is the most widely used source control system, and it solves all these problems efficiently.
- If you need to install git follow this guide
- If you have Git installed, learn more about it here