Git VCS && Watch Tenet
I've recently started collaborating with friends through GitHub and I've forgotten a lot of the basics of Git! Using VCS is an absolute must in the industry so I decided to write this tutorial. I'll be going through some of the basics: setting up repos, pushing, pulling, using branches, merging conflicts, etc. I'll also be throwing in some analogies to Christopher Nolan's new mind-bending sci-fi film Tenet, there are a surprising number of similarities between version control software and closed-loop time travel. 
Git VS GitHub
If you're not familiar with the two, they might seem like more or less the same thing, but this could not be further from the truth. Git is a tool that takes snapshots of different saved states of files (they can be source code, documents, or even images). GitHub is a hosting service that allows people to upload these snapshots to a remote server (that way you can have backups of these states, share them with others, and use other nifty features the website offers). There are other hosting services such as GitLab, BitBucket, SourceForge, etc. There are also alternatives to Git: Mercurial and Bazaar. I've never used them and I don't know what advantages they might hold over Git. Let me know what you have used in the past.
The History of VCS
Version control software has been around for decades. It has gone through a few big changes; the most notable being:
- Only one person can edit a file at a time
- Users must merge with the server before committing their changes
- Users have their own local version of changes and can work offline, uploading their 'snapshots' at their pleasure
Distributed version control software or #3 is what I am most familiar with, but plenty of people/companies are still working with #2 or centralized VCS. There are pros and cons to each. Check out this article to learn more Centralized vs Distrubuted Version Control Software
Repositories
Using the VCS host of your choice (BitBucket, GitHub, etc.) create a repo. This is where your project and it's different versions will live online. Like I said before, you can keep track of any type of file and the changes you make to it. After you set up the remote repository you will need to initialize a local repo on your computer and connect it to the remote repo.
# navigate to or create the directory your project is located and run these commands in your terminal
$ git init
$ git add .
$ git commit -m 'initial commit'
$ git branch -M main
$ git remote add origin git@github.com:SamG-H/practice.git
$ git push -u origin main
With these commands you have successfully initialized a local repository, made your first commit (saved a snapshot of your project), linked your remote repo to your local one, and pushed your local commit to your remote repository. Whew! A productive day already!
Commits
The power of VCS are in the commits. Commits are the snapshots to which I keep referring. They save every bit of information in your project and keep track of any changes made since the last commit. You accidentally delete that crucial function call and destroy your latest and greatest application. With Git you can go back in time through commits and make it like it never happened. To take full advantage of this powerful but simple tool you must commit, and you must commit often! It makes all the difference.
Reset
With the command git log we can see all of our commits. Add the --oneline option for a condensed log. Now with this information we can see the commit values, some sort of hexadecimal value like 5276ff3. Using this value we can turn back the clock and return to a simpler time when our application worked. All we need to do is git reset 5276ff3 replacing the commit value with whatever commit you want to go back to. This does not reset anything permanently on its own! All that has happened is your project and its files are back to the way they were when you committed (5276ff3). You can easily go back to your most recent commit by git reset-ting to whatever your most recent commit value was. WARNING: If you commit after resetting to a previous commit you will have undone all the commits inbetween.
Revert
Something to keep in mind with resetting is that it can become very challenging for coworkers to deal with merging their changes if someone resets and pushes that reset to the remote repo. So before resetting consider reverting. Similar to a reset, revert instead makes a commit that resets the project back to a specified commit. Confused yet? So was I while watching Tenet. Time travel right? Just know reverting does not destroy any commits, it simply creates a new commit that reflects a reset. This gives you and your team more flexibility (more commits) in the long run.
The Journey
Just like I needed to watch Tenet more then once to better understand and appreciate it, you will need to experiment with these commands to get comfortable taking full advantage of Git! We have just scratched the surface and I haven't even made that many references to Nolan's latest gem. We will continue next week!
Top comments (0)