Git Setup

Learning Competencies

By the end of this challenge, you should be able to:

• Navigate repositories in GitHub
• Create a Git repository both from the command line and on GitHub
• Understand and execute essential Git commands such as git add, git commit, and git push
• Establish a connection between local and remote repositories
• Clone a repository
• Check repository status

Summary

Now that you kind of understand version control, it's time to start using Git. We're going to set up a new git repository, two ways! Then we'll explore the difference between local repositories on your computer and remote repositories on github.com.

Time Box

Try to follow the timebox suggestions. Remember, they're more like an "upper limit" than necessarily how much time you should spend.

How Git works

With Git, each project has a repository - a collection of all the versions of the project along with some special information - What order the changes occurred, a description of each change, who was responsible for each change etc. It's a history of everything that happened in the project, every step along the way.

Git doesn't automatically keep track of your versions - You have to explicitly tell it when you are finished so that Git will track them for you. The act of telling Git that the version is finished is called committing. Much like you would commit something to memory, you also commit changes to your repository. Because of this, versions are often referred to as commits. In some cases a commit might be a big new feature, or something small like a spelling correction or a fix to a broken link.

Committing your changes is like a saving your progress in a videogame, but instead of overwriting your previous save file, you keep that one too! You can keep playing from where you're currently up to, or teleport back in time and play old levels again. All of your items and equipment would be exactly as they were back when you first played the level. Everything is saved and recorded, frozen in time in every commit along your journey.

When you interact with your project, these commits are hidden so that you won't even know they're there until you need to interact with them. Git has a set of tools to review your project history. For example, it can allow you to view or filter the complete list of commits or even switch what version your project is currently displaying. Do you want to look at what your project looked like this time last sprint, last month, and last year? Git will let you do all those things, often with just one command.

Git Terminology

Shared via Readwrite.com

Command Line - The computer program we use to input Git commands. On a Mac / Linux, it’s called Terminal. On a PC, it’s a non-native program that you download when you download Git for the first time. In both cases, you type text-based commands, known as prompts, into the screen, instead of using a mouse.

Repository - A directory or storage space where your projects can live. People call it a "repo" for short. It can be local to a folder on your computer or storage space on GitHub or another online host. You can keep code files, text files, image files, you name it, inside a repository. Storing small-ish files like these are free, but if you want to store bigger files like movies you need to use something called "Large File Storage (LFS)" which costs a little bit of money.

Version Control - Basically, the purpose Git was designed to serve. When you have a Microsoft Word file, you either overwrite every saved file with a new save or save multiple versions. With Git, you don’t have to. It keeps “snapshots” of every point in time in the project’s history, so you can never lose or overwrite it.

Commit - This is the command that gives Git its power. When you commit, you are taking a “snapshot” of your repository at that point in time, giving you a checkpoint to which you can reevaluate or restore your project to any previous state.

Branch - How do multiple people work on a project simultaneously without Git getting them confused? Usually, they “branch off” of the main project with their own versions full of changes they themselves have made. After they’re done, it’s time to “merge” that branch back with the “main,” the project's main directory. This is important because it helps people not override each other's code when they're working collaboratively on the same project.

Git Commands

Shared via Readwrite.com

Since Git was designed with a big project like Linux in mind, there are many Git commands. However, to use the basics of Git, you’ll only need to know a few phrases. They all begin the same way, with the word git.

A few essential commands to get familiar with

git clone [the url for a repository] - Copy an existing repository from a target location (such as GitHub) and create a matching version on your computer.

git status - Check the status of your repository. See which files are inside it, which changes still need to be committed, and which branch of the repository you’re currently working on.

git add [the name of a file you want to add, or ALL your files with the -A flag] - This does not add new files to your repository. Instead, it brings new files to Git’s attention. These added files are referred to as "tracked". After you add files, they’re included in Git’s “snapshots” of the repository.

git commit - Git’s most important command. After you make any change, you input this to take a “snapshot” of the repository. Usually, it goes git commit -m “Message here”. The -m indicates that the following section of the command should be read as a message.

git push - If you’re working on your local computer and want your commits to be visible online on GitHub, you “push” the changes up to GitHub with this command.

git help - Forgot a command? Type this into the command line to bring up the 21 most common Git commands. You can also be more specific and type git help init or another term to figure out how to use and configure a specific Git command.

git config - Short for “configure” is most useful when setting up Git for the first time.

git init - Initializes a new Git repository, i.e. turns the current folder into a Git folder. It's just a regular folder until you run this command inside a repository or directory. Only after you input git init does it accept further Git commands. Be careful just running this command in random places, if you create a git repository somewhere unexpected on your computer it can mess up your ability to interact with your other repositories. This is because if you have a git repository inside another git repository, only the "highest" repository will work. IE, if you created a git repository inside your Documents folder, no other git repositories inside your documents folder would work anymore.

rm -rf .git - ⚠️ DANGER: This command PERMANENTLY DELETES a git repository from your computer. There is NO UNDO!

This is used to FIX the situation mentioned above where you accidentally created a git repository in the wrong location.

Before running this command:

1. Make ABSOLUTELY SURE you're in the correct directory by running pwd first
2. Double-check that you actually want to delete this repository
3. Ensure you have no uncommitted work you want to keep

To use safely: Navigate into the folder with the unwanted git repository using cd, verify your location with pwd, then run rm -rf .git to remove the repository.

git pull - If you’re working on your local computer and want the most up-to-date version of your repository to work with, you “pull” the changes down from GitHub with this command. It is useful when working on the same repository as someone else or on different computers.

git branch [name of branch] - Working with multiple collaborators and want to make changes on your own? This command will let you build a new branch (or timeline of commits, changes and file additions) that is entirely your own. Your title goes after the command. If you wanted a new branch called “cats”, you’d type git branch cats.

git checkout [name of branch] - This allows you to “check out” (switch to) a different branch in your project. You can use this command as git checkout main to switch to the main branch or git checkout cats to switch to the cats' branch.

Try it out!

Okay so now we're going to create a new repository- two ways. First it's important to really double down on this concept of "local" and "remote" repositories. A remote repository exists on the internet, somewhere on a server probably far, far away. It might be underground in a desert in Arizona. A series of tiny cables connected to a shiny silver box eventually become larger, thick polyethylene armoured tendrils snaking along the ocean floor. They snake their way all the way to the coastline of your country, under your streets and eventually into your home. This is how the remote repository communicates with your local repository.

The local repository lives on your computer, and it is a "clone" of the remote repository. This means that they are destined to be the same. They want to have the same files in them, and contain the same stuff. They can have differences from each other, but they don't like it! Their goal is to spend as little time being different from one another as possible. We'll cover how to reconcile their differences soon, but for now, let's create a new local git repository.

Creating a local repository from the command line

In your terminal, use cd to navigate to the place where you want your new git repository to be. This needs to be somewhere that is not already a git repository. Once you're there, run mkdir git-test. This creates a new empty folder, and next we can hop into it with cd git-test.

Now that we're inside, run git init. This will create a new git repository here, and place us on the main branch. You might get a message in your terminal saying that the default name for your branch is 'master'. In recent years, developers have been moving away from using this name for branches because of it's historical connections to slavery. The preferred name for the primary branch on a repository is now 'main', and you can change this default name by running the command git config --global init.defaultBranch main. If it has already named your current branch master, this can also easily be changed with the command git branch -m main.

Now we have successfully created a git repository, but it doesn't have anything in it, and it also doesn't have a remote branch. Right now it is completely pointless. Most repositories have a readme file, which is basically like the description of / instructions for your repository. We can create one for our new repository using the touch command. touch readme.md.

If you run ls now, you can see that the readme file has been created. Right now it's empty, so let's run code . to open up our new repository in visual studio. You should be able to see your readme.md file on the left hand side of the screen now and add some text into it. You can add whatever you want, I wrote "This is the best repository I've ever seen". Then save your file.

Adding and committing your changes

Now that we've added something to our repository, we need to "save" those new changes. We already saved the new markdown file, but that just saves it to our computer. In order to really save stuff in git, we need to do three other steps. You're going to do these steps 10,000 times in the future so pay attention, and also don't worry if you forget how to do it. You'll get plenty of practice later on.

• Step 1: Adding files When a new file is created, it needs to be "tracked / added" by git. This means right now even though our readme.md file exists, git doesn't care about it. If we run git status right now (A good command to know, it just means basically "What is going on with git right now?") it will tell us nothing added to commit but untracked files present (use "git add" to track). If you are confused at any point, try running git status. Often it will give you hints about what you might want to do next. In this case, it's telling us to use git add to track the new file we have created. You can do this by running git add readme.md, or if you want to just add all the files in your repository, you can do this by running git add -A. The -A is for "All". There are some very rare cases where you might want to not be tracking all of your files, but don't worry about that right now. Just use git add -A every time, and don't worry about tracking individual files. If you run git status again, you can see the message new file: readme.md, confirming that it is now being tracked.

• Step 2: Committing changes Now that we have added our changes, we need to "commit" them. This is like when you have put the birthday present into the box, and you're going to tie it up with a nice big ribbon and write a heartfelt message on the card. The commit says "Yes, I have finished making my changes, I'm ready to save them now, and here's what I did". Enter the command git commit -m "add readme.md". Notice that add -A from before has an upper case A and commit -m has a lower case m. This is important, and serves no purpose other than to trick you into forgetting which is which and getting it wrong. Don't let it trick you. Running git status again should now show the message 1 file changed, 1 insertion(+), which means everything went really well.

• Step 3: Pushing to github We've added our files, made our commit with a message, now it's time to "push" those changes up to github.com. That's where our remote repository lives, over the ocean in the desert. The only problem is, we don't actually have a remote repository yet. We haven't created one; it doesn't exist. Try running the command git push in your terminal and you will receive back a FATAL error. fatal: No configured push destination.. So we're stuck here, we can't complete step three until we create a remote repository.

Creating the remote repository

It's time to head on over to github and create our remote repository. Up in the top right hand corner you click Create New... > New Repository. Set yourself as the "Owner" and call the repository git-test. You can leave all the other fields empty or just however they are by default.

Now on the next screen, there will be instructions for how to clone / create or push to this repository. The part we're interested in right now is pushing to this repository, and one command in particular. From your terminal, run git remote add origin git@github.com:YOUR-USERNAME/git-test.git. Obviously replacing YOUR-USERNAME with your username, unless coincidentally your username is YOUR-USERNAME. You will only need to do this step once, your local repository will remember the remote address from now on.

• Step 3, Again: Pushing to github

Normally at this point, you would simply run git push and you would be done. However, because this is the first time you have pushed up to the remote repository branch, you will get the FATAL error fatal: The current branch main has no upstream branch.. This sounds stressful, but luckily the error message tells us exactly what we need to do to fix it: To push the current branch and set the remote as upstream, use git push --set-upstream origin main. And we should listen! Run git push --set-upstream origin main now.

Git will then take your local commit, and push it up to the remote repository on github.com. Your terminal will say some stuff like Counting objects: 100% (3/3), done. and Branch 'main' set up to track remote branch 'main' from 'origin'.. This just means it all went well. Like when we added our remote origin before, we won't need to do this "--set-upstream origin main" stuff every time. From now on, simply running git push will be all we need to do to push our new changes up. (After adding and committing them, that is). Running git status again now should declare nothing to commit, working tree clean, which means everything is perfect.

Head back over to your repository on github.com and you should now be able to see your readme.md file front and center on the page. You have now successfully created a repository from your command line, made changes, added them, committed them, and pushed them up. The local and remote repositories are in sync with each other, just how they like it. Now let's do it again! A slightly different way..

Creating a new repository on github (this way is a little bit easier)

Head back over to github and create our remote repository first. Up in the top right hand corner you click Create New... > New Repository. Set yourself as the owner and call the repository git-test-2. At the top of the next screen, there will be a section that says "Quick setup — if you’ve done this kind of thing before". Make sure the little toggle box is set to SSH (not HTTPS), and click the copy/paste icon on the right hand side of the URL. This is the URL of our new remote repository, and we're going to use it to create the "local clone" on our computer.

Back over in your terminal, use cd and navigate to where ever you want to put your local version of this new repository. (Remember! Do not put this inside something that is already a git repository, for example, don't put it inside git-test). Now from your terminal, we're going to use the git clone command, and then paste in that URL from github that you copy/pasted. That would look something like git clone git@github.com:YOUR-USERNAME/git-test-2.git. You will probably receive a warning that says "warning: You appear to have cloned an empty repository.", but that's okay, we don't mind that it's empty.

If you run ls now you should be able to see your new local clone of the git-test-2 repository, and you can now hop into it with cd git-test-2. We're pretty much done! Try repeating the steps from before and use touch readme.md to add a readme file, code . to put some stuff in it, then git add -A, git commit -m "add readme.md" and git push to get your changes up onto github. Once you've checked and can see them online, do it a couple more times! Try adding some random new folders into your repo using mkdir the-name-of-a-folder and adding some new .txt files into it using the touch command. Just flail around for a while, adding stuff and pushing it up. Do this until you feel kind of comfortable with the process in general, then you're done!

In summary

You learned about local and remote repositories, what they are, how to make them, how to change them, and how to add, commit and push those changes. Next we'll cover branches on git, and how to work on a git repository collaboratively with other people.

Extra Resources (optional)

• Code School - Git Real
• Git and GitHub Crash Course for Beginners

Reflect

On the same text document as your last reflection, answer these questions:

In your reflection, answer the questions:

• What are the two different ways of creating a new git repository?
• How would you rate your understanding of everything you just did on a scale of 1-10?
• What part is the most confusing still?