git常用操作

参考：Pro Git

分支主要操作

git branch -a  #看本地和远程全部分支

git checkout -b feature/my-feature  #创建或切换到这个分支上，不加-b直接切换

修改后，对内容进行add暂存，或者commit提交。

git checkout main #切换到主分支
git merge feature/my-feature #将feature/my-feature分支，注意合并时暂存的也会合并，合并到main分支上。
git push #将主分支推送。

git checkout remotes/origin/master-test #直接切换远程分支，不会在本地创建分支。此时不可git pull,一定要在本地分支上才能对应的拉取远程分支，比如git checkout master
git checkout -b master-test remotes/origin/master-test 可以在本地创建分支并将远程分支下来。相当于
git branch master-test remotes/origin/master-test  
git checkout master-test  

1.初始化文件夹，以下两种方法

文件夹内.git文件为代码库

git init

文件本身就是代码库

git init --bare

2.获取代码库

生成代码文件，且其内部.git文件为代码库

git clone

不获取代码文件，仅获取代码库，文件夹本身就是代码库

git clone --bare

3.暂存区

git add 1.txt #加入暂存
git reset #取消所有暂存
git reset 1.txt #将1.txt取消暂存
git reset HEAD 1.txt  #将1.txt取消暂存

4.提交版本

全部变化提交，包含删除。如果不全部提交需要把-a参数去掉

git commit -a -m '' # 全部提交
git commit --amend # 首先，将暂存区文件再次提交。然后，可以修改版本注释。注意没有add进入暂存区的修改不会提交

5.查看提交的版本

git log #查看索引
git log -p -2  #其中-2是仅现实最近的两次更新细节。
git log -p 3b7d1e #查看某次提前交的更新细节，最后参数为版本索引。
git log -p -1 --word-diff #以单行的形式展示对比，新增单词{+ +}，删除单词[--]

6.取消文件的修改

取消修改的内容，注意是没有加入暂存区的

git checkout  #全部修改取消，此命令非常危险，谨慎使用
git checkout 1.txt #将1.txt的内容置为上次提交的内容，如果暂存区有此文件则恢复到暂存区的状态。
git restore 1.txt  #取消对文件的修改，恢复到上次提交的状态，如果暂存区有此文件则恢复到暂存区的状态。
如果文件被删除，也可使用git restore 1.txt恢复回来。当然checkout也行

7.远程仓库

添加远程仓库

git remote add origin https://github.com/test.git
git remote  add  [remote-name] [url/本地路径/ssh]

查看当前仓库的远程仓库 

git remote
git remote -v #显示远程库地址

fetch从远程仓库抓取数据，此命令会自动将远程仓库归于origin名下，会把origin/master指针移动到它最新的位置上。此命令会抓取别人上传到此仓库中的所有更新。

注意，fetch命令只是将远端的数据拉倒本地仓库。生成“隐藏分支”（其实是一个无法移动的origin/master 指针）名称为  [remote-name]/[server-branch-name]  ，并不自动合并到当前工作分支，只有你确实准备好了，才能手动合并。

如果想要在这这个“隐藏分支”上进行开发，将其分化为本的一个新分支如下

git checkout -b [new-local-branch-name] origin/master

虽然拉取了，但是没有出现在当前工作目录。需要git checkout origin/master才能看到，注意分支名称前有远程库简称，如果不加远程库代表的是本地原有的master分支。

需要切换或合并分支后，才能看到。git pull = git fetch + git merge

git fetch [remote-name] #注意此时master分支并没有变化，HEAD并没有移位,下载的分支为[remote-name]/[server-branch-name] 例如origin/master
git checkout origin/master #这样可以直接先切换到本地刚下载的远程分支。
#注意本地分支master没有变化，这里分支有前缀origin/代表着是刚下载的远程分支
#注意此分支虽然可以提交，但不会保存，离开分之后变化会被丢弃，如果要编辑内容最好是将其生成本地的分支，见上面的代码
git merge origin/master #此时才能看到master分支更新的内容

如果设置了某个分支用于跟踪某个远端仓库的分支，可以使用git pull命令自动抓取数据下来。然后将远端分支自动合并到本地仓库中当前分支。在日常工作中经常这么用，既快且好。

实际上，默认情况下git clone命令本质上就是自动创建本地的master分支用于跟踪仓库中的master分支。所以一般我们运行git pull，目的都是从远端仓库中获取数据后，合并到工作目录的当前分支。

8.推送数据到远程仓库

git push [remote-name] [branch-name]
#例如把本地的master分支推送到origin服务器上
git push origin master

只有在服务器上有写权限，或者同一时刻没有其他人在推送数据，这条命令才会如期完成。

如果你在推送前，已有人推送了若干更新，那你的推送会被驳回。你必须先把他们的更新抓到本地，合并到自己的项目中，然后才可以再次推送。

9.远端仓库操作

查看远端仓库信息

git remote show origin

修改某个远端仓库在本地的简称

git remote rename [oldremote-name] [newremote-name]
#例如
git remote rename pb paul

删除远端仓库 

git remote rm paul

10.标签

git可对某一时间点的版本打上标签。人们在发布某个软件版本（如v1.0等等）的时候，经常这么做。

git tag #显示已有标签
git tag -l 'v1.4.*' #模糊查看
git show v1.4 #查看标签的版本信息， 与git show 04abd1 查看版本信息一模一样

标签有两种，轻量级的和含附注的。轻量级标签就像个不会变化的分支，实际上它就是指向特定提交对象的引用。

含附注标签，实际上是存储在仓库中的一个独立对象，它有自身的校验和信息，包含标签的名字，电子邮件地址和日期，以及标签说明。

一般都建议使用含附注类型的标签，以便保留相关信息，当然如果只是临时加注标签，或者不需要注释，用轻量级也没有问题。

git tag v1.5 #对当前提交的版本加轻量级标签
git tag -a v1.4 -m 'my version 1.4' #对当前提交的版本加 含附注的标签
#对历史版本追加标签，一个版本可以打多个标签
git log --pretty=oneline #先查看各版本信息，数字签名，标签等
git tag -a v1.2 9fceb02 后面是版本的数字签名

默认情况下，git push不会把标签传到远端服务器上，只有通过显示命令才能分享标签到远端仓库，命令如同推送分支。

git push origin [tagname]
#如果一次推送所有标签上去，可以使用 --tags选项
git push origin --tags

11.分支

gti鼓励在工作流程中频繁使用分支与合并，哪怕一天内多次进行多次都没有关系。

git branch #查看当前有哪些分支，且工作在哪个分支上
git branch testing #创建分支，仅是新建分支，当前分支并没有切换到新的分支上
git checkout testing #切换的testing分支上
git checkout -b iss53 #新建并切换到新分支，相当于执行上两个命令

git如何知道当前在哪个分支工作呢？答案很简单，它保存着一个名为HEAD的特别指针，它是一个指向你正在工作中的本地分支的指针。

git的分支仅是一个包含所指对象校验的文件，所以创建和销毁一个分支很廉价。新建一个分支就是向一个文件写入41个字节那么简单。

注意：必须commit后才能产生分支内容的不同，如果要切换分支，必须先commit当前的变化。既刚新建了分支，此时对文件修改。必须在某一分支提交修改后，其它分支才能看到修改前的变化。否则所有分支均可看到修改的文件，并可选其中一个提交修改。

git merge [branch-name] #合并分支，当前在哪个分支，就是主分支，merge后面是要并入的分支。
git branch -d [branch-name] #合并完成就要顺手删除分支
git branch -D [branch-name] #强制删除分支
git branch --merged #查看哪些分支已经并入当前分支
git branch --no-merged #查看哪些分支没有并入当前分支
git branch -v #查看当前分支情况，注意如果新分支是fetch而来，才是查看不到新分支，只有主动切换到远程来的新分支后，此命令才可见新分支

合并分支时，如果有冲突。默认是不会将合并提交到当前分支的。而是会提示冲突，用status查看会有Unmerged paths指示了哪些文件有了冲突。

冲突文件中<<<<<<<，======= 和 >>>>>>> 来隔开，需要手动修改文件，删除这些内容。再使用add暂存，一旦暂存，就代表着冲突已经解决了。

git mergetool #调用一个可视化工具，来查看冲突

合并有两种情况，一个是“Fast forward”既新commit和旧分支在一条线上，这种合并称为“快进”。还有一种情况，新的commit和旧的分支不在一条线上，会产生一个新的commit，这个新commit会以原有的两条线上的commit为父节点。

注意：合并的时候，当前一定要处于落后的分支上，不然新分支不会有任何变化，例如每次合并前，都是在master这个分支上。

分支规范流程

分支名称	解释
master	稳定版
develop	开发版
iss53	修复bug版
topic	特性版
proposed或pu	建议更新分支。某些大项目可能用到

推送分支

git push [remote-name] [branch-name] #推送分支到远程库
#推送时在远程库改分支名
git push origin [local-branch-name]:[server-branch-name]

跟踪分支

从远程分支checkout出来的本地分支，称为跟踪分支。是一种和某个远程分支直接联系的本地分支。在跟踪分支里输入git push，git会自动推断应该向哪个服务器的哪个分支推送数据。同理git pull会索取所有的远程索引。

克隆仓库时，git通常会创建一个名为master的分支来跟踪origin/master，这正是git push和git pull一开始能正常工作的原因。当然，你可以随心所欲的设定为其它跟踪分支。

git checkout -b [分支名] [远程名]/[分支名]
#也可以使用--track简化
git checkout --track origin/serverfix

删除远程分支

git push [远程名] :[分支名]
#例如删除远程库中的serverfix分支
git push origin :serverfix #很像在推送本地分支到服务器端时，给远程分支改名。可以理解为推送空到远程库的serverfix分支中，相当于删除它

12.衍合（rebase）

把一个分支的修改整合到另一个分支的办法有两种：merge和rebase。

把一个分支里提交的改变移动到另一个分支里重放一遍。

git checkout experiment
git rebase master
#下面解释
#git rebase <upstream-branch-name> <to-branch-name>
#此命令的执行内容如下
#1.切换到to-branch分支；
#2.将to-branch中比upstream-branch多的commit先撤销掉，并将这些commit放在一块临时存储区（.git/rebase）；
#3.将upstream-branch中比to-branch多的commit应用到to-branch上，此刻to-branch和upstream-branch的代码状态一致；
#4.将存放的临时存储区的commit重新应用到to-branch上；结束。
#注意： 执行完上述第3步后，to-branch的代码状态已经改变，接着执行第4步时则可能会产生合并冲突。

原理是回到两个分支最近的共同祖先，根据当前分支（experiment）后续的历次提交对象，生成一系列文件补丁，然后以基底分支最后一个提交对象为新的出发点，逐个应用之前准备好的补丁文件，最后会生成一个新的合并提交对象，从而改写experiment。现在回到master分支，进行一次快进合并。

虽然最后整合的结果和merge没有任何区别，但衍合能产生一个更为整洁的提交历史。如果视察一个衍合过的分支的历史记录，看起来更清楚：仿佛所有修改都是在一根线上先后进行的，尽管实际上它们原本是同时并行发生的。

一般我们使用衍合的目的，是想要得到一个能在远程分支上干净应用的补丁。比如某些项目你不是维护者，但想帮点忙的话，最好用衍合：先在自己的一个分支里进行开发，当准备向主项目提交补丁的时候，根据最新的origin/master进行一次衍合操作然后再提交，这样维护者就不需要做任何整合工作（实际上是把解决分支补丁同最新主干代码之间冲突的责任，转化为由提交补丁的人来解决），只需要根据你提供的仓库地址作一次快进合并，或者直接采纳你提交的补丁。

请注意，合并结果中最后一次提交所指向的快照，无论是通过衍合还是三方合并，都会得到相同的快照内容，只不过提交历史不同罢了。

衍合适按照每行的修改次序重演一遍修改，而合并是把最终结果合在一起。

衍合时冲突

如果有冲突，此时分支会切换到一个临时分支上，不在当前任何一个分支上，按下面三步解决完后，会自动再切换为之前的分支

#1.首先手动解决冲突
git add . #2.标记冲突的文件已解决
git rebase --continue #3.继续提交