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
- Git is a distributed version control system to manage file versions, especially useful for collaborating or cross-device editing and not just for code files.
- GitHub is a website which adopts and extend Git, provides a friendly GUI and are mainly used by developers.
git configto denote identity
- Basic Git workflow sub commands include
- Git has 3 states - Working Tree, Staging Area and Local Repo
- Git keeps multiple different working version as branches
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 https://devopscube.com/wp-content/uploads/2015/08/GIT-BASICS.png.]
In more complicated usage cases, the state-changing manipulation commands can be shown as the following graph.
[The above image is adopted from http://www.moxie.io/images/git-operations.png.]
Another version of the state-changing manipulation summary with GitHub
pull request concepts is as follows.
[The above image is adopted from http://www.ntu.edu.sg/home/ehchua/programming/howto/images/Git_StorageDataFlow.png.]
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
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 https://buildamodule.com/video/change-management-and-version-control-deploying-releases-features-and-fixes-with-git-how-to-use-a-scalable-git-branching-model-called-gitflow#viewing.]
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:
- create a development branch when
initialize git repository and always work on this branch instead of the default
- use the default
masterbranch to denote file versions for production and generally only does
mergetasks on this branch
- use separate branch for bug fixing tasks, such as
- use separate branch for new feature ideas or requested utilities, such as
- ? possibly [not] delete the branch after
merged to mainstream branch such as
masterfor branches like
Collaborating with Others or More than One Device
Some common requirements are like the following:
- You start writing a report at your work place on the desktop computer but want to finish it after work on your own computer at home
- You and your colleges need to finish a report based on the same set of materials at the same time but mainly deal with different part
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 push and
git fetch which basically deals with collaboration.
Forecast of Git Advanced User Guide
- Give a better description of using git to collaborate
- Git power in level 3 is not the final power where
- Git usage problems and solution,
- Git tools for more like branch graphing
- 7.3 Git Tools - Stashing and Cleaning
* cached version, generated at 2019-06-21 23:17:50 UTC.
Subscribe by RSS