Git and GitHub basics

Back to Resources

Goal: save a clear history of your work and share a checked change. Use a practice repository first. The commands work in Windows PowerShell, macOS Terminal, and Linux terminals.

Contents

1. Learn the main words
2. Set up Git and GitHub
3. Clone a repository
4. Save and upload a change
5. Use branches and pull requests
6. Use GitHub in your browser
7. Keep the right files in Git
8. Fix common problems

1. Learn the main words

Git runs on your computer and records changes to files. GitHub stores Git repositories online and lets people review work together. They are different tools. A Git commit does not upload anything until you push it.

Read About Git and What is GitHub? for the full definitions.

2. Set up Git and GitHub

1. Create a GitHub account and verify your email.
2. Install Git. Open a new terminal and run git --version.
3. Install VS Code and open its terminal. Follow the VS Code guide if needed.
4. Accept your lab repository invitation. Keep research source files and meeting notes in the private repository assigned to you.
5. For this lesson only, create a private repository named git-practice on GitHub. Select Add a README file so it starts with a commit.

Use your assigned lab repository for real work. Do not make a second copy of a lab project under another owner unless the professor asks you to.

3. Clone a repository

1. On GitHub, open the repository and select Code > HTTPS. Copy the address.
2. Open a terminal in the folder where you keep projects.
3. Run the following example. Replace YOUR-USERNAME with your actual GitHub username, or use the repository address you copied.

git clone https://github.com/YOUR-USERNAME/git-practice.git
cd git-practice
git remote -v
git branch --show-current
code .

1. Check that origin points to the correct repository. This guide uses main as the default branch; use the actual default branch if yours has another name.
2. Set your name and email for this clone. Replace both example values. Use a GitHub-verified email or the no-reply address shown in your GitHub email settings.

git config user.name "Your Full Name"
git config user.email "YOUR-GITHUB-VERIFIED-EMAIL"

1. If a browser sign-in opens during clone or push, sign in with the account that has access. Do not use your normal GitHub password as a Git HTTPS password. Use Git Credential Manager, GitHub Desktop, or the lab’s approved SSH setup.

Check: VS Code shows the project files. The terminal is inside the cloned folder. git status works there.

Sources: Cloning, GitHub authentication.

4. Save and upload a change

Use this sequence in your own practice repository. For a shared lab repository, use the branch process in section 5.

A. Get the latest version

git status

Continue when Git says the working tree is clean. If you have unfinished edits, finish and commit them first, or ask for help. Then run:

git pull --ff-only

This gets remote work without creating an extra merge commit. If it fails, stop and read the error.

B. Edit and review

1. Open README.md in VS Code.
2. Add your name and one sentence about what you are learning.
3. Save the file. Saving a file is not the same as making a Git commit.
4. Review the change:

git status
git diff

C. Stage and commit

Choose the file you want to save in Git, then inspect the staged change:

git add README.md
git diff --staged
git commit -m "Add my learning goal"

If you edit the file again after staging, run git add README.md again to include that new edit. Use a short commit message that explains the change.

D. Push and check

git push
git status
git log --oneline -5

Open the repository on GitHub. Check that the file and commit message are visible. A successful push is your upload check. For a website, also open Actions and check its deployment; a commit alone does not prove the website published successfully.

Sources: Check status, stage files, make a commit, and push commits.

5. Use branches and pull requests

Use this route for shared projects or changes that need review.

1. Start with a clean working tree. Switch to the default branch and get the latest version.
2. Create a short branch name that explains the task.

git status
git switch main
git pull --ff-only
git switch -c update-reading-notes

1. Edit README.md, save, review, and commit it. Replace the file path if your task changes another file.

git diff
git add README.md
git diff --staged
git commit -m "Add reading notes"
git push -u origin update-reading-notes

1. Open the repository on GitHub. Select Compare & pull request, or open Pull requests > New pull request.
2. Set base to main and compare to update-reading-notes. Check the changed files.
3. Write what changed and how you checked it. Create the PR and request the agreed reviewer.
4. Fix review comments on the same branch. Commit and push again; the PR updates.
5. Let the agreed maintainer merge it. In your practice repository, you can review and merge your own practice PR.
6. After the merge, return to the default branch and update your local copy:

git switch main
git pull --ff-only

Check: your change is on main on GitHub and on your computer. A push to a feature branch does not change main until the PR is merged. git pull and a pull request are different actions.

Sources: GitHub’s first PR lesson, creating a pull request.

6. Use GitHub in your browser

Use a browser for a small text edit when you do not need to run code.

1. Open the file in the repository. Select its edit button.
2. Make one small change and preview it.
3. Select Commit changes. For shared work, choose a new branch and open a PR for review.
4. After the browser change or PR is merged into the default branch, run git status, then git pull --ff-only from a clean default branch before your next local edit. Browser changes do not appear on your computer until you get them.

To report a problem, open Issues > New issue. Write what you expected, what happened, the steps to repeat it, and the exact error. Keep passwords and private data out of the issue.

For a student website, continue with the student and internship site guide. It explains the two configuration files, private meeting notes, and Pages deployment.

7. Keep the right files in Git

Commit code, approved text, configuration, and package files. Put local environments, cache files, and secret files in .gitignore:

.venv/
__pycache__/
.env

Keep private research data in the storage approved for the project. Do not upload passwords, access tokens, or a whole Python environment.

A .gitignore rule does not remove a file already tracked by Git. Deleting a secret in a later commit also leaves it in old history. If a secret was uploaded, tell the maintainer and replace or revoke it first. Ask for help with history cleanup.

8. Fix common problems

Avoid git reset --hard, git clean -fd, and force push while learning. These can remove work or rewrite shared history. Ask for a checked recovery plan instead.

Sources: Unstage with Git restore, rejected pushes, removing sensitive data.