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, 如果有冲突,先处理冲突
通常,合并分支时,如果可能,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, 如果有冲突,先处理冲突