Git Research

Git is a version control system.

Why we need a version control system?

With the help of the version control system, we can compare changes between two different state of the same file. We can revert back the previous state of the file, and in this way, if our work in the file gets worse, we can always go back to the known previous safe state. Also, we can collaborate with other developers and keep our code database tidy.

General Information

Git is created by Linux community and Linus Torvalds the guy who created Linux kernel and it is a distributed version control system. It means there is no dependency for a central server. Also, every clone of the repository contains a full history of files, not just the final state of files. So every clone is also a backup of the repository. Git stores files as snapshots, doesn't store differences between files as some version control systems do. It also doesn't store if a file is unchanged, it just refers to the previous identical state.

Almost every operation in Git(except clone, push etc.) is a local operation. This causes great speed and no dependency for another server. Git stores everything by their hash value. It uses the SHA-1 hash algorithm and hash values consist of 40 hexadecimal characters.

Basically, there are 3 sections in Git:

• Working Directory
• Staging Area
• Repository(.git directory)

In the working directory, there is one version of a project and there is probably development in progress. Staging area contains changes you want to be part of your next commit. So, it is just information about what will go into your next commit. The git repository contains history and metadata of the project. In the same manner, there are 3 stages of files:

• Modified: File is changed but not committed yet.
• Staged: File is selected for the next commit.
• Committed: File is committed to the repository.

Git Commands

git init initializes new Git repository.

git add adds files to Git you want to track.

git clone <url> gets a copy of the existing repository from the given url. Also, you can give an argument for the new directory name.

git status shows which files are in which states. (modified, staged, unmodified)

git add <path> begins tracking the file or the directory in the given path. Also, you can use the same command to stage file.

If you want to ignore some files(don't want to automatically add to Git or don't want to see untracked file warning), you can create a file named .gitignore and write the names of the files you want to ignore.

git diff shows the difference between staged area and working directory.

git diff --staged shows difference between staged area and last commit.

git commit commits the staging area. If you don't stage a file, after a commit, the file is still in the working directory as before.

git commit -a skips the staging area and commits all the tracked files.

git rm <filename> removes the file from the working directory and also from the index of Git.(means that you will not track the file and not get the untracked file warning.)

git rm --cached <filename> removes the file from Git, but the file is still in your working directory.

git mv <old path or old name> <new path or new name> renames or moves the file.

Branching

In every project, there is the main pathway for all contributors along with multiple side versions, features, tests, and trials. In version control systems creating a side path may - branching- be not that easy but Git, in particular, has a very fast and lightweight design that makes branching an instantaneous operation.

Every version that is created -and committed- in Git becomes a node in the acyclic undirected tree the VCS wanders about. Although the graph has a master branch that indicates the main pathway of the different versions, it is possible to create different branches and merge them when needed.

No operation in Git can alter a previously created node since the graph builds up on parent nodes and have unique IDs that depend on the parent. So changing the source code and committing it basically extends the tree further by new nodes. Merging branches, on the other hand, can form nodes that have multiple parents, therefore, decreases the number of branches by combining 2 different pathways.

In order to identify branches, tags -or pointers- are used. The main branch is called master but additional branches can be named by the coder. These pointers are used to change from branch to branch and operate on them. There is also a head pointer which points to the current node.

git branch <branchname> creates a pointer called "branchname" that points to the current node, head.

git checkout <anotherbranch> changes the head pointer from its current node to "anotherbranch"s last node so we can continue branching or developing from different nodes.

git merge <anotherbranch> merges "anotherbranch" and the master branch and creates a node -if needed- that is a child of both.

git mergetool Merging can be problematic in conmplex trees. Mergetool helps the coder to see the problem in the merging and act accordingly.

Working With A Remote Repository

While having a remote repository is not required, it is useful if you want your code to be accessible by various different computers. This allows multiple coders to work easily together without the need for a secondary communication channel. Following commands are related to working with a remote repository:

git push <remote name> <branch name> uploads the commits to a branch on the remote repository. Usually done after a commit or several commits.

git push uploads the commits to the previously specified remote repository and the currently checked out branch.

git fetch downloads the changes from a remote repository without applying them.

git merge Usually follows a git fetch to apply the changes to the working directory.

git merge <branch name> Merges the currently checked out branch with the specified branch and makes a merge commit. You may need to resolve merge conflicts before finishing the merge commit.

git pull Basically a git fetch followed by a git merge. It downloads the changes from a remote repository and applies the changes. Be careful as this may result in merge conflicts.