{"id":1979,"date":"2021-07-07T10:38:42","date_gmt":"2021-07-07T10:38:42","guid":{"rendered":"https:\/\/gitprotect.io\/blog\/?p=1979"},"modified":"2023-11-22T12:48:25","modified_gmt":"2023-11-22T12:48:25","slug":"git-forking-workflow","status":"publish","type":"post","link":"https:\/\/gitprotect.io\/blog\/git-forking-workflow\/","title":{"rendered":"Git Forking Workflow"},"content":{"rendered":"\n

Recently I was talking to my friend about Open Source projects. That was a lively debate and we wondered about how to cooperate in such projects, of course from the technical point of view. How are they stored, how can you contribute to their development, and finally \u2013 who and how controls what the community adds to such a project. This inspired me to describe a mechanism called forking in Git because a lot of people have heard of it, but when you need to delve into the details, it turns out that not everything is so obvious. Let’s check how it works and what a forked repository is.<\/p>\n\n\n\n\n\n\n\n

What is forking in Git<\/h2>\n\n\n\n

Fork and clone… Is it the same? Actually forking <\/em>in Git in short means copying a project. This will copy the entire project, just like the Clone function, but there is a fundamental difference between them. If we do Clone, we will just create a local copy of the repository, so to say – cloned repository, and all synchronization will take place between the base repo and our local copy. You can read more about git clone operation, the Clone function and how to clone a repository here: Git clone vs backup<\/a>.<\/p>\n\n\n\n

Fork<\/em><\/em>, on the other hand, differs in that it copies the entire repository, so to say, you create forked repositories, but on the server-side! And then this copy can be cloned and worked on it, completely separate and independent of the basic project. Powerful functionality. Wondering where the name Fork came from? The copies we create in this way can be visualized as a fork. Anyway, just look at the icon for this option in GitHub: <\/p>\n\n\n

\n
\"Fork<\/figure><\/div>\n\n\n

How does forking work<\/h2>\n\n\n\n

It doesn’t matter who, where, and how manages the base project, if it is possible to fork <\/em>a repo, that fork <\/em>is entirely yours<\/strong>. You don’t have to worry about permissions or accesses. You can treat such a fork <\/em>as your own public repo in your namespace. So where is magic? With this feature, you can easily synchronize your work between two seemingly separate git repositories! Let us consider a small example:<\/p>\n\n\n

\n
\"example<\/figure><\/div>\n\n\n

original\/niceRepo<\/strong> <\/strong>stands for the name of the repository in the given namespace. This is a representation of the public repository that we want to make some changes too, but not having any permissions to it. So we use the fork <\/em>option and create a copy, this time in our namespace \u2013 myNamespace\/niceRepo<\/strong>. <\/strong>We clone our own repository, make changes locally, push, and finally, we come to the point. At the moment, we can perform a Pull Request between our repository and the original one. If we do this, the project owner will receive a notification that someone wants to make changes, and then it depends on him or her whether our change will be accepted or not. It is important that such Pull Request allows for code review and discussion on the proposed changes, just like in the case of a typical PR. Now let’s briefly discuss how it works on different platforms.<\/p>\n\n\n\n

Fork in GitLab<\/strong><\/h3>\n\n\n
\n
\"Fork
Source: GitLab documentation<\/a><\/em><\/figcaption><\/figure><\/div>\n\n\n

It is always worth looking at the official documentation, I encourage you to do so because in this case, GitLab describes the process very easily. In short, the whole operation is to find the project we are interested in, click the\u00a0fork\u00a0<\/em>option (in the upper right corner, as in the picture above)<\/strong>, then select our namespace in which we want to make a copy and it’s ready. Importantly, GitLab encourages us to use repository mirroring. I also recommend that you do this, this option will allow you to automatically sync changes from the original repo with our copy. Beware of the naming convention, because GitLab uses\u00a0Merge<\/a>\u00a0Request, not Pull Request, as in GitHub.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\n\n\n\n

How secure are your repos and metadata? Don’t push luck – secure your code with the first professional GitHub, Bitbucket, and GitLab backup<\/strong>.<\/p>\n\n\n\n

\n
Start 14 days free GitProtect trial<\/a><\/div>\n<\/div>\n\n\n\n
\n\n\n\n
<\/div>\n\n\n\n

Fork in GitHub<\/strong><\/h3>\n\n\n\n

And since I mentioned GitHub, I will tell you immediately how it works in this service. The actual execution of fork <\/em>works almost identically, so I won’t describe it. However, the main difference is that GitHub by default does not provide the option of automatic synchronization between our and the original repository. It is true that we have a button that allows us to do it manually, but it is a downside to the competing platform. On the other hand, it must be admitted that the GitHub documentation describes very clearly how we can deal with this and easily synchronize our local copy to be up to date with the original repo all the time.<\/p>\n\n\n\n

Fork in Bitbucket<\/strong><\/h3>\n\n\n\n

While the GitHub and GitLab web interfaces are quite similar to each other, Bitbucket differs significantly from them. Repository forking is no exception. While this option is still in the upper right corner, after opening the repository we are interested in, there is no well-known \u201cfork\u201d icon there. We need to open the drop-down menu and select the \u201cFork this repository\u201d option<\/strong> there, as shown in the image below:<\/p>\n\n\n

\n
\"Fork<\/figure><\/div>\n\n\n

Bitbucket also allows us to check the \u201cPrivate repository\u201d option. Apart from the obvious consequences of this decision, there is also one less clear matter here. Namely, the fork <\/em>in Bitbucket by default inherits permissions for users<\/strong> \/ groups and there may be a problem with the limit on our Bitbucket plan. Checking this option allows us to bypass this limitation.<\/p>\n\n\n\n

Also, just like on GitHub, we have here a button available to sync changes between the original repo and our copy. The important thing is that the sync only happens between main branches, although we can also manually select a different branch, another feature branch.<\/p>\n\n\n\n

Forking workflow<\/strong><\/h2>\n\n\n\n

We already know what fork <\/em>is, we also know how to create our own on three popular platforms. Now I will talk about how to properly work with its use and deliver changes to the original repository. In fact, I mentioned it at the beginning, but I didn’t say it’s a formalized process called Forking Workflow. We’ll talk about the different ways of working with Git another time, now just a few words in relation to today’s topic.<\/p>\n\n\n

\n
\"Get<\/a><\/figure><\/div>\n\n\n

The main advantages of git fork workflow are two things<\/strong> <\/strong>\u2013 branched flow, where everyone works on their own copy, and above all the fact that only the project maintainer can push to the original repo, so any changes have to go through their hands. Why is this an advantage? Because it is a control mechanism. It is the creator of the original design that decides what will be in the codebase and what will not. No matter how beautiful and functional the code someone wants to include is, it is the maintainer who decides whether that code will be there.<\/p>\n\n\n\n

Another advantage is that at some stage of the project, it can be split into two (or more) separate ones. For example, due to differences in development plans among maintainers, or because of the desire to create a commercial solution based on the existing one. Of course, there are still licensing issues here, but we will not deal with that now.<\/p>\n\n\n\n

Forking Workflow is very similar to Git Workflow (which I will tell you about the other day), but instead of dedicated branches, we have a dedicated, separate repo that is a copy of the original. Let’s go back to the example and the picture from the beginning of the article:<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n