|
1
2
3
4
|
每次提交前需要先和线上的对比，先把冲突解决掉，然后把线上的更新到本地，
最后把本地的提交上去。即：对比
-
>解决冲突
-
>更新
-
>提交。
svn 右键项目
-
> Team
-
> 与资源库同步
git git fetch
|
http://www.ruanyifeng.com/blog/2012/07/git.html
http://learngitbranching.js.org/
http://nvie.com/posts/a-successful-git-branching-model/
Git创建Develop分支的命令
git checkout -b develop master
将Develop分支发布到Master分支的命令
# 切换到Master分支
git checkout master
# 对Develop分支进行合并
git merge --no-ff develop
除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：
* 功能（feature）分支
* 预发布（release）分支
* 修补bug（fixbug）分支
第一种是功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop
git checkout -b feature-x develop
git checkout develop
git merge --no-ff feature-x
删除feature分支：
git branch -d feature-x
预发布分支
第二种是预发布分支，它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试
git checkout -b release-1.2 develop
确认没有问题后，合并到master分支：
git checkout master
git merge --no-ff release-1.2
# 对合并生成的新节点，做一个标签
git tag -a 1.2
再合并到develop分支：
git checkout develop
git merge --no-ff release-1.2
最后，删除预发布分支：
git branch -d release-1.2
修补bug分支
最后一种是修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补
高级
git merge 和 git rebase 小结
当我们使用Git log来参看commit时，其commit的顺序也有所不同。
假设C3提交于9:00AM,C5提交于10:00AM,C4提交于11:00AM，C6提交于12:00AM,
对于使用git merge来合并所看到的commit的顺序（从新到旧）是：C7 ,C6,C4,C5,C3,C2,C1
对于使用git rebase来合并所看到的commit的顺序（从新到旧）是：C7 ,C6‘,C5',C4,C3,C2,C1
因为C6'提交只是C6提交的克隆，C5'提交只是C5提交的克隆，
从用户的角度看使用git rebase来合并后所看到的commit的顺序（从新到旧）是：C7 ,C6,C5,C4,C3,C2,C1
本文转自 liqius 51CTO博客，原文链接：http://blog.51cto.com/szgb17/1830014，如需转载请自行联系原作者
