SDPT Lab 1

De la WikiLabs
Versiunea din 23 februarie 2026 00:34, autor: Rhobincu (discuție | contribuții) (Pagină nouă: = Lab 1: Foundation of Process - Git and GitLab Basics = == Introduction == Welcome to the first lab of Software Development Process and Testing (SDPT). In our lecture, we discuss...)
(dif) ← Versiunea anterioară | Versiunea curentă (dif) | Versiunea următoare → (dif)
Jump to navigationJump to search

Lab 1: Foundation of Process - Git and GitLab Basics

Introduction

Welcome to the first lab of Software Development Process and Testing (SDPT). In our lecture, we discussed why treating software like a physical breadboard leads to failure in complex systems. We introduced the Software Development Life Cycle (SDLC), Issue Tracking, and the underlying graph model of Git.

Today, we put theory into practice. By the end of this 2-hour lab, you will have:

  1. Created a project repository on GitLab.
  2. Created your first tracked Issue.
  3. Configured Git on your local machine.
  4. Moved a C++ source file through the Three States of Git.
  5. Pushed your local history to the remote GitLab server and automatically closed your Issue.

Note: Do not rush. The goal is to understand where your files are in the Git graph at any given moment. Run git status frequently!

---

Part 1: Setting Up the Remote (GitLab)

Before we touch the terminal, we need to set up our remote infrastructure and document the work we intend to do.

1. Create a New Repository

  • Log into your university GitLab account.
  • Click New Project -> Create blank project.
  • Project Name: sdpt-rfid-access
  • Visibility Level: Private (or Internal, depending on your professor's instructions).
  • Important: Uncheck "Initialize repository with a README". We want an entirely empty repository to practice pushing from our local machine.
  • Click Create project.

2. Create Your First Issue

We need a business requirement before we write code.

  • On the left sidebar of your new project, navigate to Plan -> Issues.
  • Click New issue.
  • Title: Create initial RFID reader driver skeleton
  • Description: Need a basic main.cpp file that will eventually hold the SPI communication logic for the RFID module.
  • Click Create issue.
  • Take note of the Issue Number (e.g., #1) generated next to the title. You will need this later!

---

Part 2: Initializing the Local Environment

Now, open your terminal (Linux/macOS) or Git Bash (Windows).

1. Configure Your Identity

Git embeds the author's name and email into every commit permanently. You only need to run these commands once per computer.

git config --global user.name "Your First and Last Name"
git config --global user.email "your.university.email@domain.edu"

2. Create Your Local Workspace

Create a folder for your project and initialize it as a Git repository.

mkdir sdpt-rfid-access
cd sdpt-rfid-access
git init

Notice the output: Initialized empty Git repository. A hidden .git folder has been created. This is your database.

---

Part 3: The Three States in Practice

Remember the three states from the lecture: Working Directory, Staging Area, and Repository. Let's move a file through them.

1. The Working Directory

Create a new C++ file. This represents writing your initial code.

touch main.cpp

Open main.cpp in your favorite text editor (nano, vim, VS Code) and add a basic skeleton:

#include <iostream>

int main() {
    std::cout << "RFID Access Control System Initialized" << std::endl;
    return 0;
}

Now, check your radar:

git status

Notice that main.cpp is red and listed under "Untracked files". Git sees the file in your Working Directory, but is not managing it yet.

2. The Staging Area (Index)

Tell Git you want to include this file in your next commit snapshot.

git add main.cpp
git status

Notice the file is now green and under "Changes to be committed". It is in the Staging Area.

3. The Repository (Commit)

Save the snapshot permanently into your local Git database.

git commit -m "Add initial RFID system skeleton"
git status

Your working tree is now clean. The snapshot is stored as a node in your local Git graph.

---

Part 4: Connecting Local to Remote and Closing Issues

Your code is safe locally, but the "Bus Factor" is still 1. If your laptop crashes, the code is gone. We must push to GitLab.

1. Link the Remote Server

Go back to your GitLab project page. Under "Push an existing Git repository", copy the git remote add origin... command. It will look like this:

git remote add origin https://gitlab.com/your-username/sdpt-rfid-access.git

2. Push and Close the Issue

We want to push our code AND tell GitLab that this code fulfills the requirement we documented in Part 1. We do this by making a new commit that references the Issue number.

Let's make a small change to main.cpp. Open it and add a comment:

// TODO: Implement SPI communication with RC522 module

Now, stage and commit this change, using a special keyword (Closes #1) in the commit message:

git add main.cpp
git commit -m "Add SPI TODO comment. Closes #1"

Finally, push your local graph to the remote server:

git push -u origin main

(Note: If your default branch is 'master' instead of 'main', use git push -u origin master)

3. Verify the Magic

Go back to your browser and refresh your GitLab project page:

  • Your main.cpp file is now visible on the server!
  • Go to Plan -> Issues. Notice that Issue #1 is now automatically marked as Closed. Git and GitLab worked together to link your code directly to the business requirement.

---

Lab Deliverable

To receive full credit for this week's lab, call the professor or teaching assistant over to your workstation and demonstrate:

  1. Your GitLab repository showing the main.cpp file.
  2. Your GitLab Issue board showing Issue #1 as Closed.
  3. Your terminal showing the output of the git log command, displaying your two commits.