标签:
最近部门有人书写了一篇很好的Git协作方式,操作也简单,分支能以保持一条干净的线进行协作开发。这里做个笔记,方便之后查看。
PS:本文非原创。
原则
对策
步骤
1. Clone项目
git clone <版本库的网址> <本地目录名>
2. 获取远端最新状态,并从 origin/dev 上创建自己的分支
git fetch --all git checkout -b fix-file-upload-bug origin/dev # <分支名> <签出点> git push -u fix-file-upload-bug # 推送当前分支,并映射 origin/fix-file-upload-bug 为默认推送分支
此分支应只有你自己使用
3. 查看、确认修改,创建commit
(假设提交所有) git status git add -A git commit -m "[WIP] fix logic on server side, web page not fixed yet" git push # 在远端保留自己的备份以防万一, # 此操作会提交到 origin/fix-file-upload-bug,不影响origin/dev ... git add -A git commit -m "[WIP] web page fixed" ... git add -A git commit -m "[FIX] fix and tested"
(注:与svn不同,commit并不会影响远端分支,也就不可以被别人获取)
4. [rebase]更新本地代码,在 本地 解决冲突(以最新的 origin/dev 为基准)
Git的杀手功能,推荐详细阅读更多资料,欢迎补充。
git pull -r origin dev # 组合命令,拉取 & Rebase
git 当前分支 和 origin/dev 的 commit 纪录,进行 commit by commit 的比对。 相对频繁的 commit,能有效降低 rebase 的难度。
参考阅读 https://git-scm.com/docs/git-rebase 注意模型图
5. [push]把本地代码,立刻公布到 origin/dev上
git push origin HEAD:dev # 手动指定推送到 origin/dev 上(非默认分支 origin/fix-file-upload-bug)
由于步骤4[rebase]的存在,这一步肯定可以成功,且无冲突。
如 origin/dev 被保护,则需要到gitlab上发起MR(merge request),指定目标分支是 origin/dev ,由管理员审核代码后,触发合并操作。
标签:
原文地址:http://www.cnblogs.com/lovesong/p/5399336.html