Git & GitLab Onboarding: Working Safely on TechLit Computers
Welcome to the TechLit Africa contributor team! This guide will walk you through setting up your terminal environment on our workstations. Because our default user home is reset on logout, we must use specific persistent paths to ensure your security keys and code projects are never lost.
Phase 1: Environment & Key Provisioning
Section titled “Phase 1: Environment & Key Provisioning”Objective: Setup your GitLab account, generate persistent security keys, and configure your global Git identity. Estimated time: 10 minutes
1.1 GitLab Account Setup
Section titled “1.1 GitLab Account Setup”Before you start working in the terminal, you need a GitLab account to identify your contributions.
- Register: Go to GitLab.com and create a free account.
- Join the Group: Once your account is ready, request GitLab write access on WhatsApp. Provide your GitLab username, and you will be added to the techlit-africa workspace.
1.2 Persistent SSH Configuration
Section titled “1.2 Persistent SSH Configuration”To connect to GitLab without a password, we generate an SSH key. We store this in your persistent folder so it survives a logout.
Action Commands:
Verification Step:
Visual Checkpoint:
1.3 Git Identity Setup
Section titled “1.3 Git Identity Setup”Git needs to know who is making changes so that your name appears correctly in the project history.
Action Commands:
Verification Step:
Phase 2: Local Workspace & The 3-Stage Pipeline
Section titled “Phase 2: Local Workspace & The 3-Stage Pipeline”Objective: Create safety backups, clone the project, and master the local saving cycle. Estimated time: 15 minutes
2.1 Safe Folder Backups: Your Manual Undo Button
Section titled “2.1 Safe Folder Backups: Your Manual Undo Button”Before practicing Git commands, always make a local duplicate of your folder. This is your 100% safe “undo button” if a command gets confusing.
Action Commands:
2.2 The “Git Status” Mantra
Section titled “2.2 The “Git Status” Mantra”Think of git status as the terminal user’s eyes. Run it before you add a file, after you stage it, and right before you commit. If you ever feel lost, git status is the first command you should type.
2.3 Project Cloning
Section titled “2.3 Project Cloning”Pull the websites repository from GitLab into your persistent projects folder.
Action Commands:
Visual Checkpoint:
2.4 Saving Your Work: The Three Stages
Section titled “2.4 Saving Your Work: The Three Stages”Git uses a holding zone to help you organize what you save.
- Modified: You have edited a file (e.g.,
src/main.js) but haven’t told Git to save it yet. - Staged (
git add): You have picked which changes you want to include in your next save. Think of this as putting files into a “to-be-saved” box. - Committed (
git commit): You have permanently saved the snapshot of your staged files to your local history.
Branching & Staging:
%%{init: { 'theme': 'default', 'themeVariables': { 'fontSize': '28px' }}}%%
graph LR
subgraph Remote["GitLab (Remote Server)"]
RM[main branch]
RFB[remote branch]
MR{Merge Request}
end
subgraph Local["Your dev computer (Persistent)"]
LM[main branch]
FB[feature-branch]
Edit[Edit Files] --> Modified(Modified)
Modified -- "git add" --> Staged(Staged)
Staged -- "git commit" --> Committed(Committed)
end
RM -- "git clone" --> LM
LM -- "git switch -c feature-branch" --> FB
FB --> Edit
Committed -- "git push" --> RFB
RFB -- "Open MR" --> MR
MR -- "Merged" --> RM
Phase 3: Team Sync & Upstream Collaboration
Section titled “Phase 3: Team Sync & Upstream Collaboration”Objective: Master feature branching, keep your work current, and share changes via Merge Requests. Estimated time: 15 minutes
3.1 Feature Branching Workflow
Section titled “3.1 Feature Branching Workflow”We never edit the main branch directly. We use Feature Branches to keep our production code stable.
Action Commands:
Visual Checkpoint:
3.2 Keeping Your Branch Current
Section titled “3.2 Keeping Your Branch Current”If you haven’t worked on your feature branch for a few days, rebase it to include the latest team changes.
Action Commands:
Visual Checkpoint:
3.3 Pushing Changes & Opening an MR
Section titled “3.3 Pushing Changes & Opening an MR”Once you have committed your work locally, send it to GitLab to share it with the team.
Action Command:
Visual Checkpoint:
3.4 Troubleshooting & Escape Hatches
Section titled “3.4 Troubleshooting & Escape Hatches”- The Escape Hatch: If a rebase or merge becomes confusing, go back to safety with
git rebase --abort. - Clean Workspaces: Always check your
.gitignoreto ensure temporary files aren’t being tracked. - The snapshot rule: Anything left in
~/or/home/guestdisappears forever on logout. Always verify your path withpwd.
Congratulations! You are now ready to contribute safely and effectively to the TechLit Africa project.