Git - HackMD

# Git  --- # Agenda - About Version Control System(VCS) - Distributed VCS: Git - Git Branch - Git Routine - *How Git Works* --- # About Version Control System(VCS) ---- - Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. - It allows you to - revert back to a previous state - compare changes over time - see who last modified something that might be causing a problem. - Using a VCS also generally means that if you screw things up or lose files, you can easily recover. ---- # VCS Evolution *think about the world without VCS...* ---- ```flow st=>start: copy files into another directory ↓ e=>end: ??? op1=>operation: 1. Local VCS ← op2=>operation: 2. Centralized VCS op3=>operation: 3. Distributed VCS st->op1->op2->op3->e ``` use VCS for yourself ---- # **Local** VCS ---- ![](https://git-scm.com/book/en/v2/images/local.png =x400) - It has a simple database that kept all the changes to files. ---- ```flow st=>start: copy files into another directory e=>end: ??? op1=>operation: 1. Local VCS ↓ op2=>operation: 2. Centralized VCS ← op3=>operation: 3. Distributed VCS st->op1->op2->op3->e ``` collaborate with people ---- # **Centralized** VCS ---- ![](https://git-scm.com/book/en/v2/images/centralized.png =x400) - Is has a single server that contains all the versioned files, and a number of clients that **check out** files from that central place. ---- ```flow st=>start: copy files into another directory e=>end: ??? op1=>operation: 1. Local VCS op2=>operation: 2. Centralized VCS ↓ op3=>operation: 3. Distributed VCS ← st->op1->op2->op3->e ``` Server died, we died, or disk died, the full history is gone ---- # **Distributed** VCS ---- - If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. - If the hard disk becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything -- the entire history of the project except whatever single snapshots people happen to have on their local machines. ---- ![](https://git-scm.com/book/en/v2/images/distributed.png =500x) ---- - Clients don’t just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history. - If any server dies, and these systems were collaborating via that server, any of the client repositories can be copied back up to the server to restore it. ---  # Distributed VCS: Git ----  - Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. - Git is easy to learn and has a tiny footprint with lightning fast performance. - It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCasewith features like cheap local branching, convenient staging areas, and multiple workflows. ---- # Git Basics - **Snapshots, Not Differences** - Nearly Every Operation Is Local - Git Has Integrity - Git Generally Only Adds Data - The Three States ---- **CVS** stores data **as a list of file-based changes** to a base version of each file. (delta-based) ![](https://git-scm.com/book/en/v2/images/deltas.png =600x) **Git** stores data **as snapshots** of the project over time. ![](https://git-scm.com/book/en/v2/images/snapshots.png =600x) ---- # Git Basics - Snapshots, Not Differences - **Nearly Every Operation Is Local** - Git Has Integrity - Git Generally Only Adds Data - The Three States ---- - Most operations in Git need only local files and resources to operate — generally no information is needed from another computer on your network. - If you’re used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. - Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous. ---- - Browse the history of the project, Git doesn’t need to go out to the server to get the history and display it for you— it simply reads it directly from your local database. This means you see the project history almost instantly. - If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally. ---- # Git Basics - Snapshots, Not Differences - Nearly Every Operation Is Local - **Git Has Integrity** - Git Generally Only Adds Data - The Three States ---- - Everything in Git is check-summed before it is stored and is then referred to by that checksum. - This means it’s impossible to change the contents of any file or directory without Git knowing about it. - This functionality is built into Git at the lowest levels and is integral to its philosophy. You can’t lose information in transit or get file corruption without Git being able to detect it. ---- - The mechanism that Git uses for this checksumming is called a SHA-1 hash. - This is a 40-character string composed of hexadecimal characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. - A SHA-1 hash looks something like this: ``` 24b9da6552252987aa493b52f8696cd6d3b00373 ``` ---- # Git Basics - Snapshots, Not Differences - Nearly Every Operation Is Local - Git Has Integrity - **Git Generally Only Adds Data** - The Three States ---- - When you do actions in Git, nearly all of them only add data to the Git database. - It is hard to get the system to do anything that is not undoable or to make it erase data in any way. - As with any VCS, you can lose or mess up changes you haven’t committed yet, but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository. ---- # Git Basics - Snapshots, Not Differences - Nearly Every Operation Is Local - Git Has Integrity - Git Generally Only Adds Data - **The Three States** ---- - Git has three main states that your files can reside in: - **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. - **Committed** means that the data is safely stored in your local database. ---- Working tree, staging area, and Git directory. ![](https://git-scm.com/book/en/v2/images/areas.png =x400) ---- - **The working tree** is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. - **The staging area** is a file, generally contained in your Git directory, that stores information about what will go into your next commit. - **The `.git` directory** is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer. ---- - The basic Git workflow goes something like this: - You modify files in your working tree. - You selectively stage just those changes you want to be part of your next commit, which adds only those changes to the staging area. - You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory. --- # Git Commands ---- 1. start a working area; 2. work on the current change ||||||| |:-:|:-:|:-:|:-:|:-:|:-:| |==init==|==clone==;|==add==|mv|==reset==|==rm==| 3. examine the history and state; 4. collaborate |||||| |:-:|:-:|:-:|:-:|:-:| |bisect|grep|==log==|show|==status==;| |==fetch==|==pull==|==push==| 5. grow, mark and tweak your common history |||||| |:-:|:-:|:-:|:-:|:-:| |==branch==|==checkout==|==commit==|diff|==merge==| |==rebase==|tag| --- # Git Branch - Branches in a Nutshell - Creating a New Branch - Switching Branches ---- # Branches in a Nutshell ---- ![](https://git-scm.com/book/en/v2/images/commit-and-tree.png) A commit and its tree ---- ![](https://git-scm.com/book/en/v2/images/commits-and-parents.png) Commits and their parents ---- ![](https://git-scm.com/book/en/v2/images/branch-and-history.png) A branch and its commit history ---- # Creating a New Branch ---- ```shell= git branch testing ``` ![](https://git-scm.com/book/en/v2/images/two-branches.png) Two branches pointing into the same series of commits ---- ![](https://git-scm.com/book/en/v2/images/head-to-master.png) HEAD pointing to a branch ---- # Switching Branches ---- ```shell= git checkout testing ``` ![](https://git-scm.com/book/en/v2/images/head-to-testing.png) HEAD points to the current branch ---- ```shell= git commit ``` ![](https://git-scm.com/book/en/v2/images/advance-testing.png) The HEAD branch moves forward when a commit is made ---- ```shell= git checkout master ``` ![](https://git-scm.com/book/en/v2/images/checkout-master.png) HEAD moves when you checkout ---- ```shell= git commit ``` ![](https://git-scm.com/book/en/v2/images/advance-master.png) Divergent history ---- # Basic Branching and Merging - Basic Branching - Basic Merging ---- # Basic Branching ---- ![](https://git-scm.com/book/en/v2/images/basic-branching-1.png) A simple commit history ---- ```shell= git branch iss53 git checkout iss53 # git checkout -b iss53 ``` ![](https://git-scm.com/book/en/v2/images/basic-branching-2.png) Creating a new branch pointer ---- ```shell= git commit ``` ![](https://git-scm.com/book/en/v2/images/basic-branching-3.png) The iss53 branch has moved forward with your work ---- ```shell= git checkout master git checkout -b hotfix git commit ``` ![](https://git-scm.com/book/en/v2/images/basic-branching-4.png) Hotfix branch based on master ---- ```shell= git checkout master git merge hotfix ``` ![](https://git-scm.com/book/en/v2/images/basic-branching-5.png) master is fast-forwarded to hotfix ---- ```shell= git branch -d hotfix git checkout iss53 git commit ``` ![](https://git-scm.com/book/en/v2/images/basic-branching-6.png) Work continues on iss53 ---- # Basic Merging ---- ```shell= git checkout master git merge iss53 ``` ![](https://git-scm.com/book/en/v2/images/basic-merging-1.png) Three snapshots used in a typical merge ---- ![](https://git-scm.com/book/en/v2/images/basic-merging-2.png) A merge commit ---- # Branching Workflows - Long-Running Branches - Topic Branches ---- ## Long-Running Branches ---- ![](https://git-scm.com/book/en/v2/images/lr-branches-1.png) A linear view of progressive-stability branching ![](https://git-scm.com/book/en/v2/images/lr-branches-2.png) A “silo” view of progressive-stability branching ---- # Topic Branches ---- ![](https://git-scm.com/book/en/v2/images/topic-branches-1.png =x500) Multiple topic branches ---- ![](https://git-scm.com/book/en/v2/images/topic-branches-2.png =x500) History after merging dumbidea and iss91v2 --- # Git Routine ---- # DEMO 1. create a new empty git repository 2. create a new file in git 3. modify this new file in git 4. branch this repository a copy version 5. modify this new file on original version 6. modify this new file on copy version 7. merge copy version into original version --- ### GitKraken context menu items - edit commit message - **reset** {v branch} to this commit - soft, mixed, hard - **revert** commit - push {v branch} and start a **pull request** - **cherrypick** commit - **squash** 2 commits - **rebase** {branch} onto {v branch} - fast-forward {v branch} to {branch} - merge {v branch} into {branch} ---- # Before going forward... ---- |context menu items|commands| |:-:|:-:| |create **b**ranch here|`git checkout -b `| |create **t**ag here|`git tag [-a] <t>`| |rename {**b**ranch}|`git branch -m `| |delete {**b**ranch}|`git branch -d `| |checkout {**b**ranch}|`git checkout `| |-|-| |:-:|:-:| |copy branch name to clipboard|copy commit id to clipboard| --- ## edit commit message ``` git commit --amend ``` > Replace the tip of the current branch by creating a new commit. ---- - In Git, the text of the commit message is part of the commit. - Changing the commit message will change the commit ID--i.e., the SHA1 checksum that names the commit. - Effectively, you are creating a new commit that replaces the old one. --- ## reset {v branch} to this commit ### soft, mixed, hard ``` git reset --soft git reset --mixed git reset --hard ``` > Reset current HEAD to the specified state ---- - reset master to this commit - soft - keep all changes - mixed - keep working copy but reset index - hard - discard all changes ---- ``` (v master)---- * | nth modification ... * | 1st modification * | initial commit ``` turn commits into... ---- ``` (v master)---- * | [nth modification - file(s) committed] * | nth modification - file(s) added * | nth modification - file(s) modified ... * | [1st modification - file(s) committed] (Soft)* | 1st modification - file(s) added (Mixed)* | 1st modification - file(s) modified (Hard)* | [initial commit] ``` --- ## revert commit ``` git revert <commit id> ``` > Revert some existing commits - Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them. - This requires your working tree to be clean (no modifications from the HEAD commit). ---- ``` (v master)----(*)| 2nd modification * | 1st modification * | initial commit ``` If I revert the commit of `2nd modification`... ---- ``` (v master)----(*)| Revert "2nd modification" * | 2nd modification * | 1st modification * | initial commit ``` If I revert the commit of `1st modification`... ---- conflicts, need to merge ``` (v master)----(*)| Revert "1st modification" * | 2nd modification * | 1st modification * | initial commit ``` --- ### push {v branch} and start a pull request - A pull request(PR) is a development process that provides a platform for discussion and review of a completed feature. - Its purpose is to notify team members that the feature has been completed and it is open for discussion or modifications. - The discussion usually occurs to improve the quality of the code; it is basically a code review process. --- ## cherrypick commit ``` git cherry-pick <commit id> ``` > Apply the changes introduced by some existing commits ---- ``` (feature)-----(*)| 3rd modification on feature * | [2nd modification on feature] * | 1st modification on feature (v master)---- * | 2nd modification on master * | 1st modification on master * | initial commit ``` If I cherrypick the commit of `2nd modification on feature`... ---- ``` (v master)----(*) | cherrypick [2nd modification on feature] (feature)----- (*)| 3rd modification on feature * | [2nd modification on feature] * | 1st modification on feature * | 2nd modification on master * | 1st modification on master * | initial commit ``` --- ## squash 2 commits ``` git merge --squash <commit id> ``` ---- ``` (v master)----(*) | cherrypick [2nd modification on feature] * | cherrypick [1st modification on feature] (feature)----- (*)| 3rd modification on feature * | [2nd modification on feature] * | 1st modification on feature * | 2nd modification on master * | 1st modification on master * | initial commit ``` - If I squash ... - the commit of `cherrypick [2nd modification on feature]` - the commit of `cherrypick [1st modification on feature]` ---- ``` (v master)----(*) | squash [1st & 2nd modification on feature] (feature)----- (*)| 3rd modification on feature * | [2nd modification on feature] * | 1st modification on feature * | 2nd modification on master * | 1st modification on master * | initial commit ``` --- ## merge {v branch} into {branch} ``` git merge ``` --- ## fast-forward {v branch} to {branch} ``` git merge --ff ``` --- ## rebase {branch} onto {v branch} [Git Rebase](https://hackmd.io/s/rJx3f16x7) --- ## git pull vs git fetch |cmd|definition| |:-:|:-:| |fetch|Download objects and refs from another repository| |pull|Fetch from and integrate with another repository or a local branch| > git pull is shorthand for git fetch followed by git merge FETCH_HEAD. --- # *How Git Works* [How Git Works](https://github.com/ChaoLiou/HowGitWorks) --- # The End