Section 4.1 Getting Set Up with Git
You should have Git installed at this point. If not, see Materials: Windows, Materials: Mac, or Materials: Linux. This means you already have Git ready to go. But how do we use it? We created a repo on GitHub but need a way to connect that repo with our personal computer. That’s a great feature of Git: to connect the files on your computer to GitHub. It also performs version control and automatically records changes that have been committed.
It’s not always feasible to edit file on GitHub, as we did in Section 3.2 and Section 3.3. Certain text editors (for instance, Visual Studio Code which you might also have installed) have features built in to ease coding and file editing. VS Code extensions might add color to text to help you see what’s going on in your code. Others provide bug fixing and error catching before the errors actually occur. In general, you will edit files on your personal computer and will want to share them with the world. I would stay away from editing on GitHub unless you have a small correction and/or you don’t need any special editing tools.
Subsection 4.1.1 Cloning a Repository
In order to make Git work, we need to set up a connection between your computer and your GitHub repo. From here on, I might refer to your personal files as your local files. A file is typically considered “local” if it does not exist on GitHub (or anywhere else on the internet). It is local because only you have access to it. You will likely hear other people use this term and its derivatives (such as “editing locally”). Whenever it comes up, it refers to work/files/things on your computer and not online.
So let’s use the new vocab. We need a way to edit our GitHub repo locally but still have version control and GitHub tools. Git is the right tool for the job. Performing this connection is called cloning. A clone of a repository is a local version of a repo that exists on GitHub. Luckily for us, GitHub expects us to do this and makes it rather simple to do.
Somewhat unfortunately, one thing must be done before we are able to clone a repo. Interacting with your GitHub materials in this way will require authentication; in other words, your password. This is necessary for safety and is a smart feature. However, Git/GitHub has deprecated the use of passwords on the command line so we must generate an Personal Access Token (PAT). The following procedure guides you through this process. I recommend creating a new PAT for each repo to ensure that if anyone gets unauthorized access of one repo, they won’t be able to get to your others.
(a)
Click on your GitHub profile icon and navigate to Settings.
(b)
Scroll down and click on “Developer Settings”.
(c)
Click on “Personal access tokens” and then “Tokens (classic)”. This page will give you an overview of all the tokens you have created, their expiration dates, and the things they have access to.
(d)
Click on “Generate new token” and then “Generate new token (classic)”. Your GitHub password may be required.
(e)
Enter a title for your token. What is your project? This name doesn’t really matter; it exists solely to help you remember why you made it. If this is your first PAT, perhaps name it “Git Started Work” or “About Me”.
If you choose the above, make sure you only use the token for that purpose!
(f)
Choose an expiration date. At what point do you plan on being done with this project? Set the date for a month after that. Don’t fret too much about it; you can always create a new PAT later for the same project. But I can bet that you won’t want to do this process more than once for one project if you can help it.
(g)
Select a scope or scopes. What do you want this PAT to give you access to? This will depend on your project but less is better (for privacy and security). If you do not give a PAT permission to do something, that something will not be able to be done locally, even by you.
For this project, you will want the “repo” scope and maybe the “user” scope. Once you have the scope(s) selected, click “Generate token”.
(h)
You will get an email that a PAT was created. Record your PAT somewhere. You will never see it again after you close or refresh the page. Don’t put it somewhere easily accessible. Treat PATs like passwords. They are confidential and should not be shared. When Git (on the command line) asks for your password, you will enter in your PAT instead.
Now that we have a PAT, let’s work on cloning a repo! You will likely need your PAT in this procedure. Note that sometimes Git remembers old PATs. If Git does not ask you for a password, this doesn’t mean something went wrong, it just means that you are already authenticated.
Git Procedure 4.2. Cloning from GitHub.
This procedure assumes you have a repo on GitHub called
aboutme and have been following along with the changes as described in Chapter 3.(a)
Navigate to the Code tab your repo
aboutme. Make sure you are on the main branch.(b)
Find the dialog box labeled “Code” (yes, the Code box inside the Code tab). This can be found above your list of files.
Click on this Code box and make sure you have the “Local” sub tab selected. This part is titled “Clone” which is a good sign. A url-like string should appear (if not, be sure you have the HTTPS tab selected.) Copy this string.
See Figure 4.1.1.1 for what the Code submenu might look like.
The Code box which contains the Local tab which contains an HTTPS link to copy.
(c)
Open your terminal. Use
cd to navigate to a folder where you want your repo to live locally. Remember that repositories are essentially folders. When you clone your repo, it will look like a folder on your computer. In some cases, it might not make sense to create a folder and then clone your repo as it will look like a folder that contains a folder. Note that the name of the cloned repo/folder will be the name of your repository.(d)
You should be at the location you want your repo to be. It is now time to activate Git. Every time you use a Git command, you start with
git, then the command. For cloning:> git clone <copied-https-string>
Cloning into 'aboutme'...
remote: Enumerating objects: 17, done.
remote: Counting objects: 100% (14/14), done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 17 (delta 2), reused 0 (delta 0), pack-reused 3
Receiving objects: 100% (17/17), 5.06 KiB | 1.01 MiB/s, done.
Resolving deltas: 100% (2/2), done.
where <copied-https-string> is replaced with the HTTPS string you copied in Task 4.2.b. Press Enter to run the command.
Your terminal may ask you for your GitHub username and password. This is ok: enter your username and instead of typing your normal GitHub password, paste/type your PAT as found in Git Procedure 4.1.
(e)
Verify that the clone worked. In the location you chose (on your computer), you should see a new folder with the name of your repository. Inside of that folder will be your files!
Cloning a repository does not navigate you into that repo. In other words, when you clone a repo, you won’t see the files in the repo until you
cd into the newly-created directory. In order to use Git, you will have to navigate your terminal into the repo. In this instance, you would do cd aboutme.Subsection 4.1.2 Branches With Git
Great! We’ve cloned a repository. Now what? You probably want to jump into editing files but wait! Best practice says to create a new branch first. Sure, you are working solo (if you aren’t, see Part III) and you can really do what ever you want. You could just edit everything on the main branch and never have to worry about other branches. No one will be able to screw with your files without permission.
No one except you! Yes, you could make a mistake and break your program or project. You want to avoid that. I would recommend always using branches whether you are working alone or not. If you make a horrible mistake, branches help you fix mistakes without messing with your main branch. Remember, if your repo is public, anyone can access it. Anyone can view the files, download the files, clone your repo, or fork your repo (Subsection 5.2.1). You want to make sure that the files on the main branch are up-to-date AND functional at all times. Branches will let you test new things without breaking main.
We saw earlier how to work with branches on GitHub, but you can also do this right from the command line. This can be done with two commands (or one, see Branch/Checkout Shortcut) and doesn’t involve navigating multiple pages as we did on GitHub (Section 3.3).
Git Procedure 4.3. Branches With Git.
Later on in this chapter, you will be adding to your README file. You first will add the country you were born in.
(a)
Ensure that your terminal is navigated into your repo. You may have noticed that your terminal changed! The name of your active branch is displayed by the file path. Mine now has a
(main). This is how you remember which branch you are editing on.(b)
Remember that each Git command begins with
git to let your computer know you will be using Git. To create a new branch, use the following:> git branch <branch-name>
where
<branch-name> is the non-spaced name of your new branch. Try creating a new branch now, with the name of country. So,> git branch country
(c)
Well, shoot. Git still says we’re on the main branch. We want it to tell us that we are on the
country branch. That’s because we need to tell Git that we want to work on that new branch. Git doesn’t move you to that branch in case you want to make more than one branch at one time.With Git, navigating to a new branch is done with the
switch command. In general,> git switch <branch-name>
Switched to branch '<branch-name>'
If done correctly, Git will tell you that it switched to the new branch. This should be reflected in the branch name indicator. Switch to your new branch
country:> git switch country
Switched to branch 'country'
My terminal now says
(country) instead of (main) so I have verification that the process worked.Branch/Checkout Shortcut.
Using a little terminal trick, we can actually create a branch and switch to that branch at the same time. This uses the
-c argument. For our example in Git Procedure 4.3,> git switch -c <branch-name>
Switched to new branch '<branch-name>'
By adding the
-c argument to the switch command, Git creates a new branch with the title given and checks out that branch. This is quite useful if you are only creating one branch and want to switch right to it. If you are uncomfortable with this, then feel free to continue using the method in Git Procedure 4.3. Each will get you to the same place.Note About git switch (Optional).
The
git switch command was introduced to help remove user confusion. Previously, the command was git checkout <branch-name>. However checkout has two functions: to switch branches and to reset files (if a file has edits that you want to restore, you can use checkout to restore the file to how it was before you made the changes).git checkout still exists and you are welcome to use it to switch branches (you would use git checkout -b <branch-name>). However, to avoid confusion, I recommend using git switch for changing branches and git restore for restoring files.You are now ready to edit files! You determined a chunk of your project to start with (adding your birth country), created a corresponding branch (
country) and checked out that branch. Until you change your branch again, all edits will take place on your current branch only. Continue on to edit your README file!
