Now let's create a new directory called
git_basics and add a few files to it.
$ mkdir git_basics
$ cd git_basics
$ echo '# README #' > README.md
$ echo '# LICENSE #' > LICENSE.md
> character on lines 3 and 4 above is the redirection operator. This operator takes the output of the command and places it in the file whose name appears to the right. These two commands, thus, create 2 files,
LICENSE.md, each of which starts with a simple comment (
# README #,
# LICENSE #).
The files above,
LICENSE.md, are for demonstration purposes only, though they are included in the root directory of many open source projects. These particular files use the markdown format. We are using markdown here because it is readable as plain text and will render nicely when we share our repository on github.com in the next section.
As of late 2020, GitHub uses
main as the name of your primary branch (it used to use
git, however, still defaults to
master. You want to make sure that both
git and GitHub are using the same branch name, so we'll use
main. The best way to accomplish this is to change your default branch name to
$ git config --global init.defaultBranch main
If you are using an older version of
git (pre 2.28), the above command won't work. If that happens, you can ignore the error and continue to use
master wherever we mention
main. Alternatively, you can run:
git branch --move master main
to change the name after you make the first commit to your repo. However, you will have to do this for every new repo.
If this command doesn't work, try this one:
git branch -M main
Throughout the remainder of this book, we assume that you are using the
main branch as your default.
We're now ready to create a local repository. On the command line, from within the
git_basics directory, type the following:
$ git init
Initialized empty Git repository in .../git_basics/.git/
Initialized message means that
git "initialized", or created, a new repository in your current directory. Technically, the only thing that changed was a
.git directory was added to the
git_basics directory. Conceptually, you can think about it as turning that directory into a git repository. After you initialize a directory as a git repository, you can start issuing other git commands.
Do not nest your repositories. That means that if
~/dev/project is a repository,
~/dev/project/other_project should not be another repository. You need to move
It's important to only issue the
git init command from within the directory that you wish to turn into a git repository. If you've accidentally typed that command in a directory that you didn't want to turn into a git repository, all you have to do is delete the
.git directory within that directory. Deleting the .git directory doesn't uninstall the
git application or affect the other git repositories on your computer. It only removes the git repository from the current directory.
After you type
git init, a directory named
.git is added to the current directory. This directory will contain all of the configuration and metadata necessary for git to keep track of our files and the changes that we make to them. The directory name starts with a
. to signify that it's a hidden file. Hidden files are normally not shown to the user by the operating system. Your operating system uses many hidden files for system configuration purposes and the
.git directory is a configuration file for git.
Use the terminal to display the
.git directory with the command
ls -a. The
ls command lists the current directory contents and by default will not show hidden files. If you pass it the
-a flag, it will display hidden files. You can navigate into the
.git directory like any other normal directory. Go ahead and poke around the
.git directory to take a look at its files. Take a peek at the
.git/config file in particular. No need to do anything or make any changes, just take a look at it. You'll want to peek at this file periodically after you make changes to your git repository configuration.
There are three places on your system where git keeps its configuration information.
|Contains settings that are system-wide and apply to all users and all of their repositories.
|Configuration that is specific to your user account. This file overrides
|Configuration that is specific to a repository. This file overrides both of the other files.
The precise location of the system-wide
gitconfig file may vary from one system to another. In fact, its very existence depends on whether you have set any system-wide configuration items. For the most part, you do not need to concern yourself with this file's location and contents.
Usually you'll want to store your identity information, your name and email address, in
~/.gitconfig file, which tells all git repositories in your system your name and email address, which will be applied to each commit. There are many other configuration settings that can be set, including colors for git's output. Where those configuration settings go will depend on whether you want them to be global settings or just for a particular repository.
Most configuration settings can be set with the
git config command, which is how you should manage the
~/.gitconfig file. Let's go ahead and configure your identify. Type the following into the command line, replacing the fake name and email address with your own:
$ git config --global user.name "Maya Angelou"
$ git config --global user.email "MayaAngelou@poets.com"
--global flag tells git to save the configuration in your personal configuration file,
~/.gitconfig. If you were to use the
--system flag, the configuration would be saved in
/etc/gitconfig, thereby applying to all users on this computer. If you do not pass the
git config command any flags, it will save the name and email in the current repo's config file,
Most git repositories will have private data that you do not want shared, such as local databases, log files or personal credentials. That is what the
.gitignore file is for (note the
., which means it's a hidden file). This file is a list of files and/or directories that you do not want included in your repository. Git will not allow you to add any of the files referenced in .gitignore to your repository. The
.gitignore file lives in the current git repo's directory and paths to ignored files and directories should be relative from that directory.
Let's create a dummy database file which we do not want to commit to our repository. From the
~/git_basics directory, type the following commands from the command line:
$ mkdir db
$ touch db/development.sqlite3
If we ran
git add and
git commit commands now, the database file (
db/development.sqlite3) would be committed to our repository. However, we don't want to do that. Instead, we need to tell
git to ignore the database file (and any other
*.sqlite3 files that we may create in the
db directory). To do that, we need a
.gitignore file. In your terminal, type:
$ touch .gitignore
~/git_basics/.gitignore in your text editor and add the following to the file:
# Ignore all SQLite databases
The lines that start with
# are ignored and act as comments. The
* on the second line acts as a wildcard, so our
.gitignore file ignores all files with the extension
sqlite3 in the
db directory. If you put this in a global ignore file, the same would apply to all git repositories on your computer. We won't talk about global git ignore files, but the concept is the same. For now, just use the
.gitignore file in the repo you're working with.
git will ignore any
sqlite3 files in the
Remember to create a
.gitignore file for every git repo you're working with.
You can create private repos on GitHub for sensitive data. To convert a repo to private, login to GitHub in your browser, open the existing repo, then click the Settings button. Scroll down to the bottom of the page to find the "Change Visibility" button. Click that button to convert the repo to a private repo.
git command offers no built-in way to make a private repo. You have to log in to GitHub to change the repo's settings or use GitHub's command-line tool. We do not cover the command-line tool in this book.
In addition to sensitive data, private repos are good for scratch projects, Launch School notes, and more. While at Launch School, the simplest approach is to put code for LS projects in public repos, and put everything else in a single private repo.
DO NOT POST any Launch School assessment-related information on GitHub or any other site.
Keep in mind that once you upload sensitive or private data to a public repo, there is no way to remove it entirely. Your only options are to either delete the entire repo or make the repo private.
This first video introduces us to the concept of repositories and how to configure its settings:
Next up, we talk about creating new repositories with
git init and also talk about
In this chapter, we learned how to turn any directory into a git repository just by using the
git init command. All the
git init command does is add a
.git folder to the current directory, and that enables the directory to be a git repository. We also talked about how to configure your git repository, and the very important concept of never nesting your git repositories.