Skip to main content

Section 6.1 Getting Set Up: A Few Extra Steps

Before you are able to jump right in and start editing files locally, there are some things that have to happen first. Like in Section 5.2, we need to fork the repository you would like to edit. Although it is possible to use Git to edit on a repository that has not been forked, you will find problems when you try to push your changes since you do not have write access to the repo.
So, to continue on with this section, make sure you have my aboutme repository forked. Recall that we did this in Subsection 5.2.1. If you’ve done this already, you do not need to do it again. If you haven’t, review the instructions in Subsection 5.2.1.
I would also like to repeat something I said back in Section 4.1:
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.
The rest of this section and chapter will look a lot like Section 4.1 and Chapter 4 with a few changes. With that being said, do you remember what the first step to editing locally was?

Subsection 6.1.1 Cloning A Fork

Hopefully you didn’t peek ahead! The first step is to clone our repo. Remember that in order to edit files locally, we need a copy of the repository on our computer and the way to do that is to clone.
This again increases the complexity of the Git tree. From an authoritative repo we made a copy on GitHub, called a fork. We did this so that we could have all freedom to edit the files as we pleased without breaking any of the official files. From there, we need to clone to make a copy of the fork on our computer. Do make sure you are cloning your fork, not the repo you forked.

Checkpoint 6.1.1.1.

So go ahead, use your terminal clone your fork of my aboutme repository. Before you do so, make sure that your branch is up to date with ian-curtis/aboutme:main.
Don’t remember how to do this? Git Procedure 4.2 might be useful, as may be the solution to this exercise.
Solution.
Use the code tab on your fork to copy the HTTPS link. Then use git clone <https-link>. Make sure you have used cd to get to the right place first!
Great! Your repo should now be cloned on to your computer. Carry on.

Subsection 6.1.2 Don’t Forget About Branches!

For nearly every edit we’ve made in this book, we’ve made a corresponding branch. This is no different. I hope you understand the importance of branches, even if you are working with yourself.
Since my repository is public, anyone can edit the files there. Therefore, I will approve pull requests from anyone as I will assume they are working through this book. However, the task in this chapter will be exclusive to just those who are reading this book. There is file called secret.txt with no instructions or anything at all. Later on, you will be adding a line to this text file.
For now, create a good branch name for this edit, perhaps secret? Remember that cloning a repo does not navigate inside of the repo so make sure you use cd <your-repo-name> before creating a branch.

Checkpoint 6.1.2.1.

Make a new branch. Switch to that branch. See Subsection 4.1.2 if you need a refresher.
Solution.
There are a couple of choices here.
  1. git branch <name> then git switch <name>
  2. git switch -c <name>
Arrow diagram depicting main repo copied to a fork, then a clone. Edits on a branch from the clone are merged into main branch of the fork, then merged in to main branch of authoritative repo.
Figure 6.1.2.2. Diagram of a fork, a clone, and a branch
Take a look at Figure 6.1.2.2 for a visualization of what the Git tree might look like at the end of the editing process. This is the end goal. Then, let’s get to editing.