git

git

基础设置

设置用户名

git config --global user.name 'xxoo'  # xxoo为设置的用户名

　　--global参数表示这台机器上的全部的Git仓库都会使用这个配置

设置邮箱

git config --global user.email 'xxoo@126.com'  # xxoo@126.com为设置的邮箱

建立版本库

　　版本库又称仓库，能够理解为是一个目录，这个目录里面的全部文件均可以被git管理起来，没每一个文件的修改、删除，git都能跟踪，以便任什么时候刻均可以追踪历史，或者在未来某个时刻能够回滚还原。

建立版本库

mkdir learngit

切换目录

cd learngit

显示当前目录

pwd

初始化仓库

git init

　　此时，生成了一个.git的目录，其做用是git来跟踪管理版本库的，不能私自修改文件。

把文件添加到版本库

　　全部的版本控制系统，只能跟踪文本文件的改动，Git也不例外，好比TXT文件、网页、程序代码。坂本控制能够告诉你每次改动的内容及位置。图片、视频这些二进制的文件也能够由版本控制系统管理，可是没有办法跟踪文件的具体变化，只能知道问件大小的变化，具体改变内容没法追踪。

　　Word的格式是二进制的，因此没法使用坂本控制系统跟踪Word文件的改动。

　　尽可能使用utf-8编码。

添加文件到仓库

 　　使用命令git add告诉Git，把文件添加到仓库：

git add readme.text  # readme.txt为要添加的文件的名称

　　 这一步尚未提交，只是将修改的文件提交到暂存区。

提交文件到仓库

git commit -m 'wrote a readme file'  # -m后面跟的本次提交的说明

 　　commit 能够一次提交不少文件，因此能够屡次add不一样的文件，而后最后统一commit。例如：

git add file0.txt
git add file1.txt file2.txt
git commit -m 'add 3 files.'

文件修改提交

查看仓库当前的状态

git status

　　输入这条命令后，会提示当前仓库的状态，修改装填、提交状态，可是看不到具体的修改内容。

查看具体的修改内容

git diff readme.txt  # readme.txt为须要查看的文件的名称

　　它会显示具体的修改的内容，包含修改前的和修改后的。

　　其中，diff是difference的简写。

　　查看无误后，可使用git add命令提交修改后的文件到仓库。提交完后，可使用git status再次查看当前仓库的状态，最后使用git commit提交修改，完事儿以后能够再使用git status查看下当前仓库的状态。

退回

版本回退

 查看文件的修改历史记录

git log

　　显示从最近到最远的提交日志。

若是输出信息太多，能够加上--petty=oneline参数：

git log --pretty=oneline

　　在Git中，HEAD表示当前版本，也就是最新版本，上一个版本就是HEAD^，上上一个版本就是HEAD^^，当数量较多时，能够写成HEAD~100。

回退上一个版本

git reset --hard HEAD^

查看文件内容

cat readme.txt

回到下一个版本

　　当回退后悔以后，而且当前窗口尚未关闭，能够往上滚动，找到目标版本id，使用git reset --hard id 回到以前修改的最新的版本。

git reset --hard 1094a  # 1094a指的是以前版本的id号，不用所有都输进去，写5位便可。

　　版本id是使用SHA1算法自动生成的。

　　当关闭了当前窗口，找不到须要回滚的目标版本id时，可使用get reflog命令查看历史命令记录：

git reflog

工做区和暂存区

 工做区

　　电脑里能看到的目录，好比个人learngit文件夹就是一个工做区。

 版本库

 　　工做区有一个隐藏目录.git，这个不算工做区，而是Git的版本库。

　　Git的版本库里存了不少东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为咱们自动建立的第一个分支master，以及指向master的一个指针叫HEAD。

 

　　第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；

　　第二步是用git commit提交更改，实际上就是把暂存区的全部内容提交到当前分支。

 修改管理

　　能够分次git add 修改到暂存区，最后统一git commit。当git commit只提交暂存区中的内容，若是只是修改了，没有添加到暂存区，最终修改是不会提交到仓库的。

撤销修改

 　　将暂存区的修改撤销掉，从新放回工做区：

git reset HEAD readme.txt

 

 删除文件

 　　通常状况下，你一般直接在文件管理器中把没用的文件删了，或者用rm命令删了，版本库中还存在：

rm test.txt

 

 　　从版本库删除文件

git rm test.txt

 

 　　误删恢复版本库中的内容

　　　　git checkout实际上是用版本库里的版本替换工做区的版本，不管工做区是修改仍是删除，均可以“一键还原”。

git checkout -- test.txt

 

 　　命令git rm用于删除一个文件。若是一个文件已经被提交到版本库，那么你永远不用担忧误删，可是要当心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。

 远程仓库

添加远程仓库

生成SSH Key

ssh-keygen -t rsa -C 'xxoo.126.com'  # xxoo.126.com为你本身的邮箱

 

　　由于不须要保密，因此邮箱不须要设置任何密码，一路回车就能够。

　　在生成SSH Key之后，去根目录中将id_rsa.pub中的内容添加到github中就能够将代码推到github中。

　　根目录

cd ~  # 切换到根目录
pwd  # 查看根目录文件路径

　　而后在本身的电脑上进入到根目录，找到.ssh文件夹，就能够找到id_rsa.pub文件。其中id_rsa为私钥，不可泄露；id_rsa.pub为公钥，将其的内容复制到GitHub中。

　　GitHub设置SSH Key的图解：（以Windows 10为例）

　　GitHub容许你添加多个Key。假定你有若干电脑，只要把每台电脑的Key都添加到GitHub，就能够在每台电脑上往GitHub推送了。

 　　在GitHub上免费托管的Git仓库，任何人均可以看到喔（但只有你本身才能改）。因此，不要把敏感信息放进去。

 　　若是你不想让别人看到Git库，有两个办法，一个是交点保护费，让GitHub把公开的仓库变成私有的，这样别人就看不见了（不可读更不可写）。另外一方法就是创建本身的Git服务器。

 添加远程库

 GitHub上建立新仓库：（Windows 10为例）

　　3处写上本身起的仓库名便可。其余的不须要更改。

 关联远程仓库

　　关联本地仓库到远程仓库：

git remote add origin git@github.com:xxoo/learngit.git  # xxoo指本身的GitHub的用户名；learngit指本身上一步起的远程仓库的名称

　　添加后，远程库的名字就是origin，这是Git默认的叫法，也能够改为别的，可是origin这个名字一看就知道是远程库。

　　若是不当心关联错了，能够修改本地关联的远程仓库，首先须要删除已经关联的错误的GitHub帐户名：

git remote rm origin

 

　　接着从新关联就好了。 

　　将本地库的全部内容推送到远程库：

git push -u origin master

　　把本地库的内容推送到远程，用git push命令，其实是把当前分支master推送到远程。

 　　因为远程库是空的，咱们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在之后的推送或者拉取时就能够简化命令。

　　若是这一步报错提示找不到远程仓库，则删掉GitHub中的ssh key，从新生成一个写进去，重新关联本地库到远程库就好了。

　　后边在提交时，就不须要加-u了：

git push origin master

 

 　　把本地master分支的最新修改推送至GitHub。

SSH警告

　　第一次使用Git的clone或者push命令链接GitHub时，会获得一个警告：

The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?

 

 　　输入yes便可。由于Git使用SSH链接，而SSH链接在第一次验证GitHub服务器的Key时，须要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器。

 　　这个警告只会出现一次，后面的操做就不会有任何警告了。

 从远程库克隆

　　在GitHub上建立一个远程库，在建立的时候勾选上 Initialize this repository with a README，这样GitHub就会自动建立一个README.md文件。

　　从远程克隆一个本地库：

git clone git@github.com:xxoo/gitskill.git  # xxoo为本身的GitHub用户名；gitskill为远程库的名称

　　而后本地查看本身的目录，已经有了README.md文件了

cd gitskill
ls

　　GitHub给出的地址不止一个，还能够用https://github.com/michaelliao/gitskills.git这样的地址。实际上，Git支持多种协议，默认的git://使用ssh，但也可使用https等其余协议。

 　　使用https除了速度慢之外，还有个最大的麻烦是每次推送都必须输入口令，可是在某些只开放http端口的公司内部就没法使用ssh协议而只能用https。

 分支管理

 　　同一个项目，没我的都有本身的分支，相互之间互不影响，最后合并起来。

　　Git的分支不管是建立、切换和删除分支。Git都能在一秒以内完成。不管版本库的大小。

 建立与合并分支

 建立分支

　　建立分支dev，而后切换到dev分支：

git checkout -b dev

 

 　　-b 参数表示建立而且换，至关于：

git branch dev
git checkout dev

　　用git branch命令查看当前分支：

git branch

 

 　　git branch命令会列出全部分支，当前分支前面会标一个*号。

　　在当前dev分支上对readme.txt进行修改，而后进行提交：

git add readme.txt
git commit -m 'branch test'

　　dev分支的工做完成，切回到master分支：

git checkout master

　　切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！由于那个提交是在dev分支上，而master分支此刻的提交点并无变。

　　将dev分支的工做成果合并到master分支上：

git merge dev

　　git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就能够看到，和dev分支的最新提交是彻底同样的。

 　　Fast-forward，“快进模式”，也就是直接把master指向dev的当前提交，因此合并速度很是快。

删除分支

 　　合并完成后，就能够放心地删除dev分支了：

git branch -d dev

　　删除后查看分支：

git branch

 

 　　由于建立、合并和删除分支很是快，推荐使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工做效果是同样的，但过程更安全。

 解决冲突

　　当Git没法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

　　解决冲突就是把Git合并失败的文件手动编辑为咱们但愿的内容，再提交。

 　　使用git status命令能够查看冲突的文件：

git status

　　查看readme.txt：

cat readme.txt

　　结果以下：

Git is a distributed version control system.
Git is free distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes.
山丘 李宗盛
Creating a new branch is quick.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

 

 　　Git用<<<<<<<，=======，>>>>>>>标记出不一样分支的内容。

　　而后手动修改冲突的内容，再提交：

git add readme.txt
git commit -m 'conflict fixed'

　　这样，master分支和feature1分支变成了以下：

　　用带参数的git log能够看到分支的合并状况：

git log --graph --pretty=oneline --abbrev-commit
# 结果：
*   b92bc4e (HEAD -> master) conflict fixed
|\
| * 519c6d9 (feature1) AND simple
* | e42cbc9 & simple
|/
* 407c857 branch test
* 541a465 (origin/master) remove test.txt
* 4af3a5c add dsb file
* 64246fc add 李宗盛
* 7b1102e add 山丘
* e97c534 add changes
* db8f66f append index and create LICENSE
* 8f92663 add GPL
* 52698d0 add distributed
* fade207 worte a readmme file

 

 　　最后删除feature1分支：

git branch -d feature1

　　这样工做就完成了。

 分支管理策略

分支管理

 　　Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

　　若是要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就能够看出分支信息。

　　禁用Fast forward模式，采用--no-ff方式

　　首先建立一个分支dev，提交保存。回到主分支master，使用git merge：

git merge --no-ff -m 'merge with no-ff' dev

 

　　--no-ff参数表示禁用Fast formard。

　　由于合并要建立一个新的commit，因此加上一个-m参数，把commit描述写进去。

　　合并后，使用git log查看分支历史：

git log --graph --pertty=oneline --abbrev-commit

 

　　不使用Fast forward模式，merge后就像这样：

分支策略

 　　master分支应该是很是稳定的，也就是仅用来发布新版本，平时不能在上面干活；

 　　干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，好比1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

Bug分支

 　　在生产过程当中，碰见bug须要修复，可是当前还不能提交，可使用stash功能将当前工做现场保存起来，等之后恢复工做现场。

git stash

 

 　　使用git stash查看工做区，赶忙的就能够建立分支来修复bug：

git  status

　　首先须要肯定在哪一个分支上修复，假设从master分支上建立临时分支：

git checkout master

　　建立临时分支：

git checkout -b issue-101

 

 　　此时修复bug，而后提交：

git add readme.txt
git commit -m 'fix bug 101'

　　修复完成后切换到master分支上，完成合并，最后删除issue-101分支：

git checkout master

# 合并
git merge --no-ff -m 'merged bug fix 101'

 

　　如今就能够切换到dev分支上进行继续工做了：

git checkout dev

# 查看状态
git status

　　工做区是干净的，使用git stash list命令查看：

git stash list

　　恢复工做现场。通常使用git stash apply恢复，可是stash内容不会被删除，须要使用git stash drop来删除；另外一种方式就是使用git stash pop，恢复的同时也把stash内容删除了：

git stash pop

　　此时再次使用git stash list查看，就看不到stash内容了：

git stash list

　　能够屡次stash，回复的时候，先用git stash list查看，而后恢复指定的stash：

git stash apply stash@{0}

 

 Feature分支

　　若是要丢弃一个没有被合并过的分支，能够经过git branch -D <name>强行删除。

 　　在开发过程当中，须要添加一个新的功能，但又不但愿由于实质性的代码影响到master分支上的主程序，能够建立一个分支，针对这个功能进行开发：

　　建立分支：

git checkout -b feature-vuclan

　　开发完成：

git add vulcan.py

git status

gie commit -m 'add feature vulcan'

　　切回dev，准备合并：

git checkout dev

　　假如如今由于某些问题，这个功能不添加了，因此须要删除掉这个分支。

git branch -D feature-vulcan

　　　　使用-d没法删除，由于这个分支没有被合并，须要使用-D才能删除掉。

多人协做

 　　当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，而且，远程仓库的默认名称是origin。

查看远程库的信息

git remote

　　或者用git remote -v显示详细信息：

git remote -v

 

 　　若是没有推送权限，就看不到push的地址，只能看到fetch的地址。

 推送分支

 　　推送分支，就是把该分支上的全部本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

git push origin master

 

 　　若是要推送其余分支：

git push origin dev

　　master分支是主分支，所以要时刻与远程同步；

　　dev分支是开发分支，团队全部成员都须要在上面工做，因此也须要与远程同步；

　　bug分支只用于在本地修复bug，就不必推到远程了，除非老板要看看你每周到底修复了几个bug；

 　　feature分支是否推到远程，取决因而否合做在上面开发。

 抓取分支

 　　当另外一台主机从远程库clone是，默认状况下，只能看到本地的master分支。可使用git branch命令查看：

git branch

　　当这台主机须要在dev分支上开发，就须要建立远程origin的dev分支到本地，使用以下命令建立dev分支：

git checkout -b dev origin/dev

　　这样就能够在dev上继续修改，而后，将dev分支push到远程：

git add env.txt


git commit -m 'add env'


git push origin dev

 

　　如今这台主机已经提交了dev分支的env.txt文件，恰巧你如今也要提交这个文件，就会致使出现冲突，提示当前文件已经提交了。 

cat env.txt

git add env.txt

git commit -m 'add new env'

git push origin dev

# error: faild to push some refs to 'git@github.com:dragon-z/learngit'

　　推送失败，提交的内容冲突。解决这种状况的方式就是先用git pull 把最新的提交从origin/dev分支上抓下来，在本地合并，解决冲突后再推送：

git pull

　　若是git pull失败了，那是由于没有指定本地dev分支与远程origin/dev分支的链接，能够根据提示设置dev和origin/dev的链接：

git branch --set-upstream-to=origin/dev dev

　　设置完成在pull：

git pull

　　这样就能够了，可是合并有冲突，就须要手动解决，解决的方法和分支管理中的解决冲突彻底一致，解决后再push：

git commit -m 'fix env conflict'

git push origin dev

 

　　多人协做的工做模式一般是这样：

　　　　1. 首先，能够试图用git push origin <branch-name>推送本身的修改；

　　　　2. 若是推送失败，则由于远程分支比你的本地更新，须要先用git pull试图合并；

　　　　3. 若是合并有冲突，则解决冲突，并在本地提交；

　　　　4. 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功

　　若是git pull提示no tracking information，则说明本地分支和远程分支的连接关系没有建立，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

 Rebase

　　rebase操做能够把本地未push的分叉提交历史整理成直线；

git rebase

 

　　rebase的目的是使得咱们在查看历史提交的变化时更容易，由于分叉的提交须要三方对比。

 标签管理　　

 　　发布一个版本时，一般先在版本库中打一个标签（tag），这样，就惟一肯定了打标签时刻的版本。不管何时，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。因此，标签也是版本库的一个快照。

 　　Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针，因此，建立和删除标签都是瞬间完成的。

　　这个标签呢，相似于IP与域名之间的关系，给某个标签取个版本好，再次找的时候可使用版本号去找。

 建立标签

 　　切换到须要打标签的分支上：

git branch


git checkout master

　　我这个是切换到master分支上打标签。

　　输入命令 git tag <name>：

git tag v1.0

　　这样就建立了一个标签，而且标签的名字为v1.0。

　　默认标签是打在最新提交的commit上的。当咱们忘记了给以前的某一天的commit打标签是，可使用 git log --graph=oneline --abbrev-commit 命令找到历史提交的commit ID，而后再打上标签就好了。具体以下：

git tag v2.0 f52cc63  # 其中 v2.0是标签名，f52cc63是须要打标签的commit的commit ID

　　查看标签

git tag

 

 　　标签不是按时间顺序列出，而是按字母排序的。能够用git show <tagname>查看标签信息：

git show v2.0

　　还能够建立带说明的标签，用-a指定标签名，-m指定说明文字：

git tag -a v3.0 -m 'version update'

　　使用git show <tagname>能够看到说明文字。

 　　标签老是和某个commit挂钩。若是这个commit既出如今master分支，又出如今dev分支，那么在这两个分支上均可以看到这个标签。

 操做标签

 　　若是标签打错了，也能够删除标签：

git tad -d v1.0

 

　　建立的标签都只存储在本地，不会自动推送到远程。因此，打错的标签能够在本地安全删除。

　　若是要推送某个标签到远程，使用命令git push origin <tagname>：

git push origin v1.0

　　或者一次性推送所有未推送到远程的本地标签：

git push origin --tags

 

　　若是标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：

git tag -d v1.0

　　而后远程删除。删除命令也是push，可是格式以下：

git push origin :refs/tags/v2.0

 

 

参考文章

Git教程