git 学习记录
2017-08-30 17:08
411 查看
（一）多人协作模式
https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013760174128707b935b0be6fc4fc6ace66c4f15618f8d000 多人协作
“
但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
”
我：目前master与dev共存，且同时保持远程同步，前者生产作业，后者开发作业，不使用bug与feature分支
多人协作时，大家都会往
接下去是一个日常团队协作场景：
你的小伙伴已经向
推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用
再pull：
这回
因此，多人协作的工作模式通常是这样：
首先，可以试图用
如果推送失败，则因为远程分支比你的本地更新，需要先用
如果合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用
如果
这就是多人协作的工作模式，一旦熟悉了，就非常简单。
查看远程库信息，使用
本地新建的分支如果不推送到远程，对其他人就是不可见的；
从本地推送分支，使用
在本地创建和远程分支对应的分支，使用
建立本地分支和远程分支的关联，使用
从远程抓取分支，使用
（二）分支定义、提炼逻辑过程 http://www.cnblogs.com/JoannaQ/p/3978252.html
每天工程师都需要git pull origin develop来更新develop分支，然后将develop分支合并到你正在开发得feature/xxxxx分支上来保持代码最新
切记不能直接在develop上进行开发
不知道什么意思
10.30知道了，就是保持develop分支的纯净
我：项目组较小，实施改为
每天工程师都需要git pull origin develop来更新develop分支，保持代码最新
分支定义：
master分支对应线上版本，上线都使用master； （ok）
develop是开发分支，用于生成提测分支release，始终保持最新； （ok）
hotfix是紧急分支，从master生成，bug修正后自动合并到master和develop并且生成tag； （这里直接操作master分支）
feature是私有分支，用于开发新需求和需要较长时间的BUG修改
（不使用，直接在dev分支上日常开发）
release是提测分支也即常规分支，测试并且bug修改结束后生成该版本tag，后续可以使用git show tagname来查看版本信息或者回滚（不使用，直接在dev上生成release）
5个分支简化为2个，
master＋hotfix－》master 生产，生产修复，紧急需求
feature＋dev＋release－》dev 日常开发，提炼release
（三）另一个更具体的多人协作生动场景
基本遵循程序：git push , git pull , 处理冲突 , git add . , git commit/push http://www.cnblogs.com/onelikeone/p/6857910.html
甲收工，准备下班了。在下班之前，需要将最新版本推送到git服务器。
开始使用命令，执行如下：
结果出错了，why？
之所以会出错，原因在于：其他程序员已经将最新的一个版本提交到git服务器上，但是你在提交之前，已经不是最新的。
在这种情况下，甲，需要先从服务器拉取最新的版本。
在多人协助开发时，每个开发人员在推送自己的最新版本时，都需要确保当前版本是最新的，所以就需要先获取最新版本，也就是说需要从服务器拉取最新版本到本地。
需要使用 git pull命令
如此一来，甲当前就是最新的版本。
然后再次使用 git push 命令推送至服务器。
接下来需要分两种情况：
如果有新的开发人员加入进来，重复2~5过程。
如果不是新的开发人员，重复3~5过程。
比如，对于乙而言，其实它现在已经不是最新的版本了，所以需要使用 git pull 拉取最新版本。
所以，对很多开发人员而言，一打开电脑，马上先git pull，拉取最新的。然后进行常规开发，
开发完毕之后，在git push之前，还需要使用git pull再拉取一遍。
没有提到冲突
（四）冲突
https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/001375840202368c74be33fbd884e71b570f2cc3c0d1dcf000 解决冲突
下面是解决冲突：
merge 非快速时的冲突（与pull origin 冲突一样，
self merge other
self pull origin self ( equel other )
）前提 ：a的改动和b或origin的改动在同一个地方
人生不如意之事十之八九，合并分支往往也不是一帆风顺的。
准备新的
修改readme.txt最后一行，改为：
在
切换到
，本分支必须提前commit 或 stash）
Git还会自动提示我们当前
的 commit 不会自动合并到master）
在
提交：
现在，
这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：
果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。
我们可以直接查看readme.txt的内容：
Git用
再提交：
现在，
用带参数的
最后，删除
工作完成。
注：
远程的master和dev分支合并时一般不会冲突
dev 日常开发 —— dev test release ——测试—— checkout master —— merge dev
master分支不提交，只等到test release测试完毕后merge dev分支
一般情况下是快速合并，也可用--no--ff 加强commit 的显式
“
git branch
*dev
git commit -am "release"
git push origin dev
git checkout master
git merge --no-ff -m "merge with no-ff" dev
git push origin master
”
（除了直接在master上修复bug或紧急需求后，合并到dev使其最新的过程中，两个分支修改了同一处）
完。2017.12.13 最后批注
https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013760174128707b935b0be6fc4fc6ace66c4f15618f8d000 多人协作
“
但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
master分支是主分支，因此要时刻与远程同步；
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
”
我：目前master与dev共存，且同时保持远程同步，前者生产作业，后者开发作业，不使用bug与feature分支
多人协作时，大家都会往
master和
dev分支上推送各自的修改。（我：前者共同修复bug或紧急需求，后者共同日常开发）
接下去是一个日常团队协作场景：
你的小伙伴已经向
origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送：
$ git add hello.py $ git commit -m "add coding: utf-8" [dev bd6ae48] add coding: utf-8 1 file changed, 1 insertion(+) $ git push origin dev To git@github.com:michaelliao/learngit.git ! [rejected] dev -> dev (non-fast-forward) error: failed to push some refs to 'git@github.com:michaelliao/learngit.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Merge the remote changes (e.g. 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.
推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用
git pull把最新的提交从
origin/dev抓下来，然后，在本地合并，解决冲突，再推送：
$ git pull remote: Counting objects: 5, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. From github.com:michaelliao/learngit fc38031..291bea8 dev -> origin/dev 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 dev origin/<branch>
git pull也失败了，原因是没有指定本地
dev分支与远程
origin/dev分支的链接，根据提示，设置
dev和
origin/dev的链接：
$ git branch --set-upstream dev origin/dev Branch dev set up to track remote branch dev from origin.
再pull：
$ git pull Auto-merging hello.py CONFLICT (content): Merge conflict in hello.py Automatic merge failed; fix conflicts and then commit the result.
这回
git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样（第四条）。解决后，提交，再push：
$ git commit -m "merge & fix hello.py" [dev adca45d] merge & fix hello.py $ git push origin dev Counting objects: 10, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (6/6), 747 bytes, done. Total 6 (delta 0), reused 0 (delta 0) To git@github.com:michaelliao/learngit.git 291bea8..adca45d dev -> dev
因此，多人协作的工作模式通常是这样：
首先，可以试图用
git push origin branch-name推送自己的修改；
如果推送失败，则因为远程分支比你的本地更新，需要先用
git pull试图合并；
如果合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用
git push origin branch-name推送就能成功！
如果
git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令
git branch --set-upstream 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，如果有冲突，要先处理冲突。
（二）分支定义、提炼逻辑过程 http://www.cnblogs.com/JoannaQ/p/3978252.html
每天工程师都需要git pull origin develop来更新develop分支，然后将develop分支合并到你正在开发得feature/xxxxx分支上来保持代码最新
切记不能直接在develop上进行开发
不知道什么意思
10.30知道了，就是保持develop分支的纯净
我：项目组较小，实施改为
每天工程师都需要git pull origin develop来更新develop分支，保持代码最新
分支定义：
master分支对应线上版本，上线都使用master； （ok）
develop是开发分支，用于生成提测分支release，始终保持最新； （ok）
hotfix是紧急分支，从master生成，bug修正后自动合并到master和develop并且生成tag； （这里直接操作master分支）
feature是私有分支，用于开发新需求和需要较长时间的BUG修改
（不使用，直接在dev分支上日常开发）
release是提测分支也即常规分支，测试并且bug修改结束后生成该版本tag，后续可以使用git show tagname来查看版本信息或者回滚（不使用，直接在dev上生成release）
5个分支简化为2个，
master＋hotfix－》master 生产，生产修复，紧急需求
feature＋dev＋release－》dev 日常开发，提炼release
（三）另一个更具体的多人协作生动场景
基本遵循程序：git push , git pull , 处理冲突 , git add . , git commit/push http://www.cnblogs.com/onelikeone/p/6857910.html
甲收工，准备下班了。在下班之前，需要将最新版本推送到git服务器。
开始使用命令，执行如下：
结果出错了，why？
之所以会出错，原因在于：其他程序员已经将最新的一个版本提交到git服务器上，但是你在提交之前，已经不是最新的。
在这种情况下，甲，需要先从服务器拉取最新的版本。
(5).从远程服务器拉取版本（git pull）
在多人协助开发时，每个开发人员在推送自己的最新版本时，都需要确保当前版本是最新的，所以就需要先获取最新版本，也就是说需要从服务器拉取最新版本到本地。需要使用 git pull命令
如此一来，甲当前就是最新的版本。
然后再次使用 git push 命令推送至服务器。
接下来需要分两种情况：
如果有新的开发人员加入进来，重复2~5过程。
如果不是新的开发人员，重复3~5过程。
比如，对于乙而言，其实它现在已经不是最新的版本了，所以需要使用 git pull 拉取最新版本。
所以，对很多开发人员而言，一打开电脑，马上先git pull，拉取最新的。然后进行常规开发，
开发完毕之后，在git push之前，还需要使用git pull再拉取一遍。
没有提到冲突
（四）冲突
https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/001375840202368c74be33fbd884e71b570f2cc3c0d1dcf000 解决冲突
下面是解决冲突：
merge 非快速时的冲突（与pull origin 冲突一样，
self merge other
self pull origin self ( equel other )
）前提 ：a的改动和b或origin的改动在同一个地方
人生不如意之事十之八九，合并分支往往也不是一帆风顺的。
准备新的
feature1分支，继续我们的新分支开发：
$ git checkout -b feature1 Switched to a new branch 'feature1'
修改readme.txt最后一行，改为：
Creating a new branch is quick AND simple.
在
feature1分支上提交：
$ git add readme.txt $ git commit -m "AND simple" [feature1 75a857c] AND simple 1 file changed, 1 insertion(+), 1 deletion(-)
切换到
master分支：（注：checkout时
，本分支必须提前commit 或 stash）
$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 1 commit.
Git还会自动提示我们当前
master分支比远程的
master分支要超前1个提交。（这里我有异议，feature
的 commit 不会自动合并到master）
在
master分支上把readme.txt文件的最后一行改为：
Creating a new branch is quick & simple.
提交：
$ git add readme.txt $ git commit -m "& simple" [master 400b400] & simple 1 file changed, 1 insertion(+), 1 deletion(-)
现在，
master分支和
feature1分支各自都分别有新的提交，变成了这样：
这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：
$ git merge feature1 Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt 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. # # Unmerged paths: # (use "git add/rm <file>..." as appropriate to mark resolution) # # both modified: readme.txt # no changes added to commit (use "git add" and/or "git commit -a")
我们可以直接查看readme.txt的内容：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.=======
Creating a new branch is quick AND simple.>>>>>>> feature1
Git用
<<<<<<<，
=======，
>>>>>>>标记出不同分支的内容，我们修改如下后保存：
Creating a new branch is quick and simple.
再提交：
$ git add readme.txt $ git commit -m "conflict fixed" [master 59bc1cb] conflict fixed
现在，
master分支和
feature1分支变成了下图所示：
用带参数的
git log也可以看到分支的合并情况：
$ git log --graph --pretty=oneline --abbrev-commit * 59bc1cb conflict fixed |\ | * 75a857c AND simple * | 400b400 & simple |/ * fec145a branch test ...
最后，删除
feature1分支：
$ git branch -d feature1 Deleted branch feature1 (was 75a857c).
工作完成。
注：
远程的master和dev分支合并时一般不会冲突
dev 日常开发 —— dev test release ——测试—— checkout master —— merge dev
master分支不提交，只等到test release测试完毕后merge dev分支
一般情况下是快速合并，也可用--no--ff 加强commit 的显式
“
git branch
*dev
git commit -am "release"
git push origin dev
git checkout master
git merge --no-ff -m "merge with no-ff" dev
git push origin master
”
（除了直接在master上修复bug或紧急需求后，合并到dev使其最新的过程中，两个分支修改了同一处）
完。2017.12.13 最后批注
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 