We started this series with a quick introduction to code reviews, and now we are extending the analogy and applying it to one of the most important tools of our trade: Git. It’s a revolutionary technology that entirely changed the field when it came to be in 2005, and we are going to explain how it works.
Think of a book.
How many authors does a book have? One, you say? Not necessarily. Every kind of book, from fiction to non-fiction, from serious journalistic inquiries to the most commercial of novels, can have several authors.
Let us tell you how collaborating on a book usually happens, and you will understand how Git works.
1. You are writing as a team
Let’s say you are writing a book and you have a co-author. Now, in the before-times, when the Internet wasn’t a key part of everything we do, you would probably write down your bit, they would write down theirs, and you would need to either meet physically or exchange documents somehow (mail, a delivery man, etc.) to be able to compare and contrast versions.
This has a number of problems.
You can’t work on the same section at the same time, for one. If you want to both work on the same section, one of the writers will have to combine the different documents.
What happens if an author wants to make a change to a chapter that is already written? What happens if an author makes a lot of changes, and the others dislike it and want to go back to the old text?
Writing code as a team had many of the same challenges before Git came along. Git is a VCS, or Version Control System.
2. A good VCS changes everything
Contemporary writers have Dropbox, Google Docs, and other tools that allow for synchronous work. No one really exchanges paper manuscripts anymore because computers and the Internet make life significantly easier.
These tools use one form or another of a VCS much like Git.
If a team of writers is writing their manuscript on, say, Google Docs, they can do a number of things that were impossible in the past, such as:
- All writers can collaborate on the same document at the same time;
- The main version of the book will always be up-to-date, regardless of changes;
- Past versions can be accessed easily;
There are plenty of VCSs out there that facilitate development, but Git is definitely the most popular, and it allows developers to do all of these exact same things. The most popular Code Hosting companies using Git are GitHub, GitLab, and BitBucket. Yes, Git and GitHub are not the same thing.
3. Keeping track of every line written
When you’re an author working on a book, you are going to take great care with the wording and every choice made. This is every bit as true even if you have co-authors.
This is why modern VCSs such as Google Docs (which is more than a little bit inspired by VCSs) have a number of features that allow you to keep track of what’s happening while you and everyone else works.
You can, for instance:
- Download and upload up-to-date versions of the book;
- Create alternate/temporary versions of the book which you can share with the other authors;
- Join temporary versions with the main one;
- Easily deal with new chapters added while other writers worked on other parts of the book;
- Go back to older versions in case something was deleted or lost;
But what if a writer particularly likes or dislikes a specific line, section, or chapter, and wants to know who wrote it?
You can do that too.
When VCSs came up with the ability to identify the author of every single line of code, this changed things. Now it’s normal.
Most of the things we’ve listed are taken for granted. They seem like the basic features of any online text editor. Every single one of these features was introduced or made mainstream by Git, though, and every single one was hailed as the key innovation they truly were.
So now, as a way to break this little analogy we’ve built, here’s some Git terminology and what it compares to:
| Writing a book in a team with a VCS | Writing code in a team with Git |
|---|---|
| Book | Code Project |
| Book Section or Chapter | Project Folder or File |
| Main version of the book | Main branch, or Head |
| Download the book for the first time | Check out the project – git checkout
|
| Update the book to the latest version | Pull changes, or Fetch changes – git pull / git fetch
|
| Temporary version to try new ideas | Branch – git branch
|
| Request to join temporary version to the main | Pull request, or Merge request – git request-pull
|
| Join temporary version to the main | Merge branches, or pull changes to Main branch – git merge / git pull / git fetch
|
| Save changes on the computer | Commit changes – git commit
|
| Upload changes to the team server | Push changes – git push
|
| Find who wrote a line of text | git blame |
We hope you enjoyed this little foray into Git, and please let us know what topics we can explain next in this “For Dummies” series in the comments or on Twitter (@reviewpad)!
Top comments (0)