This is the first in a series of articles to explain Git and GitHub in an easier-to-understand manner. This is the next article in this series. If you’re in a hurry to get to the meat of this article, you can skip the preamble.
Over the past 2 years or so, I’ve been actively involved in helping dozens of folks get started in Programming; from organized trainings to post-meetup/event follow-ups. I’ve often had to take out time to explain to many of these ones how to setup Git and get started with GitHub. You see, so many “git getting started” articles I’ve seen seem to complicate things for newbies. So I can’t just direct them to an article and say, go read that and you’ll be good.
I recently had to explain Git and GitHub to someone and thought, why not put this into an article that I can always refer others to. Anyways… here we are!
Git? Is that another name for GitHub?
Git is a software that helps you keep track of changes to files in a folder on your PC. After making some changes to files in this folder, you can “commit” the changes to Git for safe-keeping. These changes could be creating, renaming, deleting a file or subfolder; or editing the content of a file.
You can also share this folder you’re “git-tracking” with others (via a local computer network, for example) and they can also make changes to files in the folder and “commit” their changes into the mighty hands of Git for safe-keeping.
Then, you can turn back the hands of time whenever you need to and view the content of those files as they were at that time in the past. God forbid one of the friends you shared your files with messed things up for you! Oh wait, it was you and not your friend that messed things up! Oh well, we have Git, don’t we?
Yeah, that’s about it for Git for today. If you want to learn more, you can read about Git on Wikipedia.
Getting Started with Git
We did say Git is a software, so go ahead and grab the executable file for your Operating System, install it and come back here to continue gisting with me. Don’t worry, I’ll wait. I’m patient.
Installed Git? Awesome! Nope? Err, I really recommend you follow each step religiously so you don’t confuse yourself or me. Thanks for understanding.
If you have Git installed, open terminal (if you’re using Linux or Mac) or command prompt (if using Windows). Please keep your terminal open, we’ll be using it for a while…
Now let’s tell git 1 or 2 things about you — your name and email really. Git needs those info so it can confidently tie your identity to any commits you make; and then when someone comes asking, who made those changes?, Git can say, oh it was this guy or that lady. Ready to introduce yourself to Git? You’d only have to do it this one time. Punch the following TWO instructions into your terminal/command prompt:
git config --global user.name “Your Name Comes Here”
git config --global user.email firstname.lastname@example.org
Done that? Aren’t you just nice! Alright, let’s do what we came here to do — tell Git to track that folder that houses our project files. We need to get the path to that our project folder. Sorry, won’t tell you how to do that. But once you have it, send the following command into your terminal/command prompt:
You guessed right, that command changes the working directory of your terminal/command prompt to your project directory. Done?
Okay, command Git to track this folder/directory we just navigated to and watch for file/subfolder changes. Doing so officially turns your project directory into a local git repository. In a subsequent article, we’ll look at how to connect this repository to an online/cloud/remote repository. What is a repository you say? Ask Google!
Use the following command to convert your project folder into a local git repository:
Yay!!! Git is now watching our project folder for changes. But we ain’t done just yet. It is true that Git can now tell us when there’s a change to this folder, but it doesn’t save the changes to the git repository automatically. Git is smart, you know. It knows that some file changes are just plain irrelevant and need not be saved. So the onus is on us to tell Git when we’ve made a relevant change and then Git will save the changes to its history bank (the repository). If we don’t tell Git, Git won’t save nothing.
Before we learn how to instruct Git to save changes, it’s worth pointing out at this time, that you can continue working on your project files. Use your IDE, code editor, file manager or what-have-you to make changes to the files and subfolders in your project directory. When you’ve made important changes, remember to save (or commit) them. We’ll talk about how to do that shortly.
Also worth noting at this point, is that, if you restart your PC or for some other reason, your terminal/command prompt is closed, you do not need to re-execute the
git init command.
I repeat, do not execute
git initmore than once in a project folder.
Nothing bad will happen, but it’s just pointless. You initialize your project directory as a local git repository once and only once. Subsequently, you can perform other git actions such as committing changes which (I remember) we’ll look at in a bit.
Final note: always remember to execute git commands in your project directory. If for some reason, your terminal/command prompt is closed, reopen it and navigate back to your project directory before executing git commands. If you try to execute a git command without navigating to your project directory, you’ll get the following error:
fatal: Not a git repository
Alright, where were we? Ah, I remember… How do we tell Git to save relevant changes? Simple, really. Just like when you want to send multiple files via Bluetooth, you mark/select the files, then you send; we likewise tell Git to mark the files we want to save, then we save.
You can tell Git to mark certain files for saving. The
git add command is responsible for this. At the end of the command, enter the path to the files you want to mark (relative to the project folder), separating each file’s relative path with a space.
The command below tells git to MARK 2 files for saving (changed_file_1 and changed_file_2 in the subfolder named folder1):
git add changed_file_1 folder1/changed_file_2
You can also tell Git to MARK ALL CHANGED/EDITED files for saving. The code below does just that:
git add .
There are times when you want to use the
git add . command to MARK ALL edited files. Actually, most times that’s what you should do. But there may be some files and folders that have no business whatsoever in a git repository. Such files may include IDE autogenerated files/folders and sensitive configuration files which you and I know is not meant to be seen by everyone. You can tell Git that:
Hey Git, whenever I say mark all files, what I actually mean is that you should mark all files except these files”
If Git was not smart, it would have replied:
Say what now? What files do you want me to ignore?
But Git is smart. It’s smart enough to know that there’s a file it can check to find out which files and subfolders you want it to ignore. So, create that file directly inside your project directory. Do not place that file inside a subfolder! The name of the file should be “.gitignore”. If you give it any other name or put the file in a subfolder, Git will just be looking at you like 🙄🙄
Assuming you’re still with me up to this point, open your .gitignore file and start to enter the name(s) of those files and subfolders you want Git to always ignore even if you tell it to mark all files. Each file/subfolder name should be in a line of its own. When you’re done, remember to save the .gitignore file. (Control + S, anyone? Or is it Cmd + S? Whatever works for you!)
Whether using a .gitignore file or not, remember that you must always MARK the files you want Git to save before you finally save.
To finally save the MARKED files to the local repository, enter the following code in your terminal/command prompt:
git commit -m "short descriptive message"
Did you type that exact code in your terminal/command prompt 🤦♂️? I wanted to explain to you that you should change the text in quote to any message that actually briefly describes the changes that you’re about to commit. Oh, just so you know, the write word is commit, not save. If we’re all gonna become Git experts, we might as well start using the right terms, shouldn’t we?
What commit message did you use? This is an example:
git commit -m "change login page background color"
Just a passing mention, there are conventions (standards) for how to properly write git commit messages. Here’s one way to write good commit messages.
Of course, no one’s gonna beat you if you write whatever message you like, but at some point in the future, when you start working on projects in “organized” organizations or with other pros, you’re gonna need to write proper commit messages.
And that’s it! Git has “saved” (yeah, I know, won’t use it again, I promise) our latest changes to the local repository. Later in the future, we can come back to view these files, as they are right now.
While Git is in itself a marvel, it is often paired with special kinds of cloud hosting platform like GitHub to enable you keep copies of your local git repositories in the cloud. Doing so enables you to access your project files anytime, anywhere. It also enables you to allow others view your project files, make and commit changes or just review your work.
You can learn more about such git hosting platforms and how to connect your local repositories to them in the next article: GitHub 101 — Introduction to GitHub for Newbies.
That’s it for now. Gracias mucho. If you enjoyed the article, don’t forget to leave some claps.
Thoughts? Questions? Drop ‘em in the comment section or shoot me an email.