Great article, I just have a few things I need to point out that are wrong or inconsistent:
Q1 and forking:
I read all the comments that address this but I want to talk about it myself since none of them mentioned what I'm about to say.
You said the following:
A fork is a remote, server-side copy of a repository, distinct from the original. A fork isn't a Git concept really, it's more a political/social idea.
A clone is not a fork.
Well this is actually mostly wrong. A GitHub fork is a remote, server-side "copy". No it is not distinct from the original. And yes it is a actually a git concept under the hood. Lastly, a GitHub fork is actually a clone under hood.
The way GitHub does forks is through shallow clones (of depth 1, I think). So when you fork a repo on Github, on the server, under your own set of repos a shallow clone of the repo will get created. That shallow clone will only have the surface level commits of each branch with a alternates pointing to the original one. This is done to conserve space as it would be redundant to create a copy of the entire Git tree upon each fork. Moreover, by having the surface commits to build on top of, the forked repo can be integrated (pulled back) into the original repo without breaking history. Fun fact, clones can be done locally or remotely, meaning on the server the repo and its forked (ie. shallow cloned) counterparts can exist on the same hard-drive or different servers.
Q2 branches and pull requests:
You said:
A branch is just a separate version of the code.
Well this is not true since Git doesn't equal versioning, they are not the same thing. A branch is a pointer to a commit, state, snapshot (call it what you may) just like HEAD is a pointer "usually" to the commit the current checked-out branch points to.
You also said under about pull requests:
A pull request is when someone take the repository, makes their own branch...
They do not have to make their branch, pull requests can be done on existing branches. If they have to it is usually the contribution guide line of the project that requests it.
Q7 working trees and working directories:
You said:
The working tree/working directory/workspace is the directory tree of (source) files that you see and edit.
Well this is not accurate. This is also one the biggest misconceptions people have about Git. Working tree is a completely different thing from the working directory. Phrased in my own words, the working tree is the current file system tree state checked-out from the Git database. As for the working directory, it is not a Git concept, it is your normal working directory that you get by executing "pwd" for example. Most Git commands work on the entire working tree, meaning they do not care what your current working directory is. An exception is the status command, the paths given back after running it are relative to the working working directory but are checked based on the current working tree. Notice how the source you rephrased form just used workspace, which is another acceptable name for working tree. This is not your fault as the Git documentation is still inconstant about the distinction in some places, read this stackoverflow question for more info.
You also said:
The index/staging area is a single, large, binary file in...
Well no it is not necessarily large, it depends on the project size. I'm not going to go through the rest of the definition, the not part is at least correct.
Q9 using working copy:
Lastly, you used the term working copy here just cause the Atlassian tutorial used it without explaining that it is a synonym for staging/indexing area. This just takes away from the consistency of the article since you explain the the concepts beforehand using the latter terminology.
It was pointed out in other comments but I'll re-iterate. Taking content from other sources and re-presenting is difficult since they might not offer the best or most accurate explanation, it also opens more room for misinterpretation. I hope you actually end up fixing the points I provided for future reads as they might rightfully assume the information you provided is correct given that you link your sources.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great article, I just have a few things I need to point out that are wrong or inconsistent:
Q1 and forking:
I read all the comments that address this but I want to talk about it myself since none of them mentioned what I'm about to say.
You said the following:
Well this is actually mostly wrong. A GitHub fork is a remote, server-side "copy". No it is not distinct from the original. And yes it is a actually a git concept under the hood. Lastly, a GitHub fork is actually a clone under hood.
The way GitHub does forks is through shallow clones (of depth 1, I think). So when you fork a repo on Github, on the server, under your own set of repos a shallow clone of the repo will get created. That shallow clone will only have the surface level commits of each branch with a alternates pointing to the original one. This is done to conserve space as it would be redundant to create a copy of the entire Git tree upon each fork. Moreover, by having the surface commits to build on top of, the forked repo can be integrated (pulled back) into the original repo without breaking history. Fun fact, clones can be done locally or remotely, meaning on the server the repo and its forked (ie. shallow cloned) counterparts can exist on the same hard-drive or different servers.
Q2 branches and pull requests:
You said:
Well this is not true since Git doesn't equal versioning, they are not the same thing. A branch is a pointer to a commit, state, snapshot (call it what you may) just like HEAD is a pointer "usually" to the commit the current checked-out branch points to.
You also said under about pull requests:
They do not have to make their branch, pull requests can be done on existing branches. If they have to it is usually the contribution guide line of the project that requests it.
Q7 working trees and working directories:
You said:
Well this is not accurate. This is also one the biggest misconceptions people have about Git. Working tree is a completely different thing from the working directory. Phrased in my own words, the working tree is the current file system tree state checked-out from the Git database. As for the working directory, it is not a Git concept, it is your normal working directory that you get by executing "pwd" for example. Most Git commands work on the entire working tree, meaning they do not care what your current working directory is. An exception is the status command, the paths given back after running it are relative to the working working directory but are checked based on the current working tree. Notice how the source you rephrased form just used workspace, which is another acceptable name for working tree. This is not your fault as the Git documentation is still inconstant about the distinction in some places, read this stackoverflow question for more info.
You also said:
Well no it is not necessarily large, it depends on the project size. I'm not going to go through the rest of the definition, the not part is at least correct.
Q9 using working copy:
Lastly, you used the term working copy here just cause the Atlassian tutorial used it without explaining that it is a synonym for staging/indexing area. This just takes away from the consistency of the article since you explain the the concepts beforehand using the latter terminology.
It was pointed out in other comments but I'll re-iterate. Taking content from other sources and re-presenting is difficult since they might not offer the best or most accurate explanation, it also opens more room for misinterpretation. I hope you actually end up fixing the points I provided for future reads as they might rightfully assume the information you provided is correct given that you link your sources.