El flujo de trabajo basado en forks para el código abierto

Welcome to the Forking Workflow! This model is super popular for open-source contributions and managing external collaborators.

It provides a structured way for anyone to contribute to a project without needing direct write access to the original repository.

A fork is essentially your own personal copy of someone else's repository. This copy lives on the Git hosting service (like GitHub or GitLab), not directly on your computer.

• It's a server-side clone of the original project.
• You have full write access to your fork.
• Changes you make here don't affect the original project until you propose them.

Once you've forked a repository on the web, the next step is to get that copy onto your local machine. You'll clone your own fork, not the original project.

Use the git clone command with the URL of your forked repository:

After cloning your fork, it's crucial to establish a connection to the original repository. We call this the 'upstream' remote.

This link allows you to fetch updates from the original project and keep your fork synchronized.

Before making any changes, always create a new branch for your contribution. This keeps your changes isolated and makes it easier to manage multiple contributions or discard work if needed.

• Switch to your main branch (e.g., main or master).
• Pull the latest from your fork.
• Create and switch to a new branch.

Projects evolve quickly! To avoid merge conflicts and ensure your changes are based on the latest code, regularly sync your local repository with the original upstream project.

First, fetch changes from upstream, then rebase your feature branch:

Once your changes are committed and your branch is updated, push your feature branch to your personal remote fork. This makes your work visible on your GitHub/GitLab profile.

Use git push origin <branch-name> to send your changes:

With your changes pushed to your fork, the final step is to propose them to the original project. You do this by creating a Pull Request (PR) (sometimes called a Merge Request).

• A PR is a formal proposal to merge your changes into the upstream project.
• It allows project maintainers to review your code, suggest changes, and discuss your contribution.
• You'll typically initiate this from your Git hosting service's website.

Which of the following are key steps in the Forking Workflow when contributing to an open-source project?

You've learned the essentials of the Git Forking Workflow!

• You create a fork (your server-side copy).
• You clone your fork locally.
• You link to the original project as upstream.
• You make changes on a dedicated feature branch.
• You sync with upstream and push to your fork.
• Finally, you create a Pull Request to propose your changes.

This workflow is fundamental for collaborative open-source development!