Branches vs clones vs forks

[Jonta]

@TaranVH: Submit a pull request, expressing your opinion on this. =)

Click the edit-pen on the readme, and GitHub will guide you through the next steps

[TaranVH]

...which readme? You didn't link to anything. Mine?
https://github.com/TaranVH/2nd-keyboard/edit/master/README.md

or yours?

https://github.com/Jonta/Taran-should-trash-this#readme

After lots of clicking, I realized that clicking the UPPER "readme.md" yields a different result from clicking the LOWER "readme.md"

https://github.com/Jonta/Taran-should-trash-this/blob/main/README.md

Github isn't guiding me through anything. I'm not sure what you want me to do...?

I'm also not sure if that image actually will be visible for you.

Anyway, you can use my full name if you like, I don't mind either way.

[Soneji]

It's fun watching @TaranVH learn GitHub 😂

[unsign3d]

@TaranVH the lower readme is actually a relatively new functionality for having a "table of content" of a markdown file, it's exactly the same as in MS Word when you're using different heading

@Jonta not sure what this is but popped into my feeds and since @TaranVH's videos helped me a lot, I'm always in for helping him XD

[Jonta]

@TaranVH The issue report is in this repository ("repo"), so I'm referring to the readme.md belonging to this repo

I can see both images you posted. In the 2nd one, the text in the blue box is what I'm referring to as guiding you through the process

Having your entire name is just an example of a modification. The goal is for you to make a change to someone else's repo, and turn that into a pull request, and then for me to merge that pull request into this project. =)

[unsign3d]

https://github.com/firstcontributions/first-contributions
I think this is a good guide about what @Jonta is trying to make you do @TaranVH

[TaranVH]

yyyyyyyeah that "guide" gives the steps, but doesn't explain what any of them actually DO.

What exactly does it mean to "fork" a repository?
and then I have to "clone" it? I thought that was the same thing.

What if I clone without forking?
what if I fork without cloning?

Does cloning require that it be forked first?
After forking, is there ANYTHING i can do besides cloning it?
If not, why the hell are they separate steps?

This tutorial https://github.com/firstcontributions/first-contributions/blob/master/gui-tool-tutorials/github-desktop-tutorial.md says "DO NOT CLONE THE ORIGINAL REPO" ... gosh! Sounds important. Too bad they don't explain why! And if it's so bad, why is it even an option?? Sure, let's just have a "ruin everything" button and tell people not to press it. That's good design.

And then, wait, I have to make a BRANCH?? What the hell is a branch?? Why do I need that?
What if I don't make a branch, what happens then?
Is a branch just, like, a folder?

Thanks, programming tutorials, for technically explaining everything, but effectively explaining nothing. This is on par.

[Soneji]

Clone means to download a repository onto your local computer.

Forking means to make a copy of another person's code repository. You would do this because you do not have access to that person's original repository, but you have access to your fork.

The reason why you would want to fork then clone is because when you make changes to a project you wouldnt be able to push them to the main repository, but only your fork.

This diagram and website may help explain what branches are:

https://www.atlassian.com/git/tutorials/using-branches

Branches are created to avoid multiple people working on the same files at the same time and overwriting each other.
You can make your branch and work on your stuff while someone else works on their stuff in a different branch.
When you are done with your individual features, you can merge multiple branches, such as a feature branch into the main branch.

[TaranVH]

I still do not understand at all.
The purple thing is a branch? and the green thing is a branch?
But they aren't being merged later down the line. Isn't that the point?
Also, where are "cloning" and "forking" on this diagram? Nowhere, that's where.
It just looks to me that "forking" is exactly the same thing as "branch"-ing.

[Jonta]

Branch: You want to experiment with a new feature, and you know it'll take some time. You want to be able to commit things to it, and push things, but not bother the main branch with it. It's a skunkworks thing, off in its own building. You can still fetch updates from main-branch into the one you're working on though. Here are the branches in this repo: https://github.com/Jonta/Taran-should-trash-this/branches

Clone: Your local copy of the repo. git clone. Internet's down? No problem. You can still keep working, and committing changes. Internet's back up? Now you can push those commits to the GitHub/GitLab/BitBucket/wherever-repository.

Fork: GitHub making collaboration easier. They clone the original repo, and now you have your own, and they keep a connection to the old one. In your fork https://github.com/TaranVH/Taran-should-trash-this which you made to create that change and then that pull request, it says "forked from Jonta/Taran-should-trash-this" and "This branch is 2 commits behind Jonta:main"

Confusion for newcomers: People who are already here, using the wrong terms for things

[TaranVH]

It's cool that a branch can keep taking stuff from the.... is it really called the "main branch"? why not call it a "trunk"? oh well.
"Clone" makes sense.
But I still don't understand the difference between a branch and a fork.
Also, now I'm finding out that after a merge, you have the option to delete the branch, and also have the option to delete the fork? wtf! what's the difference?

[unsign3d]

Forks

I will take a leap, and it will not be perfectly ok from a developer's point of view, but I hope it will clear up things.
Imagine a fork as a completely different product based on the previous product. LibreOffice for example is a fork of Openoffice, why? because they changed stuff and they have a different project, and if Openoffice doesn't want to implement the stuff from Libreoffice, then nothing happens :)

Branches

Within the same project maybe I would like to do changes, but a lot of people may be working on the same files simultaneously.
In that case what you do is: you have a main branch [as the source of truth in that moment], you create your own branch (imagine copy paste the file), you can do your own stuff without having the fear of the main branch to be modified during the time in which you're doing the modification, and then you can merge it back to the main branch.

in short

I think another way to explain the difference (at least on github) is:
Fork: import a copy into your account
Branches: different versions of what you are doing

[unsign3d]

is it really called the "main branch"? why not call it a "trunk"? 

tl;dr you can call it as you want, in some versioning systems actually I think they were calling it trunk. It's just a convention, in the past you had a master branch instead of main, but the name was changed in the community in order to have a more inclusive language.

edit: I remembered correctly, in SVN actually it's called trunk

[unsign3d]

btw @Jonta @TaranVH if I'm intruding, please tell me, I just want to help :P

[Jonta]

btw @Jonta @TaranVH if I'm intruding, please tell me, I just want to help :P

@unsign3d I think we're still striking the balance between [information overload] and [explaining something in different ways, hoping at least one of them will make sense]. =)

[TaranVH]

"LibreOffice for example is a fork of Openoffice"
Well, that makes perfect sense to me. And like... bitcoin cash is a fork of bitcoin, right?

But those things CANNOT be smushed(merged) back together again. Right?

So, a fork MIGHT be merge-able, but if it changes too much, it'll become incompatible with the main branch, meaning it can no longer be merged. riiiiiiiiight? And once it stops being compatible with the main branch, it's still a fork, but it is NO LONGER a branch...... yes? no? If not, exactly what is the terminology used for that?

[Jonta]

"LibreOffice for example is a fork of Openoffice"
Well, that makes perfect sense to me. And like... bitcoin cash is a fork of bitcoin, right?

According to Wikipedia: Yes - https://en.m.wikipedia.org/wiki/Bitcoin_Cash

But those things CANNOT be smushed(merged) back together again. Right?

Incorrect. They can be merged again.

Bitcoin is a special case, because merging that one with one of its forks would have large implications for peoples' finances

But you can merge "any" two pieces of software. Premiere and Notepad, Firefox and Minecraft, iOS and Android

So, a fork MIGHT be merge-able, but if it changes too much, it'll become incompatible with the main branch, meaning it can no longer be merged. riiiiiiiiight?

When you use the term "too much" it becomes a tautology. https://en.m.wikipedia.org/wiki/Tautology_(language)

"If you change the fork so much that it becomes incompatible with the original, it is incompatible with the original". To the Obviousmobile.

"Incompatible": What dat mean? For some, it might be something as small as American vs British spelling. Is your video editing style incompatible with that of iJustine? To some it is. To others, not.

The more different the fork is, the more likely that it's Incompatible™. Different could be "How much code do they share?"

If your question is actually closer to "cannot be smushed together by a dumb computer without problems occurring": Yes. In that way, they can become incompatible quite quickly. Especially if you use a very dumb computer program to smush.

And once it stops being compatible with the main branch, it's still a fork, but it is NO LONGER a branch...... yes? no? If not, exactly what is the terminology used for that?

Branch: Can be Incompatible™ with the main branch. See American vs British spelling. git branch is its own command, but git doesn't care what you do there

You see that French translation branch I started yesterday? I could remove all content from it. And replace that with the latest Linux kernel. It would still be in that French translation branch. Not super useful, just like merging Firefox and Minecraft, but definitely something one could do.

Is a branch just, like, a folder?

"Folder" becomes inadequate here. It's what you tell your uncle, who doesn't have to use git. It's like saying "yes, I'm a video guy, and so is Brandon". "Video guys", as opposed to Clarence, the accountant.

But if I want to work with you, I'll need the details "editor" and "cinematographer"

Edit: Branch vs fork: Intent

Branch: "I want to make a new feature, that will hopefully become part of the main branch when I'm done making it"
Fork: "The people making this stuff want something that we don't/We don't trust those idiots. But mayyybe other people won't trust Oracle to handle OpenOffice.org well either, and most people will start using LibreOffice instead of OpenOffice.org"

[TaranVH]

well.
When I say "merge," I'm pretty much talking about the auto-merge, "this branch has no conflicts with the main branch" kind of a thing.
Not MANUALLY merging notepad++ and Premiere.
If the word "merge" has such a horribly broad definition, it's not very useful.
Your final definitions of "fork" and "branch" are helpful.

[Soneji]

I still do not understand at all.
The purple thing is a branch? and the green thing is a branch?
But they aren't being merged later down the line. Isn't that the point?
Also, where are "cloning" and "forking" on this diagram? Nowhere, that's where.
It just looks to me that "forking" is exactly the same thing as "branch"-ing.

Each node in the diagram is a "commit" or a collection of changes of files, kind of like a save command. The lines are branches, there are 3 in the diagram. The diagram does not show the merging but yes ideally you would want to merge these changes.

The above definitions of forks are from a consumer perspective with regards to projects but from a git/versioning perspective, yes, a fork is just another branch of the code. The difference is the fork belongs to another person.

The person with the fork can then choose to request the original project owner to pull (Pull Request/PR) their changes back to the original project. This is essentially a process of merging branches which can happen to branches within the same project, or with branches across forks.