Git Workshop — Hands-on Exercises

Do these in order, together

Use this handout after the slides. Run every command in a terminal (Git Bash on Windows). Do each part in order; we’ll do them together.

IDE option

Once you’re comfortable with the commands, you can do the same workflow from RStudio (Git pane) or VS Code (Source Control view). The slides cover both; try opening this repo in your IDE and stage/commit from there after we finish the terminal exercises.

Part 1 — Setup check

Make sure Git is installed and configured.

1. Check version

git --version

You should see something like git version 2.x.x.

2. Set your identity (if you haven’t already)

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

3. Confirm

git config --global --list

You should see user.name and user.email.

Tip

Use the same email as your GitHub/GitLab account so commits link to your profile.

Part 2 — First repo and first commit

Create a new folder and turn it into a Git repo, then make one commit.

1. Create a folder and go into it

mkdir my-first-repo
cd my-first-repo

2. Initialize a Git repository

git init

You should see: Initialized empty Git repository in .../my-first-repo/.git

3. Create a small file

echo "# My First Repo" > README.md

4. See what Git sees

git status

You should see README.md as “Untracked”.

5. Stage the file

git add README.md

Run git status again — the file is now “to be committed”.

6. Commit

git commit -m "Add README"

7. Look at the history

git log

You should see one commit with your message and your name/email.

Note

From now on: stage (git add) then commit (git commit -m "message"). Get used to this loop.

Part 3 — Basic workflow again

Reinforce the loop: change something, see it, stage it, commit it. Stay in my-first-repo.

1. Change a file

Edit README.md (e.g. add a line: “A small project to learn Git.”) or create a new file like notes.txt with one line.

2. See what changed

git status

You should see the file as modified or untracked.

3. See the actual diff (before staging)

git diff

If you created a new file, it won’t show in git diff until it’s tracked; git status still lists it as untracked.

4. Stage and commit

git add README.md
# or: git add notes.txt   (if you created it)
# or: git add .           (stage everything)
git status
git commit -m "Add description to README"

5. Check history

git log --oneline

You should see two commits.

Optional — Unstage or discard

To unstage a file (keep your edits, don’t commit them yet): git restore --staged README.md
To discard changes in a file (revert to last commit): git restore README.md — use with care.

Part 4 — Branches

Create a branch, make a change, then merge it back.

1. Create and switch to a new branch

git switch -c add-license

2. Add a file

echo "MIT License - use freely!" > LICENSE.txt
git add LICENSE.txt
git commit -m "Add LICENSE"

3. Switch back to main

git switch main

4. Merge the branch

git merge add-license -m "Merge add-license into main"

5. Check

git log --oneline
ls

You should see LICENSE.txt on main and the merge commit in the log.

6. (Optional) Push to remote

git push

Part 5 — SSH key and GitHub (optional)

Use SSH so you can git push / git pull without typing a password or personal access token each time. Skip this part if you are happy using HTTPS and GitHub’s browser login or a token.

1. Check for an existing key

ls -al ~/.ssh

If you see id_ed25519 and id_ed25519.pub (or id_rsa / id_rsa.pub), you may already have a key. You can reuse it or create a new one with a different file name (step 2).

2. Generate a new SSH key (recommended: Ed25519)

Replace the email with the one you use on GitHub:

ssh-keygen -t ed25519 -C "your.email@example.com" -f ~/.ssh/id_ed25519

Press Enter to accept the default path (if you used -f as above, it saves to ~/.ssh/id_ed25519).
Optionally set a passphrase (recommended): protects the key if someone copies your laptop.

Windows

Use Git Bash for these commands. The path ~/.ssh is under your user folder, e.g. C:\Users\YourName\.ssh.

3. Start the agent and add the key (macOS / Linux)

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

On macOS (Apple Silicon / recent macOS), you may use:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

so the passphrase is stored in the keychain (first time only).

On Windows (Git Bash):

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

4. Copy the public key

The file ending in .pub is safe to share; never share the private key (no .pub).

macOS: pbcopy < ~/.ssh/id_ed25519.pub then paste in GitHub (next step).
Linux: cat ~/.ssh/id_ed25519.pub and copy the whole line.
Windows (Git Bash): cat ~/.ssh/id_ed25519.pub and copy the line, or clip < ~/.ssh/id_ed25519.pub if clip works in your shell.

5. Add the key on GitHub

Log in to GitHub → click your avatar → Settings.
In the left sidebar: SSH and GPG keys.
New SSH key — give it a title (e.g. “Lab laptop”), paste the public key, save.

Official guide: Connecting to GitHub with SSH.

6. Test the connection

ssh -T git@github.com

The first time, type yes if asked to trust the host. You should see a message like: Hi username! You’ve successfully authenticated…

7. Use SSH with your repo

When you add a remote (Part 6), use the SSH URL from the green Code button on GitHub, for example:

git remote add origin git@github.com:yourname/my-first-repo.git

If you already added origin with HTTPS, change it:

git remote set-url origin git@github.com:yourname/my-first-repo.git
git remote -v

Then git push uses SSH.

Note

HTTPS with a personal access token is another valid option; SSH avoids managing tokens for every push on the command line.

Part 6 — Remote and push (optional)

Put your repo on GitHub or GitLab so you can push and pull. Do this part only if you have time and an account.

1. Create a new repo on the website

GitHub: github.com/new — create an empty repo (no README, no .gitignore).
GitLab: New project → Create blank project.

2. Copy the repo URL

HTTPS: e.g. https://github.com/yourname/my-first-repo.git (browser or token login when you push).
SSH: e.g. git@github.com:yourname/my-first-repo.git (if you completed Part 5).

3. Add the remote (use your URL)

git remote add origin https://github.com/yourname/my-first-repo.git

Or with SSH:

git remote add origin git@github.com:yourname/my-first-repo.git

4. Push your branch (first time we set upstream)

git branch -M main
git push -u origin main

With HTTPS you may be asked to log in (browser or token). With SSH, Git uses your key. After a successful push, refresh the repo page — you should see your files.

Warning

If your default branch is master, git branch -M main renames it to main. Then git push -u origin main pushes that branch and sets origin/main as upstream.

Part 7 — Simple collaboration (pair exercise, optional)

One person pushes a change; the other pulls and edits the same file, then we resolve a small conflict.

Setup: Person A and Person B. Both have access to the same repo (e.g. A owns it, B is collaborator, or use one shared repo).

Step 1 — Person A

Add a line to README.md, e.g. “Contributors: Alice”
Commit and push:

git add README.md
git commit -m "Add contributor Alice"
git push

Step 2 — Person B

Pull first (to get A’s commit):

git pull

Edit README.md and add a line, e.g. “Contributors: Alice, Bob”
Commit and push:

git add README.md
git commit -m "Add contributor Bob"
git push

Step 3 — Person A

Pull to get B’s commit:

git pull

No conflict if you edited different lines. If both edited the same line, Git will ask you to resolve a conflict (see below).

Optional — Trigger a conflict on purpose

A and B both add a line at the same place in README.md, then A pushes, B pulls, B adds their line, commits, and pushes. When A runs git pull, Git may report a conflict.
Open the file: you’ll see conflict markers <<<<<<<, =======, >>>>>>>. Edit the file to keep what you want, remove the markers, then:

git add README.md
git commit -m "Resolve conflict in README"
git push

Important

Always pull before you start and push when you finish a small chunk. That keeps conflicts smaller and easier to fix.

Done

You’ve done: setup, first commit, basic workflow (status, diff, add, commit), branches + merge, and (optionally) SSH + GitHub, remote + push, and pull/conflict resolution.

Next: Use Git for one real project (code or paper). Try opening a Pull Request on GitHub or Merge Request on GitLab for a change on a branch.