Git 的誕生是一個很是有趣的故事。1991年 Linus 開源了 Linux 內核,無數 Linux 愛好者在世界各地爲 Linux 編寫代碼,那麼問題來了,這些代碼該如何管理呢?起初 Linus 使用 BitKeeper(BitMover 公司的版本控制軟件)管理 Linux 的核心開發,後來 BitMover 中止了對 Linux 的支持,因而 Linus 秉承本身的版本本身寫的精神,花了兩週時間本身用 C 寫了一個分佈式版本控制系統,這就是 Git。php
傳統的設計方案咱們能夠簡單的分紅兩塊:工做目錄,遠程倉庫。可是做爲一個目標明確的分佈式版本控制系統,首先要作的就是添加一個本地倉庫。接着咱們選擇在工做目錄與遠程倉庫中間加一個緩衝區域,叫作暫存區。linux
若是仍是沒弄懂,那再來看看這篇精簡版的吧。git
看完還不會用的GIT操做,你就掐死我github
不管你是前端仍是後臺,不管是運維仍是移動端研發,GIT是逃避不了的東西,固然你說你要用SVN,那不在此次的討論範圍以內。很少說,請看下文GIT圖解分析,10分鐘學會git操做,固然下面的教程是爲實戰爲主,會跟你在別的網站看到的不同。算法
實戰是掌握一個工具最快的方法。segmentfault
Git 實戰詳解bash
什麼是版本庫?版本庫又名倉庫,英文名repository,你能夠簡單的理解一個目錄,這個目錄裏面的全部文件均可以被Git管理起來,每一個文件的修改,刪除,Git都能跟蹤,以便任什麼時候刻均可以追蹤歷史,或者在未來某個時刻還能夠將文件」還原」。服務器
實戰結束,來闖關試試學會了多少。框架
爲保你們都能順利通關,學到全部的知識點,接下來我會寫過關攻略,詳細介紹每一關的玩法。而且我不會直接給答案,而是演示整個過關的過程。
闖過這 54 關,點亮你的 Git 技能樹 (五) - 完結篇
附上備忘小手冊。
第一次鏈接遠程倉庫的配置
管理修改
撤銷修改(沒有提交的[commit])
刪除文件
建立與合併分支
Bug分支管理
遠程倉庫的操做
下面是本身學習使用git的經常使用的命令,還有些使用過程當中碰到問題的解決辦法,現整理以下。
相信通過上面的入門之後,再對比下面的圖解會更有收穫和體會。
本文背景,在實際項目中使用git已有一年多,發現很多同事雖然會使用經常使用git指令,但並不理解每一個指令對應的做用原理。今天靜下心總結下git 的基本理解:代碼的存在區域;本文以實際項目出發,理清使用git過程當中,代碼的遷徙流程。
場景: 提交了一個commit(該提交包含不少文件), 發現有問題, 須要回滾, 將線上分支(master)回滾到上一次commit。
git 的分支是它最明顯的特性, 大部分人聽別人推薦使用git都會聽到「git分支操做方便...」,對比其餘版本控制系統git 分支操做有難以置信的輕量,建立新分支幾乎瞬間完成,不一樣分支之間切換也很是快捷方便;本文將結合實踐以及繪圖概括、總結git常見的分支操做指令以及注意事項。
終於看完了,最後再來總結回顧一下。
我的以爲git是須要認真學的,雖然是個工具但不學習很容易把本身弄糊塗,但願這篇博客能夠在某些時候幫到您,讓您大概理解git的工做原理並把基本命令串起來。那麼下面就說一下Git重要的基本命令吧。
本文專一於支撐 Git 的圖結構以及這些圖的性質影響 Git 行爲的方式。經過了解底層,你能夠將你心中對 Git 的模型創建在事實之上,而不是基於經過積累使用經驗而創建的假設上。這個更真實的模型可讓你更好的理解 Git 作了什麼,正在作什麼以及將要作什麼。
Master 是 Git 默認的主分支,版本庫初始化之後,默認就是在主分支在進行開發。master分支代碼最完整,最乾淨,用於生產環境。
主分支只用來發布重大版本,平常開發應該在另外一條分支上完成。咱們把開發用的分支叫作Develop。
還有一些輔助開發分支,用於應對一些特定目的的版本開發。
在講git的reset和checkout的區別以前,不得不說說HEAD、Index、Working Directory三個區域。
git rebase因其「新手應當遠離的Git黑魔法」的名號名聲在外,但只要使用得當,其可使團隊開發變得無比輕鬆。本文將對比兩個類似的命令:git rebase與git rebase來區分它們的使用場景,最終將「黑魔法」歸入本身的工做流中。
本文主要講解下Git Rebase的基本概念用法、其內部原理以及咱們在真實項目中使用Git Rebase應該遵循的原則以及爲啥須要遵循這些原則。
diff是咱們天天都要使用的一個功能,每次提交時,我都習慣先用git diff --cached看看此次提交更改了些什麼,肯定沒問題,而後再git commit。git生成的diff很是直觀,直觀到我歷來都沒有去思考過diff是怎麼生成的,以爲這應該是很簡單的一件事,兩個文件作個對比,不就好了。
原本計劃本篇介紹Git分支的相關知識點與操做,可是準備的過程當中發現涉及到不少內部存儲原理,決定先介紹一下Git存儲原理,明白了這些,有助於理解後續內容,對Git的使用也會有很大幫助。
本文講述瞭如何使用 git rebase -i 及 git cherry-pick 實現代碼回滾。代碼回滾屬於高危操做,建議慎用!
深刻理解學習Git工做流(git-workflow-tutorial)
工做流其實不是一個初級主題,背後的本質問題實際上是有效的項目流程管理和高效的開發協同約定,不只是Git或SVN等VCS或SCM工具的使用。
這篇指南以你們在SVN中已經廣爲熟悉使用的集中式工做流做爲起點,按部就班地演進到其它高效的分佈式工做流,還介紹瞭如何配合使用便利的Pull Request功能,體系地講解了各類工做流的應用。
統一的工做流程是相當重要的,無論對於哪個行業的做業來講都同樣。對於咱們開發人員,工做流包含了開發時 Git 的使用規範、Repo 管理的規範、測試過程的規範、設計交互的管理規範等等。本篇文章重點說 Git 的使用規範和 repo 管理的規範。
Gitflow工做流定義了一個圍繞項目發佈的嚴格分支模型。雖然比功能分支工做流複雜幾分,但提供了用於一個健壯的用於管理大型項目的框架。
Gitflow工做流沒有用超出功能分支工做流的概念和命令,而是爲不一樣的分支分配一個很明確的角色,並定義分支之間如何和何時進行交互。除了使用功能分支,在作準備、維護和記錄發佈也使用各自的分支。固然你能夠用上功能分支工做流全部的好處:Pull Requests、隔離實驗性開發和更高效的協做。
本文定位於爲使用GIT標準分支開發流程的開發團隊新人提供一份參考指南,其中的內容都是咱們公司在研發團隊初創時所遵循的一些開發流程標準,通過近一年的實踐,雖然說還有不少不足,可是隨着團隊經驗的豐富和人員的擴張,我會適時地更新本文,分享咱們在使用GIT開發流程中遇到的問題和解決方案。
由於gitHub上的項目是公開的,不適合公司內部項目放在上面,而私人的須要收費,這絕非是咱們願意的。因此找了個跟gitHub很類似,可是又免費的gitLab。如今將搭建gitLab過程記錄一下留做參考。
用 Git Subtree 在多個 Git 項目間雙向同步子項目,附簡明使用手冊
何時須要 Subtree ?
一、當多個項目共用同一坨代碼,而這坨代碼跟着項目在快速更新的時候
二、把一部分代碼遷移出去獨立爲一個新的 git 倉庫,但又但願可以保留這部分代碼的歷史提交記錄。
Git-WebHook 自動化部署工具 - 支持Github / GitLab / Gogs / GitOsc
Git WebHook 是一個使用 Python Flask + SQLAchemy + Celery + Redis + React 開發的用於迅速搭建並使用 WebHook 進行自動化部署和運維繫統,支持:Github / GitLab / Gogs / GitOsc。
Python 使用 Tornado 框架實現 WebHook 自動部署 Git 項目
爲了方便開發測試或項目部署至服務器不那麼繁瑣,搞一個自動部署的小輪子也是必要的。小輪子須要涉及到 Coding 項目託管平臺(也能夠用 Github 平臺),Linux服務器的Nginx、Python( Tornado框架 )。同時配置項目託管平臺的我的私鑰或項目公鑰,保證 git pull 能直接拉取。
前言:本教程只面向那些我的開發者,想要本身在linux上搭建一個git中央倉庫用來上傳發布本身的項目。可是對於團隊來講可能有更高的要求,可使用gitlab搭建一個可視化的相似github的版本管理系統
使用 "5W1H" 寫出高可讀的 Git Commit Message