Why Git for your organization
Feature Branch Workflow: One of the biggest advantages of Git is its branching capabilities. Unlike centralized version control systems, Git branches are cheap and easy to merge. This facilitates the feature branch workflow popular with many Git users.
Distributed Development: In SVN, each developer gets a working copy that points back to a single central repository. Git, however, is a distributed version control system. Instead of a working copy, each developer gets their own local repository, complete with a full history of commits.
Pull Requests: A pull request is a way to ask another developer to merge one of your branches into their repository. This not only makes it easier for project leads to keep track of changes, but also lets developers initiate discussions around their work before integrating it with the rest of the codebase.
Faster Release Cycle: The ultimate result of feature branches, distributed development, pull requests, and a stable community is a faster release cycle. These capabilities facilitate an agile workflow where developers are encouraged to share smaller changes more frequently. In turn, changes can get pushed down the deployment pipeline faster than the monolithic releases common with centralized version control systems.
Getting Started - Installing Git
Install Git - Atlassian(https://www.atlassian.com/git/tutorials/install-git)
Git GUI Clients Guide：GUI Clients
Tags are ref’s that point to specific points in Git history.
git tag is generally used to capture a point in history that is used for a marked version release (i.e. v1.0.1).
Lightweight tags and Annotated tags:
Annotated tags store extra meta data such as: the tagger name, email, and date. This is important data for a public release. Lightweight tags are essentially ‘bookmarks’ to a commit, they are just a name and a pointer to a commit, useful for creating quick links to relevant commits.
git tag <tagname>
创建 Annotated Tags
git tag -a v1.4
git tag -l *-rc*
默认情况下打的 tag 是在当前 HEAD 所在的 commit 上，若要在其他的 commit 上打 tag，需要加上 commit SHA hash
git tag -a v1.2 15027957951b64cf874c3557a0f3547bd83b3ff6
替换已有的 tag：默认情况下打重复的 tag 是会报错的，这时候需要加上
git tag -a -f v1.4 15027957951b64cf874c3557a0f3547bd83b3ff6
将 tag 推送到远程仓库
git push origin v1.4
$ git tag
The high-level function of
git blame is the display of author metadata attached to specific committed lines in a file. This is used to explore the history of specific code and answer questions about what, how, and why the code was added to a repository.
git log command displays committed snapshots. It lets you list the project history, filter it, and search for specific changes.
git log 与
git status 的区别
git log -n <limit>
将每个 commit 的信息压缩为一行展示。
git log --oneline
展示每一次 commit 中哪些文件变更及具体的行数。
git log --stat
展示每一次 commit 完整的变更内容。
git log -p
git log --author="<pattern>"
👍 搜索 commit message 匹配
<pattern>的 commits 并展示，
git log --grep="<pattern>"
<until>可以是：commit ID, a branch name, HEAD, or any other kind of revision reference.
git log <since>..<until>
git log -- <file>
git log -G"<regex>"
A few useful options to consider. The –graph flag that will draw a text based graph of the commits on the left hand side of the commit messages. –decorate adds the names of branches or tags of the commits that are shown. –oneline shows the commit information on a single line making it easier to browse through commits at-a-glance.
git log --graph --decorate --oneline
Both of these commands are designed to integrate changes from one branch into another branch—they just do it in very different ways.
The major benefit of rebasing is that you get a much cleaner project history.
There are two trade-offs for this pristine commit history: safety and traceability.
The Merge Option
git checkout feature
git merge 的好处在于它是一个非破坏性(non-destructive)的操作，保留了变更历史，但同时也增加了多余的 commit。
The Rebase Option
git checkout feature
Interactive Rebasing 使你能够在 rebase 之前将你的 commit 历史做修改。
# To begin an interactive rebasing session, pass the i option to the git rebase command:
Project history that looks like the following:
⚠️ Never use it on public branches.
git revert all let you undo some kind of change in your repository, and the first two commands can be used to manipulate either commits or individual files.
- A checkout is an operation that moves the HEAD ref pointer to a specified commit.
- A revert is an operation that takes a specified commit and creates a new commit which inverses the specified commit.
- A reset is an operation that takes a specified commit and resets the “three trees” to match the state of the repository at that specified commit.
Checkout and reset are generally used for making local or private 「undos」. They modify the history of a repository that can cause conflicts when pushing to remote shared repositories. Revert is considered a safe operation for 「public undos」 as it creates new history which can be shared remotely and doesn’t overwrite history remote team members may be dependent on.
|Command||Scope||Common use cases|
||Commit-level||Discard commits in a private branch or throw away uncommited changes|
||File-level||Unstage a file|
||Commit-level||Switch between branches or inspect old snapshots|
||File-level||Discard changes in the working directory|
||Commit-level||Undo commits in a public branch|
Reset A Specific Commit
The following command moves the
hotfixbranch backwards by two commits.
git checkout hotfix
Checkout old commits
When passed with a branch name, it lets you switch between branches.
git checkout hotfix8
You can also check out arbitrary commits by passing the commit reference instead of a branch.
git checkout HEAD~2
Undo Public Commits with Revert
The following command will figure out the changes contained in the 2nd to last commit, create a new commit undoing those changes, and tack the new commit onto the existing project.
git checkout hotfix
You can also think of git revert as a tool for undoing committed changes, while git reset HEAD is for undoing uncommitted changes.
Git hooks are scripts that run automatically every time a particular event occurs in a Git repository. They let you customize Git’s internal behavior and trigger customizable actions at key points in the development life cycle.
Hooks can reside in either local or server-side repositories, and they are only executed in response to actions in that repository.
6 of the most useful local hooks:
The first 4 hooks let you plug into the entire commit life cycle, and the final 2 let you perform some extra actions or safety checks for the git checkout and git rebase commands, respectively.
All of the pre- hooks let you alter the action that’s about to take place, while the post- hooks are used only for notifications.
All of these hooks let you react to different stages of the
git push process.
The pre-receive hook is executed every time somebody uses git push to push commits to the repository. It should always reside in the remote repository that is the destination of the push, not in the originating repository.
update hook is called after
pre-receive, and it works much the same way. It’s still called before anything is actually updated, but it’s called separately for each ref that was pushed. That means if the user tries to push 4 branches,
update is executed 4 times. Unlike
pre-receive, this hook doesn’t need to read from standard input. Instead, it accepts the following 3 arguments:
- The name of the ref being updated
- The old object name stored in the ref
- The new object name stored in the ref
post-receive hook gets called after a successful push operation, making it a good place to perform notifications. For many workflows, this is a better place to trigger notifications than
post-commit because the changes are available on a public server instead of residing only on the user’s local machine. Emailing other developers and triggering a continuous integration system are common use cases for post-receive.
git cherry-pick is a powerful command that enables arbitrary Git commits to be picked by reference and appended to the current working HEAD. Cherry picking is the act of picking a commit from a branch and applying it to another.
git cherry-pick can be useful for undoing changes. For example, say a commit is accidently made to the wrong branch. You can switch to the correct branch and cherry-pick the commit to where it should belong.
SSH (SECURE SHELL) 『 SSH 官网的介绍 』
Relevant Terminology，Git Commands Glossary
Command Line Cheat Sheet
Version Control Best Practices，中文版
Authentication with SSH Public Keys
Handling Large Files with LFS
Workflows with git-flow
Pro Git 『 Pro Git 在线书籍 』
从 Subversion 过渡到 Git