The Adventures of Blink S3e5: Use the Forks

Hey friends, welcome to The Adventures of Blink! If you find today's adventure helpful, please let me know by leaving an emoji or a comment... and then make sure to subscribe so you don't miss upcoming episodes! YouTube Edition Don't wanna read all this? I got ya. Have a video: There are Rules... or, there should be Last week we pushed code into the cloud, using GitHub and GitLab. We're leveling up our ability to collaborate with other coders around the world... but putting our code in the cloud is dangerous, if we don't lay some ground rules first! Someone could just add a bunch of malware into our project or make other changes that we don't want. So how can we encourage collaboration but not succumb to absolute chaos? Two roads diverged in a wood There are two main collaboration strategies to consider: FORKS and PROTECTED BRANCHES. Forks A FORK is simply a copy of a repository. For instance, consider the Ollama project we used back in Season 1... Ollama is a product that's fully maintained in GitHub. Its source code is freely available, and you can make changes to Ollama as a product, if you like. But that doesn't automatically mean that your changes will be accepted by the Ollama community. Forks are super useful, particularly in cases like this where the community is large and widely varied. If you were to find a bug in Ollama and fix it, they want to review your change to ensure it meets their standards, it does what it's supposed to do, etc. But for them to accept your change, they'd have to make you a contributor to Ollama, and that's a lot of power and control that they might not want to give to a random internet person! So they'll ask you to fork, make your change in your forked copy, and then provide a mechanism to request your change be sent back to the main repository as a Pull Request for review. This means you as a developer have no restrictions on what you can do - your repository belongs to you - but if you want to share your work back to the main product they'll have the opportunity to review your work before folding it in. Making a fork in GitHub is easy, you... just click "fork" and follow the directions: This will make a copy of the project in your personal space. You can do anything you want to it... but should you want to send your changes back to the Ollama maintainers, you'll have to open a Pull Request. GitLab does forks in pretty much the same way, as you can see here: Note that forks are NOT part of Git... they're a construct of GitHub and GitLab. So even though they pretty much work exactly the same in both tools, they don't actually work across the tool barrier. You can't find a repository on GitHub and fork it into GitLab, or vice-versa. While forks are great for this large-scale open sharing model, they can be cumbersome if you're a regular contributor to a project. You have to manually sync your fork whenever someone makes a change upstream, and you can't share individual branches with other contributors - you can basically only collaborate via Pull/Merge Requests. We need another way to handle collab efforts for folks we're a little closer to... Branch Protections If you have a high level of trust in the person you're collaborating with, you might invite them to have access to your repository. Doing this means that they can work inside the repo right next to you, in the same way you can... they won't need to fork. This can make the collaboration flow more smoothly, but it means you need some guardrails inside the repo to ensure you're communicating together well. Branch Protections are a feature of GitHub and GitLab that give you just that kind of safety. Generally speaking, we make the 'main' branch synonymous with "In Production". If you set up a GitHub action to deploy main to your web server, or to release your mobile app into the App Store, you want to ensure you're only accepting high-quality changes into it. So using GitHub and GitLab, you can protect branches, setting some rules about how a branch can be manipulated. What rules do you need? It depends on your tolerance for "bumps in the road". The simplest (and IMO most effective) is a requirement that no one can push straight to main - they have to work in a branch and create a PR. I often couple this with a rule that requires every PR to main to need an approval: now anyone who wants to change something has to have a second person agree that the change is ok. You can do too much here Yes, it's possible to create intricate rulesets that enforce very specific behaviors and actions. That doesn't mean you should. Some folks see these settings and they get giddy about it - "ooh we should require approvals from everyone and restrict the ability to do xyz and ... I want you to think of this from the perspective of the person who has to live within the rules. Less is more; it's very easy to go ov

Apr 3, 2025 - 13:57

The Adventures of Blink S3e5: Use the Forks

Hey friends, welcome to The Adventures of Blink! If you find today's adventure helpful, please let me know by leaving an emoji or a comment... and then make sure to subscribe so you don't miss upcoming episodes!

YouTube Edition

Don't wanna read all this? I got ya. Have a video:

There are Rules... or, there should be

Last week we pushed code into the cloud, using GitHub and GitLab. We're leveling up our ability to collaborate with other coders around the world... but putting our code in the cloud is dangerous, if we don't lay some ground rules first! Someone could just add a bunch of malware into our project or make other changes that we don't want. So how can we encourage collaboration but not succumb to absolute chaos?

Two roads diverged in a wood

There are two main collaboration strategies to consider: FORKS and PROTECTED BRANCHES.

Forks

A FORK is simply a copy of a repository. For instance, consider the Ollama project we used back in Season 1... Ollama is a product that's fully maintained in GitHub. Its source code is freely available, and you can make changes to Ollama as a product, if you like. But that doesn't automatically mean that your changes will be accepted by the Ollama community.

Forks are super useful, particularly in cases like this where the community is large and widely varied. If you were to find a bug in Ollama and fix it, they want to review your change to ensure it meets their standards, it does what it's supposed to do, etc. But for them to accept your change, they'd have to make you a contributor to Ollama, and that's a lot of power and control that they might not want to give to a random internet person! So they'll ask you to fork, make your change in your forked copy, and then provide a mechanism to request your change be sent back to the main repository as a Pull Request for review. This means you as a developer have no restrictions on what you can do - your repository belongs to you - but if you want to share your work back to the main product they'll have the opportunity to review your work before folding it in.

Making a fork in GitHub is easy, you... just click "fork" and follow the directions:

This will make a copy of the project in your personal space. You can do anything you want to it... but should you want to send your changes back to the Ollama maintainers, you'll have to open a Pull Request.

GitLab does forks in pretty much the same way, as you can see here:

Note that forks are NOT part of Git... they're a construct of GitHub and GitLab. So even though they pretty much work exactly the same in both tools, they don't actually work across the tool barrier. You can't find a repository on GitHub and fork it into GitLab, or vice-versa.

While forks are great for this large-scale open sharing model, they can be cumbersome if you're a regular contributor to a project. You have to manually sync your fork whenever someone makes a change upstream, and you can't share individual branches with other contributors - you can basically only collaborate via Pull/Merge Requests. We need another way to handle collab efforts for folks we're a little closer to...

Branch Protections

If you have a high level of trust in the person you're collaborating with, you might invite them to have access to your repository. Doing this means that they can work inside the repo right next to you, in the same way you can... they won't need to fork. This can make the collaboration flow more smoothly, but it means you need some guardrails inside the repo to ensure you're communicating together well.

Branch Protections are a feature of GitHub and GitLab that give you just that kind of safety. Generally speaking, we make the 'main' branch synonymous with "In Production". If you set up a GitHub action to deploy main to your web server, or to release your mobile app into the App Store, you want to ensure you're only accepting high-quality changes into it. So using GitHub and GitLab, you can protect branches, setting some rules about how a branch can be manipulated.

What rules do you need? It depends on your tolerance for "bumps in the road". The simplest (and IMO most effective) is a requirement that no one can push straight to main - they have to work in a branch and create a PR. I often couple this with a rule that requires every PR to main to need an approval: now anyone who wants to change something has to have a second person agree that the change is ok.

You can do too much here

Yes, it's possible to create intricate rulesets that enforce very specific behaviors and actions. That doesn't mean you should. Some folks see these settings and they get giddy about it - "ooh we should require approvals from everyone and restrict the ability to do xyz and ...

I want you to think of this from the perspective of the person who has to live within the rules. Less is more; it's very easy to go overboard designing your workflows and enforcing things that end up just getting in the way. I encourage you to have a little faith in your team here, and let these rules be fairly permissive. Your collaborators will reward you with their excellence, I promise!

Wrapping up

Friends, we've reached the end of another Adventure together. I hope you're learning a lot and thinking about the ways this tooling helps you improve your craft! Tune in next week as we look "Beyond the Code" and find some additional features of GitLab and GitHub that aren't directly about code commits, but can help you level up even further! See you next time!