Introduction to Git - Continued

It has been about one year since I gave the presentation for my team and published my Introduction to Git slides in last August. But there are in fact a lot of information which cannot be revealed from just the published slides, especially for the last several slides, so I decide to spend some time to compose a git user guide as the complementary.

Review of Git Introduction

Since little description for the last 2 steps provided in the published slides, this article would describe them first.

The Three States of Git

According to 1.3 Getting Started - Git Basics, the three states are "modified", "staged" and "committed" states which are usually represented by "working directory / working tree", "staging area" and "local repository".

  • Committed means that the data is safely stored in your local database.
  • Modified means that you have changed the file but have not committed it to your database yet.
  • Staged means that you have marked a modified file in its current version to go into your next commit snapshot.

The states of files are altered with commands git add and git commit as the following graph shows.

[The above image is adopted from]

In more complicated usage cases, the state-changing manipulation commands can be shown as the following graph.

[The above image is adopted from]

Another version of the state-changing manipulation summary with GitHub fork and pull request concepts is as follows.

[The above image is adopted from]

The Branches of Git

As the snapshots of files in history are git commits, the different file versions in the same time slot are git branches. From my understanding, git branches can be viewed as different tags attached to the derived commits which are base on the some base commits. Beyond the common concepts of tags, git branches can also be merged. (Or the merge action can be viewed as build a new tag under the same name in a higher hierarchy level which consists 2 children (generally a binary tree where each parent node has a child with the same name))

Taken snapshots in the history and different versions at same time slot, git shows its power in level 2. (If the power out of commit or branch solely is in level 1). With git power in level 2, different "final" version of same project can be co-exist. [As powerful as you can imagine.]

A successful git branching demo is as follows.

[The above image is adopted from]

Take the above "gitflow" demo as example, the blue dot on the most right can represent files I submit to public, and the yellow dot on the most right can represent files I submit to my boss for discussing what I plan to achieve. While both the version I submit to public or to my boss contains common content which can be shown as the red dot on the most right.

From my point of view, a good practice of development with git branch can be like the following:

Collaborating with Others or More than One Device

Some common requirements are like the following:

Some solutions for cross-device collaborating includes AirDrop and Handoff provide Apple Products, File Synchronizing provided by Dropbox, OneDrive, Google Drive and so on; Some solutions for live collaborating includes Microsoft Office, Google Docs, Teletype(beta) for Atom and so on. But there are still some problems like you don't have enough space in your Synchronizing Drive or you don't want to be disturbed by other cursors, then git can have a rule in such conditions with git power in level 3. The git power in level 3 can be carried out with commands as git pull, git push and git fetch which basically deals with collaboration.

Forecast of Git Advanced User Guide


* cached version, generated at 2019-06-21 23:17:50 UTC.

Subscribe by RSS