簡單的說說git有哪些常規的操作， 能夠滿足我們日常簡單的開發需求。
注意：git pull 執行的是 git merge, git pull -r 執行的是 git rebase首先我們要明確乙個概念： 就是每個commit都是乙份完整的**狀態， 用乙個commitid來作為唯一標誌。
從某個角度上來說， git維護的就是乙個commitid樹， 分別儲存著不同狀態下的**，所以我們對**的任何修改， 最終都會反映到commit上去。
所謂的分支其實就是乙個指向commitid的指標， 自己可以去.git/refs/heads裡去看看。
可以同時看到本地分支和遠端分支， 配合上前文介紹的git fetch -p可以第一時間檢視到最新的分支資訊。
其實就是建立乙個指標指向某乙個commitid
// 一般情況下，我們應該從master或者其他穩定分支來新增分支
git checkout -b lifuqiang/feature-user // 新建分支
git checkout lifuqiang/feature-user // 切換分支
git push origin lifuqiang/feature-usergit status // 檢視本地**狀態
git add files // 新增**到快取區
git commit -m '提交內容的備註' // 提交**到本地倉庫
git checkout -b branchname // 不加-b就是普通切換分支
git fetch -p // 同步遠端分支狀態
git pull -r origin branchname // fetch遠端**到本地，並且以rebase的方式合併**
git push origin branchname // 更新本地**到遠端
git checkout 10.php
git reset --hard commitid把本地開發**回滾到了乙個之前到版本，而且還沒有推到遠端， 怎麼才能找回丟失到**呢？ 你如果使用git log檢視提交日誌，並不能找回丟棄的那些commitid， 而git reflog卻詳細的記錄了每個操作的commitid， 可以讓你輕易的復原當時的操作並且找回丟失的**。
這也是乙個很實用的功能， 前文提過， 我們在開發中的時候盡量保持乙個較高頻率的**提交， 這樣可以避免不小心**丟失，但是真正合併**的時候，我們並不希望有太多的冗餘的提交記錄，而且rebase合併**的時候，會把每個commit都處理一下，有時候很會造成冗餘工作。 所以壓縮日誌之後不僅能讓commit記錄非常整潔， 同時也便於rebase合併**。
那麼如何壓縮commit記錄呢？
git rebase -i ：通過互動式的 rebase，提供對分支 commit 的控制，從而可以清理混亂的歷史。
這個大多數人應該都，聽說過，git操作有它自身的生命週期，在不同的生命週期，我們可以做一些自動化的事情。
舉兩個簡單的例子：
✦ pre-commit的時候我們可以做 eslint
✦ post-commit的時候，我們可以做利用 jenkins 類似的工具做持續整合
這兩個命令通常用來管理公用的第三方模組。比如一些通用的底層邏輯、中介軟體、還有一些可能會頻繁變化的通用業務元件。 當然，兩者還是有區別的。 git submodule 主要用來管理一些單向更新的公共模組或底層邏輯。 git subtree 對於部分需要雙向更新的可復用邏輯來說，特別適合管理。比如一些需要復用的業務元件**。在我之前的實踐中，我也曾用subtree來管理構建系統邏輯。
git實用指令
1.強制拉取遠端分支覆蓋本地 git fetch all git reset hard origin master git pull2.刪除分支 位址3.遠端分支刪除後，更新本地分支列表 git remote prune origin持續更新 4 強制推送本地到遠端 有覆蓋遠端 的風險 git pu...
git教程 git實用技巧
專案的安全性比較低。不能進行協同開發。不能進行版本控制。版本過多導致混亂。git是乙個分布式版本控制系統及協同開發工具。集中式版本控制工具。svn 分布式版本控制工具 git 找到安裝程式一直下一步 雙擊開啟，彈出命令視窗。自報家門 git config global user.name your ...
git 實用命令
1.比較當前分支與另一分支的指定檔案差異 git difftool 分支名 檔名注 使用difftool最好配置好視覺化的比較工具,本人常用beyondcompare 2.一旦遠端主機的版本庫有了更新，需要將這些更新取回本地，這時就要用到git fetch命令 git fetch 遠端主機上面命令將...