zoukankan      html  css  js  c++  java
  • Git学习

    本文内容是对廖雪峰老师Git教程做的笔记,外加一些自己的学习心得,还抱着学以致用的心态来实践一番

    一.本地操作

    安装Git

    ** Linux:
    $ git
    The program 'git' is currently not installed. You can install it by typing:
    sudo apt-get install git
    $ sudo apt-get install git
    
    ** Mac OS X:
    一是安装homebrew,然后通过homebrew安装Git,具体方法请参考homebrew的文档:http://brew.sh/。
    第二种方法更简单,也是推荐的方法,就是直接从AppStore安装Xcode,Xcode集成了Git,不过默认没有安装,你需要运行Xcode,选择菜单“Xcode”->“Preferences”,在弹出窗口中找到“Downloads”,选择“Command Line Tools”,点“Install”就可以完成安装了。
    ** Windows:
    Git官网下载安装程序:https://git-scm.com/downloads
    安装成功之后点击右键菜单里面找到'Git Bash Here' 点击输入以下命令
    $ git config --global user.name "Your Name"
    $ git config --global user.email "email@example.com"
    

    创建版本库

    $ mkdir learngit
    $ cd learngit
    $ pwd
    初始化一个Git仓库,使用git init命令。
    $ git init
    添加文件到Git仓库,分两步:
    使用命令git add <file>,注意,可反复多次使用,添加多个文件;
    $ git add readme.txt
    使用命令git commit -m <message>,完成。
    $ git commit -m "wrote a readme file"
    --小结
    初始化一个Git仓库,使用git init命令。
    添加文件到Git仓库,分两步:
    使用命令git add <file>,注意,可反复多次使用,添加多个文件;
    使用命令git commit -m <message>,完成。
    

    状态查看

    修改readme.txt文件里面的内容
    $ vim readme.txt
    $ git status -- 查看当前仓库状态
    $ git diff readme.txt --根据状态显示的内容查看那个文本被修改了那些内容
    $ git add readme.txt 
    $ git status --在查看状态  将要被提交的修改包括readme.txt,下一步,就可以放心地提交了
    $ git commit -m 'add distributed' --提交
    $ git status --Git告诉我们当前没有需要提交的修改,而且,工作目录是干净(working tree clean)的
    --小结
    要随时掌握工作区的状态,使用git status命令。
    如果git status告诉你有文件被修改过,用git diff可以查看修改内容。
    

    版本回退

    查看历史提交的版本记录
    $ git log
    commit 34b1af5ec5f1e83543c09aec36d11933acfaaac7 (HEAD -> master)
    Author: iathanasy <14163548@qq.com>
    Date:   Fri Jan 4 10:23:33 2019 +0800
    
    	apped GPL
    
    commit 8d7414812ce5fa85a4ff4dbc1d8e906a246e52a4
    Author: iathanasy <14163548@qq.com>
    Date:   Fri Jan 4 10:11:11 2019 +0800
    
    	add distributed
    
    commit 1c4c57df847b94d2e549780a8cb6b1810cf66ff4
    Author: iathanasy <14163548@qq.com>
    Date:   Fri Jan 4 09:44:40 2019 +0800
    
    	wrote a readme file
    日志太多可使用简化版命令
    $ git log --pretty=oneline
    34b1af5ec5f1e83543c09aec36d11933acfaaac7 (HEAD -> master) apped GPL
    8d7414812ce5fa85a4ff4dbc1d8e906a246e52a4 add distributed
    1c4c57df847b94d2e549780a8cb6b1810cf66ff4 wrote a readme file
    -- 首先,Git必须知道当前版本是哪个版本,在Git中,用HEAD表示当前版本,也就是最新的提交34b1af...(注意我的提交ID和你的肯定不一样),上一个版本就是HEAD^,上上一个版本就是HEAD^^,当然往上100个版本写100个^比较容易数不过来,所以写成HEAD~100
    $ git reset --hard HEAD^ 
    HEAD is now at 8d74148 add distributed  --果然回退到上一个版本了。
    $ git log --可以看到第一个版本不见了
    $ git reset --hard 34b1af --指定回到未来版本 最开始的第一个版本 id号可以不用写全,Git会自动查找
    $ git reflog --在Git中,总是有后悔药可以吃的。当你用$ git reset --hard HEAD^回退到add distributed版本时,再想恢复到append GPL,就必须找到append GPL的commit id。Git提供了一个命令git reflog用来记录你的每一次命令
    34b1af5 (HEAD -> master) HEAD@{0}: reset: moving to 34b1af
    8d74148 HEAD@{1}: reset: moving to HEAD^
    34b1af5 (HEAD -> master) HEAD@{2}: commit: apped GPL
    8d74148 HEAD@{3}: commit: add distributed
    1c4c57d HEAD@{4}: commit (initial): wrote a readme file
    --小结
    HEAD指向的版本就是当前版本,因此,Git允许我们在版本的历史之间穿梭,使用命令git reset --hard commit_id。
    穿梭前,用git log可以查看提交历史,以便确定要回退到哪个版本。
    要重返未来,用git reflog查看命令历史,以便确定要回到未来的哪个版本。
    

    工作区和暂存区

    $ git diff    #是工作区(work dict)和暂存区(stage)的比较
    $ git diff --cached    #是暂存区(stage)和分支(master)的比较
    --小结
    git add命令实际上就是把要提交的所有修改放到暂存区(Stage),然后,执行git commit就可以一次性把暂存区的所有修改提交到分支
    

    管理修改

    $ vim readme.txt --添加一条
    $ git add readme.txt
    $ git status
    $ vim readme.txt --修改里面的内容
    $ git commit -m 'git tracks changes' --当你用git add命令后,在工作区的第一次修改被放入暂存区,准备提交,但是,在工作区的第二次修改并没有放入暂存区,所以,git commit只负责把暂存区的修改提交了,也就是第一次的修改被提交了,第二次的修改不会被提交。
    $ git status --咦,怎么第二次的修改没有被提交?
    $ git diff HEAD -- readme.txt  --可以查看工作区和版本库里面最新版本的区别
    那怎么提交第二次修改呢?你可以继续git add再git commit,也可以别着急提交第一次修改,先git add第二次修改,再git commit,就相当于把两次修改合并后一块提交了:
    第一次修改 -> git add -> 第二次修改 -> git add -> git commit
    --小结
    每次修改,如果不用git add到暂存区,那就不会加入到commit中。
    

    撤销修改

    $ vim readme.txt --添加一条
    $ git status --查看状态 发现不想提交添加了
    $ git checkout -- readme.txt --可以丢弃工作区的修改
    $ cat readme.txt --发现新添加的一条已经还原了
    
    命令git checkout -- readme.txt意思就是,把readme.txt文件在工作区的修改全部撤销,这里有两种情况:
    一种是readme.txt自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
    一种是readme.txt已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
    总之,就是让这个文件回到最近一次git commit或git add时的状态。
    git checkout -- file命令中的--很重要,没有--,就变成了“切换到另一个分支”的命令,我们在后面的分支管理中会再次遇到git checkout命令。
    
    $ vim readme.txt --添加一条
    $ git add readme.txt -- git add到暂存区
    $ git status --在commit之前,你发现了这个问题。用git status查看一下,修改只是添加到了暂存区,还没有提交
    $ git reset HEAD readme.txt  --用命令git reset HEAD <file>可以把暂存区的修改撤销掉(unstage),重新放回工作区
    
    $ git checkout -- readme.txt
    $ git status
    
    git reset命令既可以回退版本,也可以把暂存区的修改回退到工作区。当我们用HEAD时,表示最新的版本。
    再用git status查看一下,现在暂存区是干净的,工作区有修改
    
    --小结
    场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令git checkout -- file。
    场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git reset HEAD <file>,就回到了场景1,第二步按场景1操作。
    场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交,参考版本回退一节,不过前提是没有推送到远程库。
    

    删除文件

    $ git add test.txt
    $ git commit -m "add test.txt"
    $ rm test.txt --本地删除了
    $ git status
    $ git rm test.txt
    $ git commit -m "remove test.txt" --文件就从版本库中被删除了
    另一种情况是删错了本地文件,因为版本库里还有呢还没有提交commit,所以可以很轻松地把误删的文件恢复到最新版本
    $ git checkout -- test.txt
    git checkout其实是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”。
    如果已经commit了可以使用 git reset --HEAD 版本号 来回退 git checkout 到本地文件
    $ git checkout -- test.txt
    --小结
    命令git rm用于删除一个文件。如果一个文件已经被提交到版本库,那么你永远不用担心误删,但是要小心,你只能恢复文件到最新版本,你会丢失最近一次提交后你修改的内容。
    

    二.远程仓库

    添加远程仓库

    --创建SSH Key
    $ ssh-keygen -t rsa -C '14163548@qq.com'
    如果一切顺利的话,可以在用户主目录里找到.ssh目录,里面有id_rsa和id_rsa.pub两个文件,这两个就是SSH Key的秘钥对,id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可以放心地告诉任何人。
    第2步:登陆GitHub,打开“Account settings”,“SSH Keys”页面:
    然后,点“Add SSH Key”,填上任意Title,在Key文本框里粘贴id_rsa.pub文件的内容
    --添加远程仓库
    首先,登陆GitHub,然后,在右上角找到“Create a new repo”按钮,创建一个新的仓库
    在Repository name填入learngit,其他保持默认设置,点击“Create repository”按钮,就成功地创建了一个新的Git仓库
    目前,在GitHub上的这个learngit仓库还是空的,GitHub告诉我们,可以从这个仓库克隆出新的仓库,也可以把一个已有的本地仓库与之关联,然后,把本地仓库的内容推送到GitHub仓库。
    现在,我们根据GitHub的提示,在本地的learngit仓库下运行命令
    ·
    	…or create a new repository on the command line
    		echo "# learngit" >> README.md
    		git init
    		git add README.md
    		git commit -m "first commit"
    		git remote add origin git@github.com:iathanasy/learngit.git --添加后,远程库的名字就是origin,这是Git默认的叫法,也可以改成别的,但是origin这个名字一看就知道是远程库。
    		git push -u origin master --把本地库的内容推送到远程,用git push命令,实际上是把当前分支master推送到远程。
    	…or push an existing repository from the command line
    		git remote add origin git@github.com:iathanasy/learngit.git
    		git push -u origin master
    ·
    由于远程库是空的,我们第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来,在以后的推送或者拉取时就可以简化命令。
    推送成功后,可以立刻在GitHub页面中看到远程库的内容已经和本地一模一样
    从现在起,只要本地作了提交,就可以通过命令
    $ git push origin master
    --SSH警告
    当你第一次使用Git的clone或者push命令连接GitHub时,会得到一个警告:
    ·
    	$ git clone git@github.com:iathanasy/gitskills.git
    	Cloning into 'gitskills'...
    	The authenticity of host 'github.com (13.250.177.223)' can't be established.
    	RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
    	Are you sure you want to continue connecting (yes/no)? yes
    	Warning: Permanently added 'github.com,13.250.177.223' (RSA) to the list of known hosts.
    	remote: Enumerating objects: 3, done.
    	remote: Counting objects: 100% (3/3), done.
    	remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
    	Receiving objects: 100% (3/3), done.
    ·
    这是因为Git使用SSH连接,而SSH连接在第一次验证GitHub服务器的Key时,需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器,输入yes回车即可。
    Git会输出一个警告,告诉你已经把GitHub的Key添加到本机的一个信任列表里了:
    	Warning: Permanently added 'github.com,13.250.177.223' (RSA) to the list of known hosts.
    这个警告只会出现一次,后面的操作就不会有任何警告了。
    如果你实在担心有人冒充GitHub服务器,输入yes前可以对照GitHub的RSA Key(https://help.github.com/articles/github-s-ssh-key-fingerprints/)的指纹信息是否与SSH连接给出的一致。
    --小结
    要关联一个远程库,使用命令git remote add origin git@server-name:path/repo-name.git;
    关联后,使用命令git push -u origin master第一次推送master分支的所有内容;
    此后,每次本地提交后,只要有必要,就可以使用命令git push origin master推送最新修改;
    分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在,也就是有没有联网都可以正常工作,而SVN在没有联网的时候是拒绝干活的!当有网络的时候,再把本地提交推送一下就完成了同步,真是太方便了!
    

    从远程库克隆

    前面是先有本地库,后有远程库的时候,如何关联远程库。
    首先,登陆GitHub,创建一个新的仓库,名字叫gitskills
    我们勾选Initialize this repository with a README,这样GitHub会自动为我们创建一个README.md文件。创建完毕后,可以看到README.md文件
    现在,远程库已经准备好了,下一步是用命令git clone克隆一个本地库
    $ git clone git@github.com:iathanasy/gitskills.git
    $ cd gitskills/
    $ ls
    README.md
    如果有多个人协作开发,那么每个人各自从远程克隆一份就可以了。
    你也许还注意到,GitHub给出的地址不止一个,还可以用https://github.com/michaelliao/gitskills.git这样的地址。实际上,Git支持多种协议,默认的git://使用ssh,但也可以使用https等其他协议。
    使用https除了速度慢以外,还有个最大的麻烦是每次推送都必须输入口令,但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。
    -- 小结
    要克隆一个仓库,首先必须知道仓库的地址,然后使用git clone命令克隆。
    Git支持多种协议,包括https,但通过ssh支持的原生git协议速度最快。
        克隆远程分支
        $ git clone -b dev git@github.com:iathanasy/gitskills.git
    

    三.分支管理

    创建与合并分支

    首先,我们创建dev分支,然后切换到dev分支
    $ git checkout -b dev --git 
    	checkout命令加上-b参数表示创建并切换,相当于以下两条命令:
    	$ git branch dev
    	$ git checkout dev
    然后,用git branch命令查看当前分支:
    $ git branch
    	* dev
    	master
    git branch命令会列出所有分支,当前分支前面会标一个*号。
    然后,我们就可以在dev分支上正常提交,比如对readme.txt做个修改,加上一行数据
    $ git add README.md
    $ git commit -m 'brabch test'
    现在,dev分支的工作完成,我们就可以切换回master分支
    $ git checkout master
    $ cat README.md
    切换回master分支后,再查看一个readme.txt文件,刚才添加的内容不见了!因为那个提交是在dev分支上,而master分支此刻的提交点并没有变
    现在,我们把dev分支的工作成果合并到master分支上
    $ git merge dev
    $ cat README.md --dev分支上面的数据已经到master上了
    	# gitskills
    	branch dev
    git merge命令用于合并指定分支到当前分支。合并后,再查看readme.txt的内容,就可以看到,和dev分支的最新提交是完全一样的。
    注意到上面的Fast-forward信息,Git告诉我们,这次合并是“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度非常快。
    当然,也不是每次合并都能Fast-forward,我们后面会讲其他方式的合并。
    合并完成后,就可以放心地删除dev分支了:
    $ git branch -d dev
    $ git branch
    删除后,查看branch,就只剩下master分支了
    因为创建、合并和删除分支非常快,所以Git鼓励你使用分支完成某个任务,合并后再删掉分支,这和直接在master分支上工作效果是一样的,但过程更安全。
    --小结
    Git鼓励大量使用分支:
    查看分支:git branch
    创建分支:git branch <name>
    切换分支:git checkout <name>
    创建+切换分支:git checkout -b <name>
    合并某分支到当前分支:git merge <name>
    删除分支:git branch -d <name>
    

    解决冲突

    人生不如意之事十之八九,合并分支往往也不是一帆风顺的。
    准备新的feature1分支,继续我们的新分支开发:
    $ git checkout  -b featurel
    $ vim README.md	--修改 Creating a new branch is quick AND simple.
    $ git add README.md	--在featurel 分支上提交
    切换到master分支
    $ git checkout master
    	Your branch is ahead of 'origin/master' by 1 commit.
    	(use "git push" to publish your local commits)
    Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。
    在master分支上把readme.txt文件的最后一行改为: 
    $ vim README.md -- Creating a new branch is quick & simple.
    $ git add README.md
    $ git commit -m '& simple'
    现在,master分支和feature1分支各自都分别有新的提交。
    这种情况下,Git无法执行“快速合并”,只能试图把各自的修改合并起来,但这种合并就可能会有冲突,我们试试看
    $ git merge featurel
    	Auto-merging README.md
    	CONFLICT (content): Merge conflict in README.md
    	Automatic merge failed; fix conflicts and then commit the result.
    果然冲突了!Git告诉我们,readme.txt文件存在冲突,必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件
    $ git status
    	On branch master
    	Your branch is ahead of 'origin/master' by 2 commits.
    	  (use "git push" to publish your local commits)
    
    	You have unmerged paths.
    	  (fix conflicts and run "git commit")
    	  (use "git merge --abort" to abort the merge)
    
    	Unmerged paths:
    	  (use "git add <file>..." to mark resolution)
    
    			both modified:   README.md
    
    	no changes added to commit (use "git add" and/or "git commit -a")
    我们可以直接查看readme.txt的内容
    $ cat README.md
    	# gitskills
    	branch dev
    	<<<<<<< HEAD
    	Creating a new branch is quick & simple.
    	=======
    	Creating a new branch is quick AND simple.
    	>>>>>>> featurel
    Git用<<<<<<<,=======,>>>>>>>标记出不同分支的内容,我们修改如下后保存:
    $ vim README.md --	Creating a new branch is quick and simple.
    $ git add README.md
    $ git commit -m 'conflict fixed'
    用带参数的git log也可以看到分支的合并情况
    $ git log --graph --pretty=oneline --abbrev-commit
    $ git branch -d featurel --删除分支
    --小结
    当Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。
    解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容,再提交。
    用git log --graph命令可以看到分支合并图。
    

    分支管理策略

    通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息
    如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息
    下面我们实战一下--no-ff方式的git merge
    首先,仍然创建并切换dev分支
    $ git checkout -b dev
    $ vim README.md
    $ git add README.md
    $ git commit -m 'add merge'
    $ git checkout master
    准备合并dev分支,请注意--no-ff参数,表示禁用Fast forward
    $ git merge --no-ff -m "merge with no-ff" dev
    	Merge made by the 'recursive' strategy.
    	 README.md | 1 +
    	 1 file changed, 1 insertion(+)
    因为本次合并要创建一个新的commit,所以加上-m参数,把commit描述写进去
    合并后,我们用git log看看分支历史
    $ git log --graph --pretty=oneline --abbrev-commit
    --分支策略
    在实际开发中,我们应该按照几个基本原则进行分支管理:
    首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
    那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;
    你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。
    --小结
    Git分支十分强大,在团队开发中应该充分应用。
    合并分支时,加上--no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward合并就看不出来曾经做过合并。
    

    Bug分支

    Feature分支

    添加一个新功能时,你肯定不希望因为一些实验性质的代码,把主分支搞乱了,所以,每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后,删除该feature分支
    $ git checkout -b feature-vulcan
    $ git add vulcan.py
    $ git status
    $ git commit -m "add feature vulcan"
    切回dev,准备合并
    $ git checkout dev
    $ git branch -d feature-vulcan --新功能取消 删除分支 销毁失败。Git友情提醒,feature-vulcan分支还没有被合并,如果删除,将丢失掉修改,如果要强行删除,需要使用大写的-D参数。。
    	error: The branch 'feature-vulcan' is not fully merged.
    	If you are sure you want to delete it, run 'git branch -D feature-vulcan'.
    $ git branch -D feature-vulcan --强行删除
    --小结
    开发一个新feature,最好新建一个分支;
    如果要丢弃一个没有被合并过的分支,可以通过git branch -D <name>强行删除。
    

    多人协作

    当你从远程仓库克隆时,实际上Git自动把本地的master分支和远程的master分支对应起来了,并且,远程仓库的默认名称是origin。
    $ git remote --要查看远程库的信息,用git remote
    $ git remote -v --用git remote -v显示更详细的信息
    上面显示了可以抓取和推送的origin的地址。如果没有推送权限,就看不到push的地址。
    --推送分支
    推送分支,就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上
    $ git push origin master
    $ git push origin dev --如果要推送其他分支,比如dev
    但是,并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?
    	master分支是主分支,因此要时刻与远程同步;
    	dev分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;
    	bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
    	feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
    --抓取分支
    多人协作时,大家都会往master和dev分支上推送各自的修改.
    现在,模拟一个你的小伙伴,可以在另一台电脑(注意要把SSH Key添加到GitHub)或者同一台电脑的另一个目录下克隆:
    $ git clone git@github.com:iathanasy/gitskills.git
    $ git branch --默认只能看到master
    要在dev分支上开发,就必须创建远程origin的dev分支到本地,于是他用这个命令创建本地dev分支
    $ git checkout -b dev origin/dev
    现在,他就可以在dev上继续修改,然后,时不时地把dev分支push到远程
    $ vim env.txt
    $ git add env.txt
    $ git commit -m 'add env'
    $ git push origin dev
    你的小伙伴已经向origin/dev分支推送了他的提交,而碰巧你也对同样的文件作了修改,并试图推送
    $ vim env.txt
    $ git add env.txt
    $ git commit -m 'add new env'
    $ git push origin dev
    	`
    	Warning: Permanently added the RSA host key for IP address '13.229.188.59' to the list of known hosts.
    	To github.com:iathanasy/gitskills.git
    	 ! [rejected]        dev -> dev (fetch first)
    	error: failed to push some refs to 'git@github.com:iathanasy/gitskills.git'
    	hint: Updates were rejected because the remote contains work that you do
    	hint: not have locally. This is usually caused by another repository pushing
    	hint: to the same ref. You may want to first integrate the remote changes
    	hint: (e.g., 'git pull ...') before pushing again.
    	hint: See the 'Note about fast-forwards' in 'git push --help' for details.
    	`
    推送失败,因为你的小伙伴的最新提交和你试图推送的提交有冲突,解决办法也很简单,Git已经提示我们,先用git pull把最新的提交从origin/dev抓下来,然后,在本地合并,解决冲突,再推送
    $ git pull
    	`
    	There is no tracking information for the current branch.
    	Please specify which branch you want to merge with.
    	See git-pull(1) for details.
    
    		git pull <remote> <branch>
    
    	If you wish to set tracking information for this branch you can do so with:
    
    	git branch --set-upstream-to=origin/<branch> dev
    	`
    git pull也失败了,原因是没有指定本地dev分支与远程origin/dev分支的链接,根据提示,设置dev和origin/dev的链接:
    $ git branch --set-upstream-to=origin/dev dev
    再pull:
    $ git pull
    	Auto-merging env.txt
    	CONFLICT (add/add): Merge conflict in env.txt
    	Automatic merge failed; fix conflicts and then commit the result.
    这回git pull成功,但是合并有冲突,需要手动解决,解决的方法和分支管理中的解决冲突完全一样。解决后,提交,再push
    $ vim env.txt	--解决冲突
    $ git add env.txt
    $ git commit -m 'fix env confliot'
    $ git push origin dev
    因此,多人协作的工作模式通常是这样:
    	首先,可以试图用git push origin <branch-name>推送自己的修改;
    	如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;
    	如果合并有冲突,则解决冲突,并在本地提交;
    	没有冲突或者解决掉冲突后,再用git push origin <branch-name>推送就能成功!
    如果git pull提示no tracking information,则说明本地分支和远程分支的链接关系没有创建,用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。
    这就是多人协作的工作模式,一旦熟悉了,就非常简单。
    --小结
    查看远程库信息,使用git remote -v;
    本地新建的分支如果不推送到远程,对其他人就是不可见的;
    从本地推送分支,使用git push origin branch-name,如果推送失败,先用git pull抓取远程的新提交;
    在本地创建和远程分支对应的分支,使用git checkout -b branch-name origin/branch-name,本地和远程分支的名称最好一致;
    建立本地分支和远程分支的关联,使用git branch --set-upstream branch-name origin/branch-name;
    从远程抓取分支,使用git pull,如果有冲突,要先处理冲突。
    

    Rebase

    $ git log --graph --pretty=oneline --abbrev-commit --日志
    $ git rebase
    --小结
    rebase操作可以把本地未push的分叉提交历史整理成直线;
    rebase的目的是使得我们在查看历史提交的变化时更容易,因为分叉的提交需要三方对比。
    

    标签管理

    创建标签

    --标签的场景
    请把上周一的那个版本打包发布,版本号是v1.2”
    好的,按照tag v1.2查找commit就行!”
    在Git中打标签非常简单,首先,切换到需要打标签的分支上
    $ git branch
    $ git checkout master
    $ git tag v1.0 --打标签
    $ git tag	--查看标签
    默认标签是打在最新提交的commit上的。有时候,如果忘了打标签,比如,现在已经是周五了,但应该在周一打的标签没有打,怎么办?
    方法是找到历史提交的commit id,然后打上就可以了:
    $ git log --pretty=oneline --abbrev-commit
    	·
    	2f45328 (HEAD -> master, tag: v1.0, origin/master, origin/HEAD) merge with no-ff
    	f5e28c0 add merge
    	afcbba0 conflict fixed
    	494c104 & simple
    	96334f7 AND simple
    	3238ee9 brabch test
    	550f64a Initial commit
    	·
    比如说要对add merge 打标签,它的对应commit id是f5e28c0
    $ git tag v0.9 f5e28c0
    $ git tag
    注意,标签不是按时间顺序列出,而是按字母排序的。可以用git show <tagname>查看标签信息
    $ git show v0.9
    还可以创建带有说明的标签,用-a指定标签名,-m指定说明文字
    $ git tag v0.1 -m 'version 0.1 released' afcbba0
    $ git show v0.1
    --小结
    命令git tag <tagname>用于新建一个标签,默认为HEAD,也可以指定一个commit id;
    命令git tag -a <tagname> -m "blablabla..."可以指定标签信息;
    命令git tag可以查看所有标签。
    

    操作标签

    如果标签打错了,也可以删除:
    $ git tag -d v0.1
    因为创建的标签都只存储在本地,不会自动推送到远程。所以,打错的标签可以在本地安全删除
    如果要推送某个标签到远程,使用命令git push origin <tagname>
    $ git push origin v1.0
    或者,一次性推送全部尚未推送到远程的本地标签
    $ git push origin --tags
    如果标签已经推送到远程,要删除远程标签就麻烦一点,先从本地删除
    $ git tag -d v0.9
    然后,从远程删除。删除命令也是push,但是格式如下
    $ git push origin :refs/tags/v0.9
    要看看是否真的从远程库删除了标签,可以登陆GitHub查看
    --小结
    命令git push origin <tagname>可以推送一个本地标签;
    命令git push origin --tags可以推送全部未推送过的本地标签;
    命令git tag -d <tagname>可以删除一个本地标签;
    命令git push origin :refs/tags/<tagname>可以删除一个远程标签。
  • 相关阅读:
    第 9 章 用户自己建立数据类型
    第 10 章 对文件的输入输出
    第 7 章 用函数实现模块化程序设计
    第 4 章 选择结构程序设计
    第 5 章 循环结构程序设计
    第 6 章 利用数组处理批量数据
    第 3 章 最简单的 C 程序设计——顺序程序设计
    第 1 章 程序设计和 C 语言
    第 2 章 算法——程序的灵魂
    SQL(SQL Server) 批量替换两列的数据
  • 原文地址:https://www.cnblogs.com/iathanasy/p/10220451.html
Copyright © 2011-2022 走看看