Understanding Git through images

ref: bytebytego, nopenoshishi

Git is a distributed version control system. Every developer maintains a local copy of the main repository and edits and commits to the local copy. The commit is very fast because the operation doesn’t interact with the remote repository. If the remote repository crashes, the files can be recovered from the local repositories.

A repository in Git is a storage for files, which can be remote or local.

• Remote repository is a repository where the source code is placed on a server on the Internet and can be shared by everyone.
• Local repository is a repository where the source code is located on your computer and only you can make changes.

Clone: Duplicate a copy of the remote repository into your development environment (local repository and working directory).

A working directory is not any special directory, but a directory where you always work on your computer. You can think of it as a directory where you can connect to the target directory that Git manages (in this case, project) with a Git staging area or local repository.

Changes to the source code are made through the working directory, the staging area. Actually, in the working directory, we work.

Add: move the modified file to the staging area. It is a feature of Git that there is a cushion before changes are reflected in the local repository. Add files from the working directory to the staging area and prepare them for commit.

Commit: register the file in the staging area to the local repository. At this moment, a commit object is created.

Push: when the work is done, you register the changes from the local repository into the remote repository

We can see the changing points in the file (or the differences between two versions of the file) with diff

Staging area:

• As development work grows, we often make many changes in one working directory
• What happens if you put all the changes in a local repository at once? In this case, when parsing the commits, you may not know where a feature was implemented
• In Git, it is recommended to do one commit per feature
• This is why there is a staging area where you can divide the commit unit into smaller units.

The concept of Git is to stage only what is needed, and then proceed with the work or commit ahead of time to promote efficient development that can be traced back through the history of each implementation.

The basic workflow is to clone once, then add, commit, and push for each working.

We create a branch to change and add files in multiple branches

• The files saved in the main branch are in ongoing use
• The reason for the separate branches is to work without affecting the currently running source code.
• create a branch: git branch <new branch>
• create a branch and moves you to that branch: git checkout -b <new branch>

Moving the branch is called checking out.

• The pointer to the branch you are currently working on is called HEAD
• moving from the main branch to the develop branch means changing the HEAD
• As in picture, both branches point to the commit named Atr3ul. You just added second.txt by committing Atr3ul in the main branch, so you are ahead of the commit f27baz.

Let's say you change second.txt in the develop branch and make a new commit

• Then the develop branch created a commit called m9sgle and pointed to that commit
• The current HEAD position (working branch position), what stage the file has been worked on, or the status of who is working on it is called status.

The arrow on the commit represents the relationship between a "parent" commit and a "child" commit. The assumption of parent←-child is that how much the child (commit) born from the parent (commit) has grown (changed).

The way of managing branches will vary on each development team. Here are two simple general models to grow branches in Git

• Git-Flow
  • master: Branch to release a product. No working on this branch
  • develop: Branch to develop a product. When ready to release, merge to release branch. No working on this branch
  • feature: Branch for adding features, merged into develop when ready to be released
  • hotfix: For urgent post-release work (critical bug fixes, etc.), branch off from master, merge into master, and merge into develop
  • release: For preparation of product release. Branch from develop with features and bug fixes to be released. When ready for release, merge to master and merge to develop.
• GitHub-Flow
  • is a simplified model of the Git-Flow. It consists of only master and feature
  • The important difference is the cushion of pull requests, which allows integration between branches. Pull request is to insert a process where a higher level developer reviews the code.

I am currently working on the feature branch and have created the following third.txt.

After some local work, you may be faced with a situation where the remote repository has been updated by another developer. In this case, you can use pull to re-install the information from the remote repository back into the local repository.

---

Tags

1. cat.tut