First, what are Git and GitHub?

 how Git and GitHub are used when people work on code.

First, what are Git and GitHub?

Git is a tool that tracks changes in your code.

GitHub is a website where you store Git projects online.

So:

• Git = the system that tracks changes
• GitHub = the website where the project is stored and shared

You can use it with other people, or just by yourself.

---

Big idea

When people work together on a project, they do not just edit one file randomly.

They follow a process:

1. Create or join a repository
2. Copy it to your computer
3. Make a branch
4. Edit code
5. Commit changes
6. Pull latest updates
7. Push your changes
8. Make a pull request
9. Merge into main

Now I will explain each part.

---

Step 1: Repository or “repo”

A repository is a project folder managed by Git.

People also call it a repo.

A repo stores:

• your code files
• file history
• changes over time
• branches
• project tools like issues or documentation

On GitHub, when you create a repo, it usually starts with a main branch.

The main branch should usually have the stable and working version of the project.

Think of the repo like this:

• repo = the whole project
• main branch = the official safe version

---

Step 2: Cloning

If someone already made the repo, you need to clone it.

Cloning means copying the repo from GitHub to your computer.

When you clone, Git copies:

• the files
• the branches
• the change history

So cloning is not just downloading files.
It gives you the full project history too.

Example idea:

GitHub has the project online → you clone it → now you have a copy on your computer.

---

Step 3: Branches

A branch is like a separate work area.

Instead of changing the main project directly, you make a branch and work there.

Why?

Because your code might break while you are testing new ideas.
If you work in a branch, the main branch stays safe and stable.

So:

• main branch = stable version
• new branch = your practice or work version

This is very useful in teamwork.

---

Step 4: Check-out

To work on a branch, you check out that branch.

Check-out means switching your computer to that branch.

It does not usually download everything again.
It just tells Git:

“Now I want to work in this branch.”

So if there are many branches, check-out lets you move between them.

Simple example:

• today you work on main
• tomorrow you check out feature-login
• now your files change to match that branch

---

Step 5: Commit

After you make changes, you commit them.

A commit is like saving a snapshot of your work in Git.

When you commit, Git records:

• what changed
• which files changed
• when it changed
• your commit message

The commit message is a short note explaining what you did.

Example:

• “Fixed input error”
• “Added greeting function”
• “Updated README”

Commits are very important because they help you:

• save progress
• go back to older versions
• understand what changed

The text says it is good to commit often.

Why?

Because if something goes wrong, you lose less work.

---

Step 6: Pull before you push

This is very important in teamwork.

If other people are also changing the same branch, your copy may be old.

So before sending your changes, you should pull the latest version first.

Pull means getting the newest updates from GitHub to your computer.

This helps prevent conflicts.

That is why people say:

“Pull before you push.”

Meaning:

• first get the newest code
• then add your work on top of it
• then send your changes

---

Step 7: Push

After your commits are ready, you push them.

Push means uploading your local commits from your computer to GitHub.

So:

• commit = save changes on your computer
• push = send those saved changes to GitHub

This keeps the online branch updated.

Without pushing, your work stays only on your own computer.

---

Step 8: Pull request

When your branch is finished and working well, you make a pull request.

A pull request means:

“Please take my branch changes and add them into the main branch.”

The name sounds confusing, yes.
You are really asking for your code to be pulled into the main branch.

A pull request lets others:

• review your code
• test your code
• discuss changes
• approve or reject it

If you work alone, you may approve your own pull request.

---

Step 9: Merge

After the pull request is accepted, the branch is merged into the main branch.

Merge means combining your branch changes into the main branch permanently.

After merging:

• your work becomes part of the main project
• the stable version now includes your improvements

That is the final step.

---

Full process in simple order

Here is the whole process in easy order:

1. Create a repo

This starts the project on GitHub.

2. Clone the repo

This copies the project to your computer.

3. Create a branch

This gives you a safe place to work.

4. Check out the branch

This switches you to that branch.

5. Edit your code

You make your changes.

6. Commit the changes

You save your work with a message.

7. Pull latest updates

You make sure your branch is up to date.

8. Push your commits

You upload your work to GitHub.

9. Create a pull request

You ask to add your changes into main.

10. Merge

Your code becomes part of the main branch.

---

Important vocabulary in very simple meaning

Repo

The whole project.

Main branch

The official working version.

Clone

Copy the repo to your computer.

Branch

A separate place to work safely.

Check-out

Switch to a branch.

Commit

Save your changes in Git.

Pull

Get the newest changes from GitHub.

Push

Send your commits to GitHub.

Pull request

Ask to move your branch changes into main.

Merge

Combine your branch into main.

---

What your class is saying

Your class says that in this course, you will use GitHub mainly to submit assignments.

So you will probably not use every collaborative step.

The passage says:

• you will not work collaboratively
• you will not make branches
• you do not need to worry about check-out and merge much

That means your class uses a simpler GitHub process.

Probably something like:

1. create repo
2. add your files
3. commit
4. push to GitHub
5. submit

So your class is teaching the full idea, but you may only use part of it.

---

Easy real-life example

Imagine a group is building a website.

Main branch

This is the working website everyone trusts.

Your branch

You want to add a login page.

You do this:

1. clone the repo
2. create a new branch called login-page
3. check out login-page
4. write the login code
5. commit your work
6. pull new updates in case others changed something
7. push your branch to GitHub
8. open a pull request
9. team leader reviews it
10. merge into main

Now the main website has your login page.

---

Why branches are useful

Branches are useful because they protect the main code.

Without branches:

• one mistake can break the project
• teamwork becomes messy

With branches:

• people can work safely
• many people can work at the same time
• changes can be reviewed before becoming official

---

Why commit messages matter

A commit message tells what you changed.

Good examples:

• “Fixed typo in output”
• “Added input validation”
• “Created main function”
• “Updated docstrings”

Bad example:

• “stuff”
• “changes”
• “update”

Good commit messages help you and others understand the history.

---

Why pull before push matters

Imagine your friend changed line 10 of a file.
You also changed line 10.
If you push without pulling first, Git may find a conflict.

So pulling first helps you see the newest version and fix problems before uploading.

That is why this rule is important in team projects.

---

One-sentence meaning of each step

• Repo = project
• Clone = copy project to your computer
• Branch = separate work area
• Check-out = switch to that area
• Commit = save your changes
• Pull = get latest updates
• Push = upload your changes
• Pull request = ask to add your work to main
• Merge = combine into main

---

Very short summary

GitHub helps people work on code in an organized way.

The usual process is:

• make or join a repo
• clone it
• work in a branch
• commit changes
• pull latest updates
• push to GitHub
• create a pull request
• merge into main

Your class is using GitHub in a simpler way, mostly for assignment submission, so you may not need all the teamwork steps.

If you want, I can also make this into a very short study note or a simple diagram.