In this lesson, we’ll cover common Git commands used to manage your projects and to upload your work onto GitHub. We refer to these commands as the basic Git workflow. When you’re using Git, these are the commands that you’ll use 70-80% of the time. So if you can get these down, you’ll be more than halfway done mastering Git!
This section contains a general overview of topics that you will learn in this lesson.
- How to create a repository on GitHub
- How to get files to and from GitHub
- How to take “snapshots” of your code
Before You Start!
- Github recently updated the way it names the default branch. This means you need to make sure you are using a recent version of git (2.28 or later). You can check your version by running:
- If you haven’t already, set your local default git branch to
main. You can do so by running:
git config --global init.defaultBranch main
- For more information on the change from
mainsee GitHub’s Renaming Repository.
Create the Repository
Create a new repository by clicking the button shown in the screenshot below.
Give your repository the name “git_test” in the repository name input field. Check “Add a README file”. And then create the repository by clicking the green “Create repository” button at the bottom of the page.
This will redirect you to your new repository on GitHub. To get ready to copy (clone) this repository onto your local machine, click the green “Code” button. Then select the SSH option, and copy the line below it. NOTE: You MUST click the SSH option to get the correct URL.
Let’s use the command line on your local machine to create a new directory for all of your Odin projects. Create a directory called
mkdircommand in your home folder. If you’re not sure if you’re in your home folder, just type
cd ~. Once it’s made, move into it with the
Now it’s time to clone your repository from GitHub onto your computer with
git clonefollowed by the URL you copied in the last step. The full command should look similar to
git clone firstname.lastname@example.org:USER-NAME/REPOSITORY-NAME.git. If your URL looks like
https://github.com/USER-NAME/REPOSITORY-NAME.git, you have selected the HTTPS option, not the required SSH option.
That’s it! You have successfully connected the repository you created on GitHub to your local machine. To test this, you can
cdinto the new git_test folder that was downloaded and then enter
git remote -von your command line. This will display the URL of the repository you created on GitHub, which is the remote for your local copy. You may have also noticed the word origin at the start of the
git remote -voutput, which is the name of your remote connection. The name “origin” is both the default and the convention for the remote repository. But it could have just as easily been named “party-parrot” or “dancing-banana”. (Don’t worry about the details of origin for now; it will come up again near the end of this tutorial.)
Use the Git Workflow
Create a new file in the
git_testfolder called “hello_world.txt” with the command
git statusin your terminal. In the output, notice that your hello_world.txt file is shown in red, which means that this file is not staged.
git add hello_world.txt. This command adds your hello_world.txt file to the staging area in Git. The staging area is part of the two-step process for making a commit in Git. Think of the staging area as a “waiting room” for your changes until you commit them. Now, type
git statusagain. In the output, notice that your file is now shown in green, which means that this file is now in the staging area.
git commit -m "Add hello_world.txt"and then type
git statusonce more. The output should now say: “nothing to commit, working tree clean”, indicating your changes have been committed. Don’t worry if you get a message that says “upstream is gone”. This is normal and only shows when your cloned repository currently has no branches. It will be resolved once you have followed the rest of the steps in this project.
The message, “Your branch is ahead of ‘origin/main’ by 1 commit” just means that you now have newer snapshots than what is on your remote repository. You will be uploading your snapshots further down in this lesson.
git logand look at the output. You should see an entry for your “Add hello_world.txt” commit. You will also see details on the author who made the commit and the date and time of when the commit was made. If your terminal is stuck in a screen with (END) at the bottom, just press “q” to escape. You can configure settings for this later, but don’t worry about it too much for now.
Modify a File or Two
Open README.md in your text editor of choice. In this example, we will open the directory in Visual Studio Code by using the command
code .inside your repository.
MacOS users: If your terminal reads “command not found: code”, you must head back to Command Line Basics and follow the instructions provided to allow this command to work.
Add “Hello Odin!” to line 3 of README.md and save the file with “Ctrl+S” (or “Command+S” on Mac).
Back in your terminal (or in the fancy built-in terminal in Visual Studio Code with *Ctrl + ` * ), type
git status. You’ll notice that README.md is now shown as not staged or committed.
Add README.md to the staging area with
git add README.md.
Can you guess what
git statuswill output now? README.md will be displayed in green text. That means README.md has been added to the staging area. The file hello_world.txt will not show up because it has not been modified since it was committed.
Open hello_world.txt, add some text to it, save it and stage it. You can use
git add .to add all files in the current directory and all subsequent directories to the staging area. Then, type
git statusonce more, and everything should now be in the staging area.
Finally, let’s commit all of the files that are in the staging area and add a descriptive commit message.
git commit -m "Edit README.md and hello_world.txt". Then, type
git statusonce again, which will output “nothing to commit”.
Take one last look at your commit history by typing
git log. You should now see three entries.
Push Your Work to GitHub
Finally, let’s upload your work to the GitHub repository you created at the start of this tutorial.
git push. To be more specific, type
git push origin main. Since you are not dealing with another branch (other than main) or a different remote (as mentioned above), you can leave it as
git pushto save a few keystrokes. NOTE: If at this point you receive a message that says “Support for password authentication was removed on August 13, 2021. Please use a personal access token instead.”, you have followed the steps incorrectly and cloned with HTTPS, not SSH. Please follow these steps to change your remote to SSH, then attempt to push to Github.
git statusone final time. It should output “Your branch is up to date with ‘origin/main’. nothing to commit, working tree clean”.
When you reload the repository on GitHub, you should see the README.md and hello_world.txt files that you just pushed there from your local machine.
When trying to make simple changes to the files in your repo, such as attempting to fix a typo in your README.md you might be tempted to make this change directly via Github. However, it is best to avoid this as it will cause issues that require more advanced Git knowledge than we want to go over at this stage (it is covered in a future lesson), for now it is advised to make any changes via your local files then commit and push them using Git commands in your terminal once ready.
This is a reference list of the most commonly used Git commands. (You might consider bookmarking this handy page.) Try to familiarize yourself with the commands so that you can eventually remember them all:
- Commands related to a remote repository:
git clone email@example.com:USER-NAME/REPOSITORY-NAME.git
git push origin main(Both accomplish the same goal in this context)
- Commands related to the workflow:
git add .
git commit -m "A message describing what you have done to make this snapshot different"
- Commands related to checking status or log history
The basic Git syntax is
program | action | destination.
git add .is read as
git | add | ., where the period represents everything in the current directory;
git commit -m "message"is read as
git | commit -m | "message"; and
git statusis read as
git | status | (no destination).
There’s a lot to learn about using Git. But it is worth taking the time to highlight some best practices so that you can be a better collaborator. Git is not only helpful when collaborating with others. It’s also useful when working independently. You will be relying more and more on your own commit history in the future when revisiting old code.
Two helpful best practices to consider are atomic commits and leveraging those atomic commits to make your commit messages more useful to future collaborators.
An atomic commit is a commit that includes changes related to only one feature or task of your program. There are two main reasons for doing this: first, if something you change turns out to cause some problems, it is easy to revert the specific change without losing other changes; and second, it enables you to write better commit messages.
If you are using Visual Studio Code (and you should be if you’re following this curriculum) and you don’t want to get stuck writing a commit message in Vim because you accidentally used
git commit without the message flag (
-m), this command will make Visual Studio Code open a new tab with the ability to write your commit message and an optional description below it:
git config --global core.editor "code --wait".
There will be no confirmation or any output on the terminal after entering this command. To make a commit with Visual Studio Code as the text editor, make sure to use the
git commit command without the
-m flag. Just type
git commit and no message after that. Once you do this, a new tab will open. Now you can write your message, and provide more information if you want, right below it. After typing your commit message, save it and exit the tab.
With that out of the way, now you can choose to use either
git commit -m <your message here> or
git commit and enter your message with Visual Studio Code!
You may not feel completely comfortable with Git at this point, which is normal. It’s a skill that you will get more comfortable with as you use it.
The main thing to take away from this lesson is the basic workflow. The commands you’ve learned here are the ones you will be using the most often with Git.
Don’t worry if you don’t know all the commands yet or if they aren’t quite sticking in your memory yet. They will soon be seared into your brain as you use them over and over in future Odin projects.
In later Git lessons, we will cover some of the more advanced Git features, such as branches. They will further expand your abilities and make you more productive.
For now, concentrate on using the basics of Git that you’ve learned here for all of your projects from now on. You will soon know each of the basic Git commands from memory!
This section contains questions for you to check your understanding of this lesson on your own. If you’re having trouble answering a question, click it and review the material it links to.
- How do you create a new repository on GitHub?
- How do you copy a repository onto your local machine from GitHub?
- What is the default name of your remote connection?
- Explain what
git push origin main.
- Explain what
git push origin main.
- Explain the two-stage system that Git uses to save files.
- How do you check the status of your current repository?
- How do you add files to the staging area in git?
- How do you commit the files in the staging area and add a descriptive message?
- How do you push your changes to your repository on GitHub?
- How do you look at the history of your previous commits?
This section contains helpful links to related content. It isn’t required, so consider it supplemental.
- It looks like this lesson doesn’t have any additional resources yet. Help us expand this section by contributing to our curriculum.