Git & GitHub —
Version Control Assessment

Git manages files through four important stages. Understanding these stages makes every Git command easier to reason about, because every command operates on exactly one of them.

git add <filename> adds the entire file to staging. git add -p starts Patch Mode, where Git asks whether each small section (called a hunk) should be staged. This is useful when one file contains multiple unrelated changes — you can commit only the required change while leaving the rest for a separate commit.

Sometimes you’re developing a feature when an urgent bug needs fixing in another branch. If your work is incomplete, Git prevents switching branches. git stash saves all uncommitted changes without creating a commit, so you can switch safely and restore with git stash pop.

Embedded projects generate many temporary files during compilation (.pio/, build/, .vscode/, *.log). These increase repository size, change constantly, and can expose private information like Wi-Fi credentials. A .gitignore file tells Git which files and folders should never be tracked.

This command restores the project to the most recent commit, removing all modified files, staged changes, and uncommitted edits. The deleted changes cannot normally be recovered. Use this command with care.

There are two ways to undo commits. git reset removes commits from history, rewrites the timeline, and is unsafe after pushing to GitHub. git revert creates a new commit that reverses the previous changes, keeps the complete history intact, and is safe for shared repositories.

Professional Git projects follow a standard commit message style — short, action-oriented, and in the imperative mood (as if giving an instruction).

GitHub repositories often contain important source code. With only a stolen password, an attacker could delete repositories, upload malicious code, access CI/CD secrets, and cause serious damage. With 2FA enabled, logging in also requires a second verification step, making unauthorized access significantly harder.

Merge keeps the original branch history and creates a merge commit — safe for collaborative work. Rebase moves feature commits on top of the latest main branch, producing a clean, linear history, but rewrites commit history. For solo projects, rebase often creates a cleaner history; merge is generally safer for team collaboration.

A Git tag marks an important point in the project’s history. Tags are used to mark stable firmware releases, create GitHub Releases, track software versions, support OTA firmware updates, and allow developers to easily return to a previous stable version.

Committing and pushing after every work session is one of the most important Git practices. Even when a project is incomplete, saving current progress ensures the work is safely stored and recoverable.

• Prevents data loss. Computers crash, storage fails, and files get deleted. If the latest changes are already pushed to GitHub, the project can be restored at any time.
• Creates backup copies. GitHub acts as an online backup. Instead of keeping the only copy locally, code is safely stored in a remote repository.
• Makes debugging easier. Each commit is a checkpoint. If a bug appears after several changes, Git can compare commits to identify exactly when the problem was introduced.
• Encourages small, organized commits. Frequent commits each contain one logical change (“Add UART initialization”, “Fix SPI timeout”), which are far easier to review than one enormous commit.
• Helps collaboration. Everyone on the team can see the latest progress after each push, and the remote remains available from any computer.

Without regular commits, you risk losing work to hardware failure, struggling to locate the source of a bug, accumulating unmanageable commits, and accidentally destroying unfinished code with a careless git reset --hard.

Suppose we need to develop a new UART driver without affecting the stable main branch.

# 1. Create and switch to the feature branch
git switch -c feature/uart-driver

# 2. Stage the driver files
git add uart_driver.c uart_driver.h

# 3. WIP commit
git commit -m "Add UART driver scaffold"

# 4. Switch to main (use git stash first if you have uncommitted changes)
git switch main

# 5. Fix the bug, commit, and push
git add .
git commit -m "Fix startup bug"
git push

# 6. Return to the feature branch (restore stash if applicable)
git switch feature/uart-driver
git stash pop    # only if stash was used

If Wi-Fi credentials are pushed to GitHub, they should be treated as compromised immediately, even if the repository is private.

A simple branching strategy keeps projects organized and prevents bugs from entering stable firmware.

Main branch: always contains stable, compiling, hardware-tested code. Only merge tested features into this branch.

Feature branches: one branch per new feature (feature/uart, feature/spi, feature/bluetooth). Keeps experimental code away from stable firmware.

Bug-fix branches: dedicated branches like fix/spi-timeout keep maintenance work organized.

Merge only after testing: a feature merges into main only after successful compilation, no build errors, and hardware testing.

Tag stable releases: create tags (v0.1, v0.5, v1.0) at each stable version so you can always return to a known-good state.

SSH keys provide a secure way to authenticate with GitHub without entering a password on every push or pull. An SSH key consists of two parts: a private key (stored securely on your computer, never shared) and a public key (uploaded to GitHub). Both keys work together to verify identity securely.

• Better security. SSH keys are cryptographically much harder to steal or guess than passwords.
• No password prompt. After setup, git push and git pull work silently and instantly.
• Required by GitHub. GitHub removed password authentication for Git operations. Developers must now use SSH keys or Personal Access Tokens.
• Easy to revoke. If a device is lost, remove only that device’s SSH key from GitHub — no need to change the account password.
• Works in automation. SSH authentication integrates cleanly with CI/CD pipelines, build servers, and automation scripts.

Since the commit has not yet been pushed, the mistake can be corrected safely without affecting anyone else.

Continuous Integration automatically builds and tests a project whenever new code is pushed to GitHub. Even a simple workflow significantly improves reliability by confirming that the project compiles on a clean machine every time.

The minimum useful workflow for a PlatformIO STM32 project should: trigger on every push and pull request, check out the repository, install PlatformIO, download all project dependencies, run pio run to compile the firmware, and report the result as a pass or fail status.

When main has received new commits, the feature branch should be updated before merging. Both merge and rebase update the branch but produce different histories.

GitHub allows users to highlight up to six public repositories on their profile page. Pinned repositories are typically the first projects viewed by instructors, recruiters, and employers.

Choose the projects that best demonstrate your embedded systems skills: STM32 Driver Development, ESP32 IoT Project, BLE Application, FreeRTOS Project, LVGL HMI, or RS-485 Communication Project.

Pinning improves your professional profile by highlighting your strongest work, making your page more organized, and helping recruiters quickly evaluate your skills for internships and job applications.