Git Day 3: Collaborative Development with Forks¶
Today's task moved away from the command line and into the web UI, which is where a huge amount of modern Git collaboration happens. I learned about the concept of "forking," which is the cornerstone of contributing to projects where you don't have direct write access.
This was a critical lesson in understanding the difference between a clone (a local copy for me to work on) and a fork (a new server-side copy that I own). It's the first step in the famous "Fork and Pull Request" workflow that powers open-source software.
Table of Contents¶
- The Task
- My Step-by-Step Solution
- Why Did I Do This? (The "What & Why")
- Deep Dive: The Fork and Pull Request Workflow
- Common Pitfalls
- Exploring the Commands Used
The Task¶
My objective was to perform a task as a new developer, jon, using the Gitea web interface. The requirements were:
1. Log into the Gitea server as user jon with the provided password.
2. Find the existing Git repository named sarah/story-blog.
3. Fork this repository so that a new copy exists under my (jon's) account.
My Step-by-Step Solution¶
This entire task was performed using the web browser, not the command line.
-
Access and Login: I clicked the Gitea UI button in the lab environment. On the login page, I entered the credentials:
- Username:
jon - Password:
Jon_pass123
- Username:
-
Locate Repository: After logging in, I used the search bar at the top of the dashboard to find the
sarah/story-blogrepository. I clicked on it to navigate to the repository's main page. -
Fork: In the top-right corner of the repository page, I located the "Fork" button and clicked it.
-
Confirm Fork: Gitea presented a "New Fork" screen. The owner was correctly set to
jon. I just had to click the final "Fork Repository" button. -
Verification: The best part was the immediate confirmation. I was automatically redirected to my new repository's page. The title clearly showed
jon/story-blog, and just below it was the text "forked from sarah/story-blog". This was the definitive proof of success.
Why Did I Do This? (The "What & Why")¶
- Gitea: This is a self-hosted Git service, like a private version of GitHub or GitLab. It provides a web UI to manage users, repositories, and collaboration features like pull requests.
- Forking: A fork is a new copy of a repository that is created on the server. This new copy belongs to me (jon), so I have full permission to push changes to it. The original repository (sarah/story-blog) remains untouched and protected.
- Forking vs. Cloning: This is the most important concept from this task.
- A clone creates a local copy on my machine.
- A fork creates a new repository on the server.
The standard workflow is to first fork the project on the server, and then clone your fork to your local machine.
Deep Dive: The Fork and Pull Request Workflow¶
Forking is the first step in the most common collaboration pattern in software development. It allows anyone to contribute to a project without giving them direct access to the main codebase.
The full process is:
1. Fork: Create my own server-side copy of the project (jon/story-blog).
2. Clone: Clone my fork to my local machine (git clone <URL_of_jon/story-blog>).
3. Create a Branch: Create a new branch for my changes (git checkout -b new-feature).
4. Code: Make my changes to the files.
5. Commit: Save my changes (git commit -am "Add my new feature").
6. Push: Push my new branch to my fork on the server (git push origin new-feature).
7. Create a Pull Request (PR): From the Gitea UI, I would open a "Pull Request" from my new-feature branch on jon/story-blog to the main branch on the original sarah/story-blog. This is a formal request asking Sarah to review and merge my work into the main project.
Common Pitfalls¶
- Cloning Instead of Forking: A very common mistake for beginners is to clone the original repository (sarah/story-blog) directly to their machine. While this gives them the code, they won't be able to push their changes back to the server, because they don't have permission. This breaks the contribution workflow.
- Incorrect Credentials: Simply failing to log in with the correct username and password (jon / Jon_pass123).
Exploring the Commands Used¶
This was a UI-driven task, so no command-line tools were used. The key actions were all performed by clicking buttons within the Gitea web interface: - Login Button - Search Bar - Fork Button - Fork Repository Button