Wild Wonder S1 E1 — GIT setup

My name is Isaac, I’m currently a graduate software engineer at xDesign and welcome to my new series of writing I am calling Wild Wonders!

I have chosen to become a wizard for my first learning and development day, but not any wizard a GIT wizard!! I also want to share my learning by writing this and letting you learn along with me.

This course will let me learn many things but most of all confidence when using GIT. I want to also be that person you go to if your files and GIT session start to turn south.

GIT’ing started with (g)it! 💻

The start of the course is 7 sections of the basics of how to install and initialise a GIT repo.

GIT is a version control system (VCS), which means it keeps track of your files and changes. You can even leave a nice little message for yourself for each change you commit to so you don’t leave a trail of sticky notes to remember what you did. It also lets you make alternate realities where your changes are completely separated, then when you want to you can join it all back up!

Installation

To install GIT we will need a command line either from a terminal or your IDE. There are GUI options available such as GITKracken but for now, the CLI and your IDE are good enough. To begin run git --version to see if you have it installed already, If you get back a GIT version over 2 you’re good to go! Otherwise, download it from the GIT website or use your favourite flavour of packet manager. Now with this downloaded and installed, we should tell GIT who we are. Run the git config --list command and you can see your current config details. What we will be wanting to do is update/provide our email and name for GIT. (Also if you become stuck on this terminal screen don’t panic hit : & q and you should quit out fine). To give GIT our name run git config --global user.name “Your name here” adding in your name. And for email, it is git config --global user.email “Your email here”. When I set my details up I had done these commands back to back. Setting my name as Isaac Wildgit config — global blah blah blah… 😂 so don’t be like me and make sure to set each on its own!

Initialization

Initializing a GIT repo is easy once you are in your folder with your code pop open your terminal and use git init. You should see a lovely little message saying you have now initialized an empty Git repository 🎉 . Depending on your IDE you may also see your file’s changed colour. An untracked marker or indicator may show next to your file names and if you have a version control tab it’ll activate. You may also see your master/main branch name shown to you as well as this is the default name of your first branch.

Using Git Status

Status is a great way to keep a tab on what’s going on in your repo and get an update from GIT’s perspective! So if you are following along you can run git status and you should see a nice update of which branch you are on. Any commits you have made, in our case none, would also show any tracked and then untracked files under that. This means that GIT is not going to be tracking any of the changes made to these untracked files. For some files, you may not want GIT to follow these at all. If you have a secret.json file or build folders for your project we can have GIT forget about these by creating a .gitignore file. Within the file give the file names we want it to leave alone and GIT will forget they even exist. Once in here many IDE’s will show these files as untracked by either greying them out or removing the GIT marker from the file as well. You will also not see these files if you re-run the git status command.

Git add & staging

Add and Staging may be a little odd to get your head around but we’ll get there. Before we can tell GIT about all the changes made and to start tracking them we need to add the files into staging. Think of it like getting all the people at a party to get together ready for a picture but they’ll only be in the picture if you tell them. Well, that is what git add does! If you want everyone (excluding the files pointed to in the .gitignore file) you can use the command git add . This will add all your untracked files ready into staging, or for the photo analogy, it will get them all ready in front of the camera ready to get captured. Your IDE should show these in stage with an update to any indicators on the files. Don’t fret we can still make any and all changes before hitting the shutter button on the camera. If you want everyone to sit down and get all those files out of staging to start again you can run git reset . and all your files will go back to untracked again. You can also add a single file by doing the command git add <yourFilenameHere> so you can pick exactly who you want in staging ready to get tracked.

Git commit

Commitment doesn’t have to be scary, and it isn’t with GIT. Think of a GIT commit like a picture we took of all the files we got into staging. We would then sign the picture with a date and name so we could remember when it was and what happened. GIT does this for us and gives a unique identifier for each snapshot/commit. These are super useful so if we ever need to roll back due to a bug/issue it’s like stepping right back in time to that exact picture. It’s usually good to save and commit changes to your files as often. To do this use the command git commit -m “commit message” the -m flag in the commit is to add a message. For your first one, you may do git commit -m “initial comit” as a safe base to start with. You’ll want to try and keep these messages standardised. There are a few patterns you can use for your commit messages but as long as you stay consistent (especially as a team on a big project) it’s the dealer’s choice. I would recommend looking into the atomic commit style as it helps keep your GIT history nice and clean. After your commit you can run another git status to check your commit went through. You should see you have nothing new to commit and you’re on a clean working tree! You can look back at your commits with git log to see the name of the commit (remember GIT signs the photo for us). It will be unique and not human-friendly but you’ll see the Author, the date and your commit message. If you then make a change to a file your IDE should show this file as modified and then you can add and commit this change to your repo. It’s a small change and if you want to show off you can add all modified files and your commit message into one command! git commit -a -m “commit message” The -a flag here is doing the work of the git add . command we did earlier. Then we’re again adding a message to the commit so, hopefully, we can see how that is all combined into a single command here! You can also shorten it even more to git commit -am “commit message” and condense the -a -m flags together into a single -am . Again it all does the same so pick your flavour and enjoy!

This is the first section of the course I followed and my learning so far. I hope you have enjoyed and follow for the next part where I cover the remote powers of GIT!

Thank you for reading my first Wild Wonder! 💛