git提交流程

git提交流程

基础Git环境配置

• 以MyProject为例，项目地址为http://gitlab.xxx.com/someUser/MyProject，在Gitlab上将中央仓库fork到个人空间（网页上的fork按钮）
• 为本项目(自己fork出来的)配置ssh 首先创建本机的公钥私钥，
  然后在http://gitlab.xxx.com//<项目名如:MyProject>/settings/repository中的DeployKeys选项里配置你的公钥，这样你的当前设备就可以通过ssh加密方式来和gitlab连接
• 将个人空间内的项目clone至本地。

git clone ssh://git@gitlab.xxx.com:10022/<your_username>/MyProject.git
**clone之后，个人仓库的url会自动记为origin**

• 添加中央仓库的远程地址。

#关联指定url的远程仓库（这里就是中央仓库），名字记做upstream
git remote add upstream ssh://git@gitlab.xxx.com:10022/someUser/MyProject.git

由于上一步中自动将个人仓库记做了origin，所以此处就无需 git remote add origin

开发前准备（每次开发新的需求从此处开始)

• 从中央仓库拉取最新代码。

#从upstream仓库的branch-1.1.x分支拉取代码到本地的当前分支上，upstream就是之前配置的中央仓库的代号
git pull upstream branch-1.1.x

若拉取的代码与本地发生了冲突，可以使用git stash ， git pull ， git stash pop stash@{0} 然后手动处理冲突后，进行接下来的创建开发分支

• 创建开发分支

git checkout -b MyProject-XXX # XXX代表redmine中的问题编号

正式开发及提交

每个需求开发过程中不要频繁commit，只需在最后commit, 并标注问题编号和一段注释
注意push至origin(个人仓库)而非upstream(中央仓库)

git add -A #将工作区发生的所有变动（文件修改、新增、删除）添加到暂存区
git commit -m "[MyProject-XXX] <some comments>" #将暂存区提交到本地仓库
#将本地MyProject-XXX的分支提交到名为origin的远程仓库的MyProject-XXX分支，若远程不存在改分支则创建
git push origin MyProject-XXX:MyProject-XXX

Merge流程

• 提交merge请求（在网页上完成）
  如果代码review时发现问题需要修改，修改后可以通过如下方法进行提交：

git commit --amend --no-edit # 不修改commit message
git push origin MyProject-XXX:MyProject-XXX --force

这样，您的最新修改将能够自动显示在Gitlab的页面上。

• merge成功之后,在本地切换回最初的分支,然后删除为了当前需求创建的分支：

git checkout branch-1.1.x
git branch -d MyProject-XXX

• 继续进行下一个需求的开发，重新回到开发前准备阶段

补充

fetch+merge=pull

比如本地master分支开发后commit，待push前需要从origin/master拉取新的改动。

1. 使用fetch+merge：
   git fetch会将origin/master 分支的拉取到本地保存起来，并不会影响本地master分支。
   然后我们可以通过 git log、git diff 查看改动情况。
   然后使用git merge origin/master 合并到当前分支。如果出现冲突，需要手动处理冲突后git add、git commit
   最后 git push
2. git pull= fetch+merge:
   略过了fetch之后可以查看变化的步骤，直接到手动处理冲突阶段。

git rebase

http://gitbook.liuhui998.com/4_2.html
假设你现在基于远程分支"origin"，创建一个叫"mywork"的分支。

$ git checkout -b mywork origin

现在我们在这个分支做一些修改，然后生成两个提交(commit).

$ vi file.txt
$ git commit
$ vi otherfile.txt
$ git commit

但是与此同时，有些人也在"origin"分支上做了一些修改并且做了提交了. 这就意味着"origin"和"mywork"这两个分支各自"前进"了，它们之间"分叉"了。

在这里，你可以用"pull"命令把"origin"分支上的修改拉下来并且和你的修改合并； 结果看起来就像一个新的"合并的提交"(merge commit):

但是，如果你想让"mywork"分支历史看起来像没有经过任何合并一样，你也许可以用 git rebase:

$ git checkout mywork
$ git rebase origin

这些命令会把你的"mywork"分支里的每个提交(commit)取消掉，并且把它们临时 保存为补丁(patch)(这些补丁放到".git/rebase"目录中),然后把"mywork"分支更新 到最新的"origin"分支，最后把保存的这些补丁应用到"mywork"分支上。

当’mywork’分支更新之后，它会指向这些新创建的提交(commit),而那些老的提交会被丢弃。 如果运行垃圾收集命令(pruning garbage collection), 这些被丢弃的提交就会删除. （请查看 git gc)

现在我们可以看一下用合并(merge)和用rebase所产生的历史的区别：

在rebase的过程中，也许会出现冲突(conflict). 在这种情况，Git会停止rebase并会让你去解决 冲突；在解决完冲突后，用"git-add"命令去更新这些内容的索引(index), 然后，你无需执行 git-commit,只要执行:

$ git rebase --continue

这样git会继续应用(apply)余下的补丁。

在任何时候，你可以用–abort参数来终止rebase的行动，并且"mywork" 分支会回到rebase开始前的状态。

$ git rebase --abort