Create the Repository

You should have already created a GitHub account in the Setting up Git lesson. If you haven’t done that yet, you can sign up here.

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, and 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 copy this repository onto your local machine, select the SSH option and copy the line next to it. Copy SSH link using GitHub
In the command line on your local machine, navigate to where you want to store this project, and then clone your repository on GitHub onto your computer with git clone followed by the URL you copied in the last step. The full command should look similar to git clone 

git@github.com:USER-NAME/REPOSITORY-NAME.git. 

That’s it! You have successfully connected the repository you created on GitHub to your local machine. To test this, you can cd into the new git_test folder that was downloaded and then enter git remote -v in your command line. This will display the URL of the repository you created in GitHub, which is the remote for your local copy. You may have also noticed the word origin at the start of the git remote -v output, 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.) Check repo remotes using CLI

Use the Git Workflow

Create a new file in the git_test folder called “README.md” with the command touch README.md. Type git status in your terminal. In the output, notice that your README.md file is shown in red, which means that this file is not staged. Check status of repo using CLI
Type git add README.md. This command adds your README.md 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 like a “waiting room” for your changes until you commit them. Now, type git status again. In the output, notice that your file is now shown in green, which means that this file is now in the staging area. Stage README and check repo status again using CLI
Type git commit -m "Add README.md" and then type git status once more. The output should now say, “nothing to commit, working tree clean”, indicating that your changes have been committed. Don’t worry about the upstream is gone message you may see, this is totally normal and only showing because your cloned repository currently has no branches. It will be resolved once you have followed the rest of the steps in this project. Commit README and check repo status again using CLI

Type git log and look at the output. You should see an entry for your “Add README.md” commit. You will also see details on the author who made the commit and the date and time for when the commit was made.

Add Another File

Create a new file in the git_test folder called hello_world.txt. In the terminal, type git status, and notice hello_world.txt is not staged. Add text file and check repo status again using CLI
Open README.md in your text editor of choice and add the text “This is (YourUsername)’s first git project!” and then save the file. Edit README using text editor

Back in your terminal, type git status, and notice that README.md is now shown as modified, and not staged or committed. This is because you made a change to it, and it is already a tracked file. Check repo status again using CLI

Add README.md to the staging area with git add README.md.
Can you guess what git status will output now? README.md will be displayed in green text, while hello_world.txt will still be in red. This means that only README.md has been added to the staging area. Stage README changes and check repo status again using CLI

Now, add hello_world.txt to the staging area with a slightly different command: git add ., where the full stop means to add all files in the current directory that are not staged. Then, type git status once more, and everything should now be in the staging area. (Note: You can use git add -A to add ALL unstaged files to the staging area within the repository) Stage all other files in repo and check repo status again using CLI

Finally, let’s commit all of the files that are in the staging area and add a descriptive commit message git commit -m "Add hello_world.txt and edit README.md". Then, type git status once again, which will output “nothing to commit”. Commit repo changes again and check repo status again using CLI
Take one last look at your commit history by typing git log. You should now see two entries.

Push Your Work to GitHub#

Finally, let’s upload your work to the GitHub repository you created at the start of this tutorial.

Type git push origin main. Push changes to remote using CLI
Type git status one final time. It should output “nothing to commit, working tree clean”. Check repo status again to confirm local repo is up to date with remote using CLI

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. Verify repo changes are on GitHub

Cheatsheet

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 git@github.com:USER-NAME/REPOSITORY-NAME.git or git clone https://github.com/user-name/repository-name.git
git push origin main

Commands related to 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
git status
git log
The basic Git syntax is program | action | destination.

For example,

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 status is read as git | status | (no destination).
Conclusion

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, which will further expand your abilities and make you more productive.

For now, concentrate on using the basics of Git that you’ve learned here with all of your projects from now on. You will soon know each of the basic Git commands from memory!