Lesson: Working with Gitea

What you'll learn 
 
 What a remote is, and how your local repo and a server repo stay in sync. 
 How to clone , and how to wire up an existing local repo with git remote add . 
 The push/fetch/pull cycle, and what a tracking branch is. 
 How to push your Module 3 scripts to the lab's Gitea server. 
 The pull-request (PR) workflow — how real teams review and merge changes. 
 
 By the end you will be able to publish your work to the lab Gitea server and propose changes through a pull request, just like on GitHub. 
 The lesson 
 1. What a remote is 
 So far everything lived only on your VM. A remote is a copy of your repository hosted somewhere else — on a server — that you and your teammates share. Git can sync commits between your local repo and the remote. 
 Our lab runs Gitea , a self-hosted Git server that behaves just like GitHub for everyday use: web UI, repositories, branches, pull requests. Its addresses: 
 
 Public URL: https://git.example.com 
 Internal (from inside the lab network): http://10.100.100.2:3000 
 
 your VM (local repo) Gitea server (remote)
 ┌────────────────────┐ push ───> ┌──────────────────────┐
 │ commits A,B,C │ │ commits A,B,C │
 │ branch: main │ <─── fetch │ branch: main │
 └────────────────────┘ └──────────────────────┘
 
 A remote is normally nicknamed origin — that is just a convention for "the main remote I cloned from / push to." 
 2. Two ways to start 
 (a) Clone an existing remote repo — copies the whole repo, history and all, to your machine and auto-configures origin : 
 git clone http://10.100.100.2:3000/yourname/my-scripts.git
cd my-scripts
 
 (b) Connect a local repo you already created — you built my-scripts locally in earlier lessons. First create an empty repo named my-scripts in the Gitea web UI (do not let it add a README, so it stays empty). Then link and push: 
 git remote add origin http://10.100.100.2:3000/yourname/my-scripts.git
git remote -v # verify: shows the fetch and push URLs for origin
 
 git remote -v should print origin twice (one fetch, one push line). 
 3. Pushing for the first time 
 Pushing uploads your local commits to the remote. The first push of a branch also sets up tracking with -u : 
 git push -u origin main
 
 Gitea will ask for your username and password (or a personal access token created in the Gitea UI under Settings → Applications — never paste a real token into shared notes; treat it as <REDACTED> ). After this, the commits appear on the Gitea website. 
 The -u (short for --set-upstream ) creates a tracking branch : it links your local main to origin/main . Once linked, you can simply type git push and git pull with no extra arguments — Git knows where they go. 
 4. fetch vs pull 
 Two commands bring remote work down to you: 
 
 git fetch downloads new commits from the remote into your local copy of the remote branches (e.g. origin/main ), but does not change your working files. It is the safe "let me see what's new" command. 
 git pull does a fetch and then merges those changes into your current branch. It is fetch + merge in one step. 
 
 git fetch origin # see what changed on the server, no merge yet
git log --oneline origin/main # inspect the remote branch
git pull # bring it into your branch (fetch + merge)
 
 Habit to build: pull before you start working each session, so you begin from the latest shared state and avoid conflicts later. 
 5. The everyday remote cycle 
 git pull <- get latest from server
 ... edit, add, commit locally ...
 git push <- send your commits to the server
 
 If git push is rejected because the remote moved ahead of you, do git pull first (resolve any conflict as you learned in Lesson 3), then git push again. 
 6. Why pull requests exist 
 On a real team you usually do not push straight to main . Instead you push a branch and open a pull request (PR) — a proposal that says "please review my branch and merge it into main ." A PR gives teammates a place to read your diff, comment, request changes, and approve before the code lands. It is the heart of collaborative Git. 
 7. A basic pull-request flow on Gitea 
 Walk through the full loop: 
 
 Start from the latest main and create a feature branch:
 git switch main
git pull
git switch -c add-readme
 
 
 Do the work and commit: 
 echo "# My Scripts" > README.md
git add README.md
git commit -m "Add project README"
 
 
 Push the branch to Gitea:
 git push -u origin add-readme
 
 
 Open the PR in the web UI. Go to https://git.example.com/yourname/my-scripts . Gitea shows a banner offering to create a pull request from your just-pushed branch. Click it, set the target to main , write a clear title and description of what and why , and create the PR. 
 Review. A teammate (or your mentor) reads the diff and comments. If they request changes, you make more commits on the same branch and git push again — the PR updates automatically. 
 Merge. Once approved, click Merge Pull Request in Gitea. Your change is now in main on the server. 
 Sync and clean up locally: 
 git switch main
git pull # bring the merged change down
git branch -d add-readme # delete the local feature branch
 
 
 
 local feature branch ─push─> Gitea branch ─PR─> review ─merge─> origin/main ─pull─> your local main
 
 8. Inspecting and tidying remotes 
 git remote -v # list remotes and URLs
git branch -r # list remote-tracking branches (e.g. origin/main)
git fetch --prune # drop local refs to branches deleted on the server
 
 That's the full collaboration loop: clone or add a remote, branch, commit, push, open a PR on Gitea, get review, merge, and pull. This is exactly how professional teams ship code every day — and it is what you'll practice in this module's assignments. 
 Dig deeper 
 
 Pro Git — Working with Remotes 
 Gitea documentation — Usage 
 Atlassian — Syncing (fetch, pull, push) 
 Atlassian — Making a pull request 
 Official git push documentation 
 
 Search terms 
 
 git remote add origin push first time 
 git fetch vs git pull difference 
 git tracking branch upstream explained 
 how to open a pull request gitea 
 git pull rejected push remote ahead fix 
 
 Check yourself 
 
 What is a remote, and what does the name origin conventionally refer to? 
 What does the -u flag do on your first git push , and how does it change later pushes? 
 Explain the difference between git fetch and git pull . 
 Why do teams use pull requests instead of pushing directly to main ? 
 List the steps to take a local change all the way to merged on Gitea via a PR.