溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇“Git版本控制的知識點有哪些”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“Git版本控制的知識點有哪些”文章吧。
現在的軟件項目通常是由一個研發小組共同分析、設計、編碼、維護以及測試的
針對團隊開發需要解決以下問題：
備份多個版本，費空間，費時間
難于恢復至以前正確版本
難以解決代碼沖突困難
難于追溯問題代碼的修改人和修改時間
無法進行權限控制
項目版本發布困難
源代碼管理工具就是為了解決上述問題應運而生的
是維護工程藍圖的標準做法，能追蹤工程藍圖從誕生一直到定案的過程。是一種記錄若干文件內容變化，以便將來查閱特定版本修訂情況的系統
如果是團隊開發，使用版本控制是強制性的！
如果是單人開發，也強烈建議現在就開始使用版本控制!
使用版本控制可以：
不會對現有工作造成任何損害
不會增加工作量
添加新的功能拓展時，會變得更加容易
CVS 開啟版本控制之門
CVS 1990年誕生，遠古時代的主流源代碼管理工具
SVN 集中式版本控制之王者
SVN:又稱subversion，是CVS的接班人，是一款集中式源代碼管理工具。曾經是絕大多數開源軟件的代碼管理工具(google code)，前幾年在國內軟件企業使用最為普遍
GIT 分布式版本控制之偉大作品
GIT:一款分布式源代碼管理工具，目前國內企業幾乎都已經完成了從SVN到GIT的轉換
集中式源代碼管理
分布式源代碼管理
分布式和集中式的最大區別在于：
在集中式下, 開發者只能將代碼提交到服務器, 在分布式下, 開發者可以本地提交
在集中式下, 只有遠程服務器上有代碼數據庫, 在分布式下, 每個開發者機器上都有一個代碼數據庫
SVN(集中式)
GIT(分布式)
速度
在很多情況下，git的速度遠遠比SVN快
結構
SVN是集中式管理，git是分布式管理
其他
SVN使用分支比較笨拙，git可以輕松擁有無限個分支
SVN必須聯網才能正常工作，git支持本地版本控制工作
舊版本的SVN會在每一個目錄置放一個.svn，git只會在根目錄擁有一個.git
GIT是一款自由和開源的分布式版本控制系統，用于敏捷高效地處理任何或小或大的項目
在世界上所有的分布式版本控制工具中，git是最快、最簡單、最流行的
是Linux之父李納斯的第二個偉大作品
2005年由于BitKeeper軟件公司對Linux社區停止了免費使用權。
Linus為了輔助Linux內核的開發(管理源代碼),迫不得己自己開發了一個分布式版本控制工具，從而Git誕生了
如果想學好GIT必須先了解GIT的工作原理
工作區(Working Directory): 倉庫文件夾里面, 除了.git目錄以外的內容
版本庫(Repository):.git目錄, 用于存儲記錄版本信息
版本庫中的暫緩區(staga):
版本庫中的分支(master): git自動創建的第一個分支
版本庫中的**HEAD指針:**用于指向當前分支
git add和git commit命名作用
git add: 把文件修改添加到暫緩區
git commit: 把暫緩區的所有內容提交到當前HEAD指針指向的分支
多人開發時需要一個共享版本庫, 單人開發初始化一個本地庫即可
共享版本庫的形式:
本地共享庫: 文件夾/U盤/硬盤
遠程共享庫: 自己搭建git服務器/托管到第三方平臺(github/oschina等)
無論是單人開發還是多人開發, 客戶端都可以使用命令行或者圖形化界面使用git
git help ：git指令幫助手冊
查看其他指令的做法：git help 其他指令
git init : 倉庫初始化(個人倉庫)
HEAD: 指向當前分支的一個提交 description: 項目的描述信息 config: 項目的配置信息 info/: 里面有一個exclude文件，指定本項目要忽略的文件 objects/: Git對象庫(commit/tree/blob/tag) refs/: 標識每個分支指向哪個提交 hooks/: 默認的hook腳本
倉庫文件目錄
GIT設置配置信息
配置用戶名：git config user.name "用戶名"（用于跟蹤修改記錄）
配置郵箱：git config user.email "郵箱"（用于多人開發間的溝通）
git config -l : 查看配置信息
git config -e : 編輯配置信息
git status ：查文件的狀態
查看某個文件的狀態：git status 文件名
查看當前路徑所有文件的狀態：git status
git add ：將工作區的文件保存到暫緩區
保存某個文件到暫緩區：git add 文件名
保存當前路徑的所有文件到暫緩區：git add .（注意，最后是一個點 . ）
git commit：將暫緩區的文件提交到當前分支
提交某個文件到分支：git commit -m ”注釋” 文件名
保存當前路徑的所有文件到分支：git commit -m ”注釋”
git log ：查看文件的修改日志
查看某個文件的修改日志：git log 文件名
查看當前路徑所有文件的修改日志：git log
用一行的方式查看簡單的日志信息：git log ––pretty=oneline
查看最近的N次修改：git log –N（N是一個整數）
git diff ：查看文件最新改動的地方
查看某個文件的最新改動的地方：git diff 文件名
查看當前路徑所有文件最新改動的地方：git diff
git reflog ：查看分支引用記錄（能夠查看所有的版本號）
git rm：刪除文件（刪完之后要進行commit操作，才能同步到版本庫）
git reset：版本回退（建議加上––hard參數，git支持無限次后悔）
回退到上一個版本：git reset ––hard HEAD^
回退到上上一個版本：git reset ––hard HEAD^^
回退到上N個版本：git reset ––hard HEAD~N（N是一個整數）
回退到任意一個版本：git reset ––hard 版本號（版本號用7位即可）
Git忽略提交規則 - .gitignore配置
別看了, 你想要的都在這企業開發專用鏈接
# 表示此為注釋,將被Git忽略*.a 表示忽略所有 .a 結尾的文件!lib.a 表示但lib.a除外/TODO 表示僅僅忽略項目根目錄下的 TODO 文件，不包括 subdir/TODO build/ 表示忽略 build/目錄下的所有文件，過濾整個build文件夾； doc/*.txt 表示會忽略doc/notes.txt但不包括 doc/server/arch.txt bin/: 表示忽略當前路徑下的bin文件夾，該文件夾下的所有內容都會被忽略，不忽略 bin 文件 /bin: 表示忽略根目錄下的bin文件 /*.c: 表示忽略cat.c，不忽略 build/cat.c debug/*.obj: 表示忽略debug/io.obj，不忽略 debug/common/io.obj和tools/debug/io.obj **/foo: 表示忽略/foo,a/foo,a/b/foo等 a/**/b: 表示忽略a/b, a/x/b,a/x/y/b等!/bin/run.sh 表示不忽略bin目錄下的run.sh文件*.log: 表示忽略所有 .log 文件 config.php: 表示忽略當前路徑的 config.php 文件 /mtk/ 表示過濾整個文件夾*.zip 表示過濾所有.zip文件/mtk/do.c 表示過濾某個具體文件 被過濾掉的文件就不會出現在git倉庫中（gitlab或github）了，當然本地庫中還有，只是push的時候不會上傳。 需要注意的是，gitignore還可以指定要將哪些文件添加到版本管理中，如下：!*.zip!/mtk/one.txt 唯一的區別就是規則開頭多了一個感嘆號，Git會將滿足這類規則的文件添加到版本管理中。為什么要有兩種規則呢？ 想象一個場景：假如我們只需要管理/mtk/目錄中的one.txt文件，這個目錄中的其他文件都不需要管理，那么.gitignore規則應寫為：：/mtk/* !/mtk/one.txt 假設我們只有過濾規則，而沒有添加規則，那么我們就需要把/mtk/目錄下除了one.txt以外的所有文件都寫出來！ 注意上面的/mtk/*不能寫為/mtk/，否則父目錄被前面的規則排除掉了，one.txt文件雖然加了!過濾規則，也不會生效！ ---------------------------------------------------------------------------------- 還有一些規則如下： fd1/* 說明：忽略目錄 fd1 下的全部內容；注意，不管是根目錄下的 /fd1/ 目錄，還是某個子目錄 /child/fd1/ 目錄，都會被忽略； /fd1/* 說明：忽略根目錄下的 /fd1/ 目錄的全部內容； /* !.gitignore !/fw/ /fw/* !/fw/bin/ !/fw/sf/ 說明：忽略全部內容，但是不忽略 .gitignore 文件、根目錄下的 /fw/bin/ 和 /fw/sf/ 目錄；注意要先對bin/的父目錄使用!規則，使其不被排除。
git init --bare : 倉庫初始化(共享倉庫)
注意: 不要直接在共享倉庫中編寫代碼
git clone：下載遠程倉庫到本地
下載遠程倉庫到當前路徑：git clone 倉庫的URL
下載遠程倉庫到特定路徑：git clone 倉庫的URL 存放倉庫的路徑
git pull：下載遠程倉庫的最新信息到本地倉庫
git push：將本地的倉庫信息推送到遠程倉庫
提交時如果遠程倉庫有其它人提交的最新代碼, 必須先pull, 再提交
沖突解決:
當多個人同時修改了同一個文件時, 后提交的需要先從服務器pull代碼到問題, 手動解決完沖突之后再push到遠程服務器
<<<<<<< HEAD 你本地的新增的代碼======= 服務器上和你沖突的代碼>>>>>>> e9609de28b65bf97539f94c6458cdebdf2711c9f
中心倉庫：包含master和develop兩個分支
分支分類
主要分支：master和develop分支
支持性分支：特性分支，發布分支，熱補丁分支
對于商業級項目，真正開發過程中都是基于develop分支進行的，develop分支是開發主線！
master分支中，只存放相對穩定的分支，例如：0.1版本, 0.2版本
在實際產品開發中，需要“規劃版本”，例如：將100個功能規劃到5個不同的版本上
發現bug，要基于“上一個最穩定的版本”進行修復，這是熱補丁分支存在的意義！
理解清楚版本管理分支的特性，是迭代式開發的重要基礎！
git branch : 查看所有分支
git branch 分支名稱 : 創建分支
新創建的分支中的內容和master分支中的內容一樣
git checkout 分支名稱 : 切換到指定分支
git merge 分支名稱 : 合并分支
將當前所在分支和指定名稱分支進行合并
git branch -d 分支名稱 : 刪除指定分支
不能在當前分支中刪除自己
經常更新：降低沖突的可能性
提交前需在本機測試通過：降低將問題代碼傳到版本庫
提交時一定寫備注：方便其他員工查看和自己以后回顧
對于不需要提交的文件不要提交到版本庫
提示:
每次提交之前先更新
每天下班前提交當天編譯通過的代碼
每天上班第一件事情更新前一天的代碼
1.注冊GitHub賬號
2.登錄GitHub
3.點擊你的倉庫
4.創建一個新的倉庫
5.新建的倉庫可以下載, 但是提交需要賬號密碼
6.配置SSH Key
6.1打開git 命令行工具
輸入指令ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
6.2復制剛才生成的公鑰
6.3將生成好的SSH Key 添加到GitHub
6.4測試是否配置成功 ssh -T git@github.com
如果后面出現 : Hi ****! You’ve successfully authenticated, but GitHub does not provide shell access.證明成功
7.利用SSH Key操作GitHub
和 GitHub 方法相同
以上就是關于“Git版本控制的知識點有哪些”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
