git学习笔记-3

27. 分支管理策略
通常，合并分支时，如果可能，git会用fast forward模式, 但这种模式下，删除分支后，会丢到分支信息
如果要强制禁用fast forward模式，git会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息


28. 实战－－no－－ff方式的git merge
a. checkout -b dev //switched to a new branch ‘dev’
b. 修改readme.txt 
git add readme.txt
git commit -m “add merge”
c. git checkout master
d. git merge －－no－－ff -m “merge with no-ff” dev
这次合并要创建一个新的commit，所以加上-m 参数，把commit描述写进去。


29. 在实际开发中，我们应该按照几个基本原则进行分支管理
a. 首先，master分支应该非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；干活都在dev分支。也就是说dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本


30. 合并分支时，加上—no—ff参数就可以用普通模式合并，合并后的历史有分支，能看出来做过合并，而fast forward合并就看不出来曾经做过合并


31. bug分支
开发中，有了bug就要修复，在git中，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除
实例：现在有一个bug99号需要修复，但我正在dev分支上进行工作，工作正进行到一半，不能提交。但bug需要马上修复，这时候就可以用git stash 把工作现场储藏起来，等以后恢复现场后继续工作
git stash //Saved working directory and index state WIP on dev: 6224937 add merge
现在用git status查看工作区，就是干净的。因此可以放心的创建分支来修复bug。首先要确定在那个分支上修复bug，假定在master分支上修复，就从master创建临时分支
a. git checkout master
b. git checkout -b issue-99
c. 修复bug
d. git add 
e. git commit -m ‘fix issue-99’
f. git checkout master
g. git merge －－no—ff -m ‘merged bug fix 99’ issue-99
h. 删除分支 git branch -d issue-99
i. 切换回dev分支继续干活 git checkout dev
j. git status
k. git stash list //查看. git 把stash内容存在某个地方了，恢复有两种方法
l. 恢复：l1. git stash apply 恢复，恢复后用git stash drop 删除stash内容
l2. git stash pop恢复的同时把stash内容也删了
m. git stash list查看


32. 可以多次stash，恢复的时候先用git stash list查看,然后恢复指定的stash git stash apply stash@{0}


33. 修复bug时，通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash下，然后去修复bug，修复后，再git stash pop 回到工作现场


34. 软件开发中，总有无穷无尽的新的功能newbee要不断添加进来.添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。
a. git checkout -b feature-newbee
b. 开发完毕
c. git add newbee.c git status
d. git commit -m “add feature newbee”
e. git checkout dev 准备合并
f. 合并，删除分支 git merge feature-newbee git branch -d freature-newbee
e. 跳过f,销毁一个没有合并的分支用 git branch -D feature-newbee


35. 当从远程仓库克隆时，实际上git是把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin. 要查看远程仓库的信息 git remote 更详细的信息 git remote -v


36. 推送分支就是把该分支上的所有本地提交到远程库. 推送时，要指定本地分支，这样git就会把该分支推送到远程库对应的远程分支上
git push origin master
git push origin dev
但是，并不是一定要把本地分支往远程推送。
master 分支是主分支，因此要时刻与远程同步
dev 分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步
bug 分支只用于本地修复bug，没必要推送到远程
feature 分支是否推送到远程，取决于是否是几个人合作在上面开发


37. 抓取分支
一个人先在提交了dev分支，然后我再提交dev，出错。因为两个人的提交有冲突，解决方法如下：
git pull 把最新的提交从origin/dev抓下来，然后在本地合并，解决冲突，再推送
git pull失败，是因为没有指定本地dev与远程的dev的链接,根据提示设置dev和origin/dev的链接
git branch －－set-upstream dev origin/dev
再pull
但是合并有冲突，手动解决


38. 多人协作的工作模式：
a. 用git push origin branch-name 推送自己的修改
b. 如果推送失败，是因为远程分支比本地的更新，用git pull视图合并；
c. 如果合并有冲突，则解决冲突，并在本地提交；
d. 没有冲突或冲突解决掉后，用git push origin branch-name 推送就能成功
e. git pull 提示”no tracking information”， 说明本地分支和远程分支的链接关系没有创建，用命令git branch －－set-upstream branch-name origin/branch-name


39. 查看远程库信息 git remote -v；
从本地推送分支 git push origin branch-name ，如果推送失败, 先用git poll抓取远程的新提交；
在本地创建和远程分支对应的分支 git checkout -b branch-name origin/branch-name,本地和远程分支名字最好一致；
建立本地分支和远程分支的关联，使用 git branch －－set-upstream branch-name origin/branch-name
从远程抓取分支 git pull, 如果有冲突，先处理冲突