As we mentioned in the first part in this series, Git for Beginners Part One — Intro, $git init is a one-time command used to create and configure a new repository. When you run $git init, it creates a new master branch on which you can build your new project. It also generates a new .git subdirectory in your current working directory, which is the base of the project. This subfolder contains everything that Git generates to track and store the revision history of each file.
Take note of the dot before the “.git” folder. This makes it effectively invisible in both the finder and the terminal unless we use a command to explicitly expose it (Hint:
$ ls -a).
Don’t worry if you haven’t discovered the .git subdirectory, let alone gone crawling around in it. The only reason we would even want to expose .git is used to ensure that the working directory has a Git repository. This is a useful skill, but otherwise, you should avoid touching the .git folder.
Git does this on purpose: there is a lot of vital information there, most of which is beyond the grasp of mere humans and average developers. Let it suffice to state .git, the folder, contains almost everything that makes Git, the versioning management software, do what we want it to do, and tampering with its contents might badly derail your project. Simply do your job and have faith in .git to do its own thing.
Just Gitignore IT!
I don’t just mean disregard the contents of .git folder.
What is .gitignore?
Another secret file in your repo, called .gitignore, is created automatically when we execute $git init. Your.gitignore file names untracked files to notify git “Hey, don’t include these!” in its versioning operations.
Essentially, it’s a list of files you wish Git to ignore.
This is similar to Git’s distributed graph theory tree model. Every file in your working directory is classified as one of three things by Git:
Tracked files are those that have already been staged and/or committed.
Untracked — a file that has not yet been staged or committed.
Ignored — a file that Git has been expressly instructed to ignore.
Ignored files are typically OS-specific files — that is, files that your computer requires to render your project but have nothing to do with your real project. This is why we don’t want to include them in our repository: they take up needless space. GitHub may be free (for the time being), but it is not endless — .gitignore is a politeness gesture from each user to only send items that belong to a project. On occasion, .gitignore contains files that are required for the project but not required by the repository because they are always generated/derived from the computer and platform on which the project is being run.
Whew! That was a lot of abstraction at the highest level. Here’s an example to help you understand: Assume you’re using a Mac and have .DS_Store files can be found in all of your directories. (You do; they’re everywhere, but they’re also harmless; it’s an Apple thing). The name .DS_Store is an abbreviation for Desktop Services Store, and it is an autogenerated file that appears in every folder (directory) you create. It saves the custom attributes of its parent folder, such as icon position and background image selection. Think of the .DS_Store file of Mac just like the .gitignore file of git. It contains some config information about your Mac you don’t necessarily want to upload to a public space like Github.
Now let’s take it back to Git. The .gitignore file contains details that are for your PC or Mac, like your Hello Kitty Desktop picture. You don’t need Git to track this information about your Hello Kitty desktop picture, stage it, commit it, and publish it to GitHub every time you commit. It has nothing to do with your project and will simply sit in memory, never being used. It’s only a small amount of RAM, but if every single change to GH contains superfluous files, and there are over 57 million repositories…well, it starts to add up. As a result, we instruct Git to disregard the superfluous, with our .gitignore file.
How to .gitignore?
We’ve dedicated this whole article to .gitignore because, while the underlying concept is simple enough, implementing it requires relying on several concepts. This is something that has confused enough of my students for me to realize that a walk-through is necessary.
Step 1: Open the terminal and navigate to your project folder. (Recall the studious_octo_carnival? That will serve as our example). Then, use “$ls -a” to print all of the project’s files, visible and hidden. And there you have it, our .git:
However, there is no .gitignore file. We must create one; Git does not do this automatically.
Step 2: Run “$ touch .gitignore” to make the .gitignore directory. Remember to include the “.”
Step 3: Open the project in your preferred text editor. Because we’re utilizing Atom. To launch Atom and open the current directory, we type “$atom”
(Bonus tip: To enable access to Visual Studio Code from the terminal, open VSC first. Select Install Shell Commands from the Atom menu in the top left corner. Return to your terminal; from now on, you may simply type “code” to launch or it, “code.” to launch the current working directory, or “$code,/directoryName” to open another directory).
Notice how our new .gitignore file is green, which indicates that it is untracked — that is, we haven’t staged/added or committed it yet.
Step 4: In VSC, open the .gitignore file like you would any other file, such as index.html. For some strange reason, this step appears to be the most enigmatic to my students, but a hidden-with-initial-dot file functions the same as any other. VSC will open a window for .gitignore when you double-click on the directory name.
Step 5: Now comes the fun part: we add the information we want Git to ignore.
Because this is plain text, we use # at the beginning of each line to indicate that it is a comment. (Or you can add a bunch of #### at the top and bottom of the list of things you want git to ignore like I did here). Then we just specify what we want Git to ignore. In this section, I include all of the garbage that the Mac OS generates in every directory that is created. So, aside from that .DS_Store file, we have machine-generated files like Thumbs.db (which renders thumbnail pictures) and .Trashes (this is the location where deleted files are kept until being permanently erased. GH does not require our thrash!).
That’s all! In your .gitignore file, just type the name of any file you wish git to ignore. Now save it … Done.
What is a Global .gitignore file?
Because so many of these nefarious files will be ignored in every project, it’s even more convenient to establish a global .gitignore file, which is a list of files to be ignored in every git repository on your computer.
Step 6*(optional)*. Go to the terminal and navigate to your top-level directory. (usually, the one that has your username; it contains all your files and on Macs has the little house icon next to it in Finder if you are unsure).
Now, start typing.
git config --global core.excludesfile ~/.gitignore global
In your text editor, navigate to the new global .gitignore directory and add All The Bad Things you want git to always ignore. The system files generated by the operating system are a good place to start.
GitHub offers a handy list of things it will never ever use but hopes you will .gitignore on their behalf as well as your own.
NB: Recursion is a not possibility.
Sadly, .gitignore is not recursive, if you have already committed a project and then go back to create a .gitignore, you must first lay the groundwork. If you wish to ignore a file that you’ve previously committed, such as .DS_Store, you must first delete it from your repository and then add a .gitignore rule for it.
Come to think of it, there is also a handy option called “--cached” (two dashes plus the word “cached”) that, when used with the Git remove command $git rm results in the file being deleted from your repository but remaining in your working directory as an ignored file.
Any file with a “.log” extension is eligible for inclusion in the .gitignore file. Git, thankfully, also generates its logs and does not require yours. If you’ve already committed a project and wish to remove the log files, it would look like this:
git rm --cached *.log
git commit -m "Start ignoring *.log files"
Because these meaningless files are now maintained by Git, removing them becomes part of the version history, so we must commit with a notice.
When you’re a rookie programmer and overloaded with all the things you do want Git to pay attention to, setting up the .gitignore file may seem like an unnecessary extra step. But I promise you that doing this for each repo you create is a vital step towards being a good GitHub citizen — and being taken seriously as a coder.
#YouAreAwesome #StayAwesome