INTRODUCTION

Tuesday, October 8, 2024 9:38 AM

Git is a powerful version control system used by developers to track changes in code and collaborate on
projects. Here's a simple explanation for complete beginners:

What is Git?
Git helps you manage changes to files (like code, documents, or any other type of files) over time.
Imagine you're writing a book, and each day you make changes or additions. Git allows you to save
snapshots of your work at different stages, so you can go back and look at or restore an earlier version if
needed.

Why Use Git?

- Tracking Changes: Every time you save (or "commit") your work, Git records the changes you've made.
This means you can always go back to any previous version of your files.
- Collaboration: If you're working with other people on a project, Git helps everyone work on the same
project without overwriting each other's work. Git can merge everyone’s contributions together.
- Backup: Git provides a backup of your work. Even if you delete something locally, you can still recover
it from the Git history.

Key Concepts in Git

1. Repository (Repo): This is where Git stores your project and its history. Think of it as a folder for your
project that Git is tracking.
2. Commit: A commit is like a "save point" in a video game. You save your progress so that you can
return to this point if needed. It contains a snapshot of your files at a particular time.
3. Branch: A branch is like a separate copy of your project. You can make changes in one branch without
affecting the main branch. Once you're done, you can merge the changes back.
4. Merge: Merging is when you combine changes from one branch into another. It's useful when you're
done working on a feature and want to integrate it back into the main project.
5. Remote Repository: This is a version of your repository that's hosted on a server (like GitHub or
GitLab), allowing you to share your work with others or keep a backup online.

Basic Git Commands

1. git init: Initializes a new Git repository in your project folder.
2. git add: Stages changes (files) to be committed. You can think of it as preparing files to be saved.
3. git commit -m "message": Saves a snapshot of the project. The message describes what changes you
made.
4. git status: Shows the status of your files, like which files are modified, staged, or untracked.
5. git push: Sends your commits to a remote repository (like GitHub), so others can access them.
6. git pull: Downloads the latest changes from the remote repository to your local machine.

How It Works Together

- Initialize a Git repository in your project folder (`git init`).
- Add changes (like new files or edits) to be tracked (`git add`).
- Commit the changes with a message describing what you did (`git commit -m "Added new feature"`).
- If you're working with others, you can push your changes to a remote repository (like GitHub), and
they can pull your changes to their machine, or vice versa.

Git helps developers stay organized, keep track of their work, and collaborate efficiently.
Key Git Concepts

1. Working Directory
This is the place where you are actively working on your project files. It's simply the directory or folder
on your computer where Git is tracking changes.
• When you open your project, you’re in the working directory.
• Any file you create, modify, or delete in this folder will be noticed by Git, but those changes aren't
officially "saved" (committed) yet.
2. Staging Area (Index)
The staging area (sometimes called the "index") is like a rough draft. It’s a place where you prepare files
before committing them. When you make changes in the working directory, you tell Git which changes
you want to include in your next snapshot (commit) by adding them to the staging area.
• git add: This command adds files to the staging area. You are basically saying, "I want to include
these changes in the next commit."
• The staging area allows you to group specific changes together before making them permanent
with a commit. You might edit 10 files, but only stage (add) 2 of them, committing just those
changes.
3. Commit
A commit is like a checkpoint or snapshot of the project at a specific point in time. After adding changes
to the staging area, you make the changes permanent with a commit.
• git commit -m "Your message here": This takes everything in the staging area and saves a
snapshot of it in the repository with a message describing what you’ve done (e.g., "Added user
login feature").
• Commits are how Git tracks the history of your project. Each commit is a separate version of your
project, and you can return to any previous commit at any time.
4. Repository (Repo)
The repository is where Git stores all your commits. It holds the complete history of your project and
tracks every version of every file.
There are two types of repositories:
• Local Repository: The Git repository on your computer.
• Remote Repository: A repository hosted on a server (like GitHub, GitLab, or Bitbucket) that allows
you to share your work with others or keep a backup.
Putting It All Together
Here’s a typical workflow in Git:
1. Working Directory: You create or edit files in your project folder (your working directory).
2. Staging Area: When you're happy with your changes, you run git add <filename> to add those
changes to the staging area. Git is now aware of these changes but hasn’t yet permanently
recorded them.
3. Commit: When you're ready, you run git commit -m "Descriptive message" to permanently save a
snapshot of the files in the staging area. This snapshot now lives in the Git repository as part of the
project’s history.
4. Push to Remote: If you're collaborating with others, you’ll then run git push to upload your
commits to a remote repository like GitHub.
Example Workflow
Let's say you're building a website and working on two features: a header and a footer. You may want to
commit these changes separately. Here's how the staging area helps you do that:
 1. Modify files in your working directory: You work on header.html and footer.html in your project
folder.
2. Stage the header: You want to commit the header first, so you stage it using git add header.html.
Now, only the header is in the staging area.
3. Commit the header: You commit the staged header file using git commit -m "Added header
section".
4. Stage the footer: Now you stage the footer using git add footer.html.
5. Commit the footer: Finally, you commit the footer with git commit -m "Added footer section".
Now, you have two separate commits: one for the header and one for the footer, which makes it easier
to track changes.
More Git Concepts
5. Untracked vs. Tracked Files
• Untracked files are new files you've created in the working directory, but Git isn’t tracking them
yet. You need to use git add to start tracking them.
• Tracked files are files that Git already knows about, either because they were part of a previous
commit or were added to the staging area.
6. Unstaged Changes
Unstaged changes are modifications made to files that Git is already tracking but haven’t been added to
the staging area yet.
• Example: You modify a file that was already committed, but until you run git add, those changes
are considered unstaged.
7. Branch
A branch in Git is like a separate timeline of your project. You can create a branch, make changes in that
branch, and merge it back into the main project later. This is especially useful when working on new
features or bug fixes.
• Master/Main branch: The main branch where all the final, stable code lives.
• Feature branch: A branch you create to work on a specific feature or fix. Once done, you can
merge it into the main branch.
Summary
• Working Directory: Where you make changes to files.
• Staging Area: Where you add files you want to commit.
• Commit: A snapshot of the staged changes.
• Repository: Stores all the commits, which are the history of your project.

Assignment
Create the repository
1. You should have already created a GitHub account from the first Video.
2. From the GitHub homepage, create a new repository by clicking the “+” button in the top-
right corner and selecting “New repository”. If you are using a smaller viewport, that
button may be hidden. In that case click on your profile picture in the top-right corner and
the button will appear next to your profile name.
 3. Give your repository the name “git_test” in the repository name input field. Check “Add a
README file”. Then create the repository by clicking the “Create repository” button at the
bottom of the page.
4. 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, which should be to the
right of the button displaying the current branch (typically it will display the main branch).
Then select the SSH option in the “Clone” section, and copy the line below it. NOTE: You
MUST click the SSH option to get the correct URL.
5. 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 repos with the mkdir command in your home folder.
Your home folder is represented by ~. Note that depending on your OS, there may be
some home directory variation - sometimes ~ stands for /Users/your_username and
sometimes it stands for /home/your_username. If you’re not sure if you’re in your home
folder, just type cd ~. Once it’s made, move into it with the cd command.
mkdirrepos
cdrepos/

Copy
6. Now it’s time to clone your repository from GitHub into your newly created repos directory
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. If your URL looks
like https://github.com/USER-NAME/REPOSITORY-NAME.git, you have selected the HTTPS option,
not the required SSH option.
gitclone git@github.com:USER-NAME/REPOSITORY-NAME.git

Copy
7. That’s it! You have successfully connected the repository you created on GitHub to your
local machine. To test this, cd into the new git_test folder that was downloaded and then
enter git remote -v on your command line. You should see an output similar to the
following, where USER-NAME is your GitHub username:
origin git@github.com:USER-NAME:git_test.git (fetch)origin
git@github.com:USER-NAME:git_test.git (push)
Copy
This displays 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 -
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.)
Use the Git workflow
8. Create a new file in the git_test folder called “hello_world.txt” with the command touch
hello_world.txt.
9. Type git status in your terminal. In the output, your hello_world.txt file should be shown with
a red text color as well as listed in a section titled “Untracked files”. This means that the
file is not yet staged.
10. Type 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 status again. In the output, notice that your file is now shown in green and in a
 section titled “Changes to be committed”, which means that this file is now in the staging
area.
11. Type git commit -m "Add hello_world.txt" and then type git status once 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.
12. Type git log and look at the output. You should see an entry for your “Add hello_world.txt”
commit. You will also see other details which include 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
13. 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.
14. Add “Hello Odin!” to a new line in README.md and save the file
with Ctrl + S (Mac: Cmd + S).
15. Go back to your terminal, or if you’re using Visual Studio Code, open the built-in terminal
by pressing Ctrl + ` (backtick). Then type git status. Notice how the output is similar to when
we created our hello_world.txt file before adding it to the staging area, except
the README.md file is listed in a section titled “Changes not staged for commit”. The
meaning is similar to the “Untracked files” section in that the file is not yet added to the
staging area.
16. Add README.md to the staging area with git add README.md.
17. Can you guess what git status will output now? README.md will be displayed in green text in
the section titled “Changes to be committed”. 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.
18. 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 status once more, and everything should now be in the staging area.
19. 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 status once
again, which will output the same “nothing to commit” message as when we previously
made a commit.
20. 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.
21. Type 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 push to 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 the steps for switching remote URLs from HTTPS to
SSH to change your remote to SSH, then attempt to push to Github.
22. Type git status one final time. It should output “Your branch is up to date with ‘origin/main’.
nothing to commit, working tree clean”.
23. When you refresh your repository page on GitHub, you should see the README.md and
hello_world.txt files that you just pushed there from your local machine.

From <https://www.theodinproject.com/lessons/foundations-git-basics>