Definitions
When working with git, there are several areas we might be discussing. The most important areas are “working directory”, “staging”, “local repository”, and “remote repository”.
A repository without a working directory is called a “bare repository”.
The working directory is a location where your files live, with a reference back to the repository. It is possible to extract the files without keeping a reference to the repository.
Most working directories, and what we will assume for our discussion, have the bare repository within the .git directory (folder).
A remote repository is normally a bare repository located somewhere apart from your local working directory. This could be a different directory on the local machine, or it could be located on a remote, network connected system.
Creating a Local Version of a Remote Repository
This is what the remote repository looks like. A pretty simple version.
gitGraph commit id: "d6458df1e" commit id: "0ccd79797"
We don’t copy it, we clone it. The implication is that what we have in the local version is the same as what is in the remote version.
git clone ssh:git@github.com/author/book.git
This creates a directory named “book”, it clones/copies the bare repository from GitHub and places it in “book/.git”. It creates a “remote” reference within “book/.git/refs/remotes” named “origin”. With “origin” it creates a copy of all the branches that are in the remote repository, in our example, just “master”
The clone command then checks out the working directory into “books”. This would be the files “chapOne.md”, “chapTwo.md”, and “chapThree.md”. It creates a file in “books/.git/refs/heads” named master with the commit hash (identifier) of “0ccd79797”.
This is a copy of refs/remotes/origin/master.
Our diagram now looks something like:
%%{ 'gitGraph': {'rotateTag': true}}%%
gitGraph
commit id: "d6458df1e"
commit id: "0ccd79797" tag: "origin/main"At this point, you start work on your three files over two commits, your local repository now looks like:
%%{ 'gitGraph': {'rotateTag': true}}%%
gitGraph
commit id: "d6458df1e"
commit id: "0ccd79797" tag: "origin/main"
commit id: "7d918ddc0"
commit id: "f4b0d4086"Meanwhile, your editor has fixed some typos and grammar errors and pushed those to the remote repository.
gitGraph commit id: "d6458df1e" commit id: "0ccd79797" commit id: "cd6023b24" commit id: "ac6d2dd15"
These two look the same, but notice that the last two commits have different values/hashes. This is because they are different.
Since you are done with your edit, you attempt to send your changes back to the remote repository named “origin” via a push command. git push origin main This fails because there would be two versions of the repository if you did this, there can be only one.
To correct this, you first fetch an updated copy of repo.
gitGraph commit id: "d6458df1e" commit id: "0ccd79797" branch origin/main checkout origin/main commit id: "cd6023b24" commit id: "ac6d2dd15" checkout main commit id: "7d918ddc0" commit id: "f4b0d4086"
This is done with git fetch origin This command updates only the bare repo.
We now need to combine these two branches, this is done with git merge origin/main After which our local repository looks like.
gitGraph commit id: "d6458df1e" commit id: "0ccd79797" branch origin/main checkout origin/main commit id: "cd6023b24" commit id: "ac6d2dd15" checkout main commit id: "7d918ddc0" commit id: "f4b0d4086" merge origin/main id:"119c29222"
We then add some more to the story line and make one more commit.
gitGraph commit id: "d6458df1e" commit id: "0ccd79797" branch origin/main checkout origin/main commit id: "cd6023b24" commit id: "ac6d2dd15" tag: "origin/main" checkout main commit id: "7d918ddc0" commit id: "f4b0d4086" merge origin/main id: "119c29222" commit id: "040e63c01"
We do another fetch, there is nothing to do as nothing else has been added. We then push our commits back to the remote repository. git push origin main
gitGraph commit id: "d6458df1e" commit id: "0ccd79797" commit id: "cd6023b24" commit id: "ac6d2dd15" commit id: "7d918ddc0" commit id: "f4b0d4086" commit id: "119c29222" commit id: "040e63c01"
Because I’m not the program, there might be some small ordering issues in the final commit.
The point in all of this is that all of this magic happens behind the scenes. The program can do most merges with no assistance from you. In the rare cases where there is a merge conflict, it is relatively easy to manual merge the changes.
A merge conflict happens when two commits modify the same line of code. In your version, you had “Ciliorys hat” originally. You modified it to be “Billy-Bobs hat” Your editor had changed it to “Cilory’s hat”.
Now you have two edits to the same line. Git says, “You figure it out.” and shows you the two versions of the line, in context. You can pick one version or the other, or put in an entirely different version.
You choose the third option and put “Billy-Bob’s hat”. The world is good.
Conclusion
git is powerful. This discussion barely touches on the power of git.
There is an entire process of modifying code by “forking” a repository. When you are finished with your modifications, you can contribute them back to the original repository with a “Pull Request”.
Git has multiple methods of inserting code review and other tools into the process.
It is so powerful, It can be used to create a full wiki, on the fly. The raw files are served as wiki pages.
There is a method of doing a binary subdivision to find bugs that were introduced in the past. There is a method of tracking who introduced an errant line of code.
There are tools for pulling a commit out of the middle of a branch and applying it to a different branch, without taking the rest of the modifications.
In general, there only about a dozen commands that a user needs to know to work with git.
If you would like to work with git, there are communities ready to help you, there are multiple cloud providers that will allow you to host your repo on the web.