---
title: "Jam 00 - Exercise 4 - Git Setup and Configuration"
tags:
- 4 🥳 done
- jam00
- setup
- git
- tools
---
<!-- markdownlint-disable line-length single-h1 no-inline-html -->
<!-- markdownlint-configure-file { "ul-indent": { "indent": 4 }, "link-fragments": {"ignore_case": true} } -->

# Exercise 4 - Git Setup and Configuration

{%hackmd dJZ5TulxSDKme-3fSY4Lbw %}

## Overview - Exercise 4

In this exercise, you'll set up Git version control for your coursework. Git is the industry standard for managing source code, enabling you to:

- Track changes to your code
- Collaborate with others
- Maintain a history of your work
- Share code professionally

### 🔑 **Why Git Matters**

- Required by most software companies
- Essential for team collaboration
- Protects against code loss
- Enables code review and feedback
- Helps track and fix bugs

📚 You'll learn more about Git and version control in Chapter 1 of your Zybooks textbook. For now, just focus on following these setup steps carefully.

### Understanding Git Repositories

Before we begin the setup, let's understand what we're building. In Git, **repositories** are special databases that store:

- All files needed to build your system
- The complete history of your code
- Every version of every file you track

This is crucial for two main reasons:

1. **Protection Against Mistakes**: When (not if!) you create bugs in your code, Git lets you:
- Compare current code to previous versions
- Understand what changes caused problems
- Revert to working versions if needed

2. **Team Collaboration**: Repositories enable teams to:
- Share code efficiently
- Track who made what changes
- Keep everyone's code in sync

:::danger
🚨 **Critical Course Requirements**

- **VPN Access**: Required for off-campus work. Set up before leaving campus: [VPN Setup Guide](https://bucknell.teamdynamix.com/TDClient/40/LIT/KB/ArticleDet?ID=300)
- **Grading**: Only files committed AND pushed to GitLab are graded - no exceptions!
- **Personal Laptops**: Technical issues on your own computer are not valid excuses for late work

:::

## Required Steps - SSH Key Setup

Our Git server uses **ssh** (Secure Shell) to:

- Securely identify you to the server
- Encrypt data between your computer and the server
- Protect your code and credentials

You'll learn more about SSH in future networking and operating systems courses. For now, just follow these steps to generate your **ssh keypair**.

:::danger
🚨 **Setup Complexity Warning**
These steps are tedious and must be done precisely. Pay close attention - this is the only time in the course you'll need to deal with this level of setup detail.
:::

1. Open your terminal
2. Check for existing keys:

    ls -la ~/.ssh

3. If no keys exist, generate them:
- **Note:** We're using ED25519 keys as they're more secure and modern than RSA keys.
- Press ENTER at all prompts to accept defaults

    ssh-keygen -t ed25519

> 🔍 **Checkpoint**: Verify you have these files:
>
> - `~/.ssh/id_ed25519`
> - `~/.ssh/id_ed25519.pub`

## Required Steps - GitLab Setup

Now, we're going to set up your remote Git repository for the semester to store your individual work. This course uses a campus-wide installation of GitLab to store our remote Git repositories.

1. Visit [gitlab.bucknell.edu](https://gitlab.bucknell.edu) and sign in with Bucknell credentials
2. Select your **Profile** icon (typically top-right), then select **Edit profile.**
3. In the Main Setting section, update your profile with full name and click "Update profiles settings" to save the changes.
4. On the left side of the page, select **SSH Keys**
5. Click **Add new key**
6. Copy your public key:
You will need to **CAREFULLY** copy and paste your **public** ssh key contents into the appropriate box on the page. From your terminal window, type the following:

    cat ~/.ssh/id_ed25519.pub

- The `cat` command will display the contents of the file.
- If you did it correctly, a long string of random characters will appear spanning several lines.
- Copy and paste the key (exactly as displayed) into GitLab's **Key** section
- Title the key with something useful. Note: this key is tied to the device you created it on. I name my keys like "macbook-pro-2024" or "linux-lab-2025".
- Add an expiration date if you want. If you set an expiration date, you will need to re-add the key to GitLab after the expiration date. Note: You can readd the key you just made or you can generate a new one.
- Click **Add key**
- Do not continue until you have a key in Your SSH keys.

## Required Steps - Creating your first repository

1. On the top of the screen, click on the "+" icon, then select **New project/repository** button
2. Select "New Project/Repository"
3. Click "Create blank project""
- Name: `csci205_jams`
- Project URL: If you have a dropdown next to `https://gitlab.bucknell.edu/` then select your userid in the dropdown. If you don't have a dropdown, then this should already be set to your userid.
- Visibility: Private
- Initialize with README: No
- Your screen should look like this (but with your userid in the Project URL)
- It is VITAL that the two fields marked with orange arrows are set correctly. Using a different name will effect our ability to grade your work.
4. After ensuring all the settings are correct, click **Create project**. GitLab will be busy creating the project on the server. It should switch to the main project screen for your new csci205_jams project. See the next image for what should be displayed once successfully created.
5. **Copy Repository URL**
- Click "Clone" button
- Copy the SSH URL
- It should look something like this:

        [e-mail]:*userid*/csci205_jams.git

>[!Important] Question 2.1
>Copy the SSH URL for your repository into your `answers.txt` file

:::info
🔧 **Learning Tip**: Bookmark this page

I recommend you keep a bookmark to this page you have opened, as it will be valuable throughout the semester.
:::

:::danger
🚨 **WARNING: NEVER MAKE CHANGES TO ANY FILES USING THE GITLAB INTERFACE!**

It's tempting, but resist! Any changes you make must be made to your files in your repository on your local repository only.
**This is the way.**
:::

## Required Steps - Git Configuration

Git needs some basic configuration before first use. From your terminal, ensure you're in your csci205_jams directory.

1. **Start by setting the default branch name**

    git config --global init.defaultBranch main

**Why 'main'?** The software industry has moved away from 'master' to 'main' as the default branch name. This change promotes inclusive language in technical contexts.

2. **Next, configure your identity**
Git needs to know who you are to track your changes. This information is attached to every commit you make, helping track who changed what in a project.

    # Change to match your userid
    git config --global user.email "[e-mail]"
    # Change to your name
    git config --global user.name "Your Name"

3. **Set Line Ending Behavior**
For Mac/Linux:

    git config --global core.autocrlf input

For Windows:

    git config --global core.autocrlf true

Different operating systems use different characters for line endings. This setting ensures consistent line endings across all platforms, preventing unnecessary file changes.

Specifically:
- Windows users get CRLF endings in their working directory but store LF in the repository
- Mac/Linux users maintain LF throughout but handle any CRLF they receive by converting to LF on commit

4. **Choose Default Editor**
Git sometimes needs you to write commit messages or resolve conflicts in a text editor. Nano is a simple, beginner-friendly editor.

    git config --global core.editor "nano"

> 🔍 **Checkpoint**: Verify your settings using this command:
>
> ```bash
> git config --global -l
> ```
>
> You should see all the settings you just configured.
>
> ```text
> $ git config --global -l
> core.autocrlf=input
> core.editor=nano
> init.defaultbranch=main
> user.email=*userid*@bucknell.edu
> user.name=*Student Name*
> ```
>
> And you've added answer 2.1 to `answers.txt`

## Required Steps - Repository Setup

Now that Git is configured, we'll create your local repository and connect it to GitLab. Each step builds on the previous one, so make sure each command succeeds before continuing.

1. **Create Local Repository**
This command:
- Creates a new Git repository in your current directory
- Sets up the initial branch named 'main'

    git init -b main

If successful, you'll see a message about an empty Git repository being initialized. The actual local repository is created in a _hidden_ directory (a directory starting with a period) in the same folder. You could confirm this by executing the command `ls -la`, and notice the new directory **.git**.

2. **Link to GitLab**
This command:
- Tells Git where your remote repository lives
- Names the remote 'origin' (the standard name for your primary remote)
- _**Replace 'userid' with your Bucknell username**_

    git remote add origin [e-mail]:userid/csci205_jams.git

3. **Configure Git Ignore**
The `.gitignore` file:
- Lists files Git should not track
- Ignores compiled code, IDE settings, etc.
- Keeps your repository clean

The next instructions change based on where you are working:
- **If on Linux lab/remote:**

        cp ~csci205/2025-spring/student/gitignore ./.gitignore

<!-- SEMESTER SPECIFIC: Update path each semester (e.g., 2024-fall -> 2025-spring) -->

- **If on your laptop** (IMPORTANT: The following is ONE SINGLE COMMAND that may wrap across multiple lines):

        scp "[e-mail]:/home/csci205/2025-spring/student/gitignore" ./.gitignore

<!-- SEMESTER SPECIFIC: Update path each semester (e.g., 2024-fall -> 2025-spring) -->

You may be prompted to enter your Linux password. If so, enter it (your Bucknell password).

4. **Examine the .gitignore File**
Take a moment to view the contents of your new .gitignore file:

    less .gitignore

This file contains a list of patterns that tell Git which files to ignore. Specifically:
- Each line specifies a file pattern
- Lines starting with `#` are comments
- Lines starting with `!` are exceptions to previous patterns
- Any file matching these patterns will be ignored by Git

:::info
🔑 **Understanding .gitignore**

Git ignores these files because they:
- Are generated automatically (like compiled code)
- Contain personal settings (like IDE configurations)
- Aren't part of your source code
- Would clutter your repository unnecessarily
:::

> 🔍 **Checkpoint**: Verify your setup:
>
> ```bash
> ls -la
> ```
>
> You should see:
>
> - A `.git` directory (hidden)
> - A `.gitignore` file
> - No error messages from any commands

## Required Steps - First Commit

Now we'll save your work to GitLab. This is a three-step process: staging files, committing them locally, and pushing to GitLab.

1. **Stage Your Changes**
Git needs to know which files you want to include in your commit:

    git add src
    git add .gitignore

These commands add your files to Git's "staging area" - a place where you collect changes before committing them.

2. **Review What's Staged**
Always verify what you're about to commit:

    git status

You should see:
- Both files listed in green under "Changes to be committed"
- No red (unhidden) files (these would be unstaged changes)

3. **Commit Your Changes**
Create a permanent record of your changes:

    git commit -m "jam00, initial commit"

The message (after -m) should briefly describe what you're committing. For jams, always start with "jamXX" where XX is the jam number.

4. **Push to GitLab**
Upload your commit to GitLab:

    git push -u origin main

The `-u` flag sets up tracking between your local and remote branches. You only need this flag the first time you push.

**First-Time Connection Note:** You may see a message asking to verify gitlab.bucknell.edu's authenticity. This is normal:
- Type 'yes' to accept (this is the default)
- Press ENTER to continue
- You should see messages about files being compressed and transferred

:::danger
🚨 **Critical Grading Requirement**
Only files committed AND pushed to GitLab are available for grading. If it's not on GitLab, it won't be graded - no exceptions!
:::

:::info
🔧 **About Empty Folders**

Git only tracks files, not folders! This means:

- Empty folders won't appear on GitLab
- The `resources/`, `test/java/`, and `test/resources/` folders won't show up yet
- These folders will appear automatically when you add files to them in future jams
- This is normal and expected behavior

Don't worry if you don't see all the folders on GitLab
:::

> 🔍 **Checkpoint**: Verify your commit:
>
> - Run `git log` to see your commit history locally - you should see your "jam00, initial commit" message
> - Run `git status` - No red (unhidden) files (these would be unstaged changes)
> - Visit your repository on GitLab - you should see your files there
> - Check that the commit message appears in GitLab's history

## Required Steps - Grant Access

Now we'll give your instructors and TAs access to grade your work. This is done through GitLab's web interface:

1. Visit [gitlab.bucknell.edu](https://gitlab.bucknell.edu) and sign in if needed
2. Navigate to your csci205_jams repository
3. Click **Manage** on the side menu 
4. Select **Members** from the left menu
5. Click the **Invite members** button
6. For each person:
- Enter their Bucknell ID in the "GitLab member or Email address" field
- Select "Developer" as their access level ⬅️ This is important!
- Click **Invite**

{%hackmd iOIQJii1QKaazUGal8dNjg %}
<!-- SEMESTER SPECIFIC: Update team member list each semester -->

:::danger
🚨 **Critical Grading Requirement**
Again, because this bears repeating: Only files committed AND pushed to GitLab are available for grading. If it's not on GitLab, it won't be graded - no exceptions!
:::

## Exploring GitLab

Take a moment to explore GitLab's interface - it's more than just a code repository! You'll find:

- A **Wiki** for project documentation
- **Issues** for tracking tasks and bugs
- **CI/CD** for automated testing
- And many more features for team collaboration

Congratulations! You now have a fully configured Git repository ready for all your coursework this semester.

> 🔍 **Final Checkpoint**: Before continuing, verify:
>
> - Your files appear on GitLab
> - All team members are added with Developer access
> - You can see your files in the repository
> - Your answers.txt file is committed and pushed