记得:用快乐去奔跑,用心去倾听,用思维去发展,用努力去奋斗,用目标去衡量,用爱去生活。
git命令
1)新建一个分支:
git checkout -b feature_order_users_1.0 origin/master
git add . 添加当前目录的所有文件到暂存区
git commit -m ‘描述’ 提交暂存区到仓库区
2)合并当前分支到develop分支
git checkout develop
git merge --no-ff feature_order_users_1.0
git push origin develop
3)确认没有问题后,合并到master分支:
git checkout master
git pull origin master
git merge --no-ff fixhot-liyunfang0522-login
git tag -a fixhot-liyunfang0522-login 打标签
git push origin master
4)最后,删除分支:
删除本地 git branch -d <BranchName>
删除远程 git push origin --delete branchname
查看项目分支 git branch -a
刷新项目分支 git feach -p 再查看
回滚 git log -10
git reset --hard 2723823h 重置暂存区与工作区,与某次commit保持一致
git push -f origin master 强行推送当前分支到远程仓库,即使有冲突
git add . 添加当前目录的所有文件到暂存区
git checkout . 恢复暂存区的所有文件到工作区
git config --global user.name " "
git config --global user.email " "
git fetch --all 查看所有分支
git checkout fixhot-- 切换到要上线的分支
git pull origin fixhot-- 拉代码到本地
git checkout master 切换master
git merge --no-ff fixhot-- 合并要上线的分支 到当前分支
git reset --hard 重置暂存区与工作区,与上一次commit保持一致
git pull origin master 重拉代码最新的
git merge --no-ff fixhot-- 合并
git status 会有几个冲突的 修改
分支介绍
master
为主分支,指向 可用于生产环境 的状态。
develop
为整合分支,总是反映 下一个版本的最新开发状况
当 develop 分支上的源代码达到一个稳定点并准备发布时, 所有的更改都应
该以某种方式合并回 master 分支, 然后使用发行版本进行标注。
辅助分支
--- 功能分支 发布分支 修复 Bug 分支 支持成员间并行开发, 轻松跟踪功能开发、生产版本发布、还能快速修复生产环境中产生的 Bug 。和主分支不同的是,辅助分支只有有限的生命周期,通常在完成使命后会被删除。
功能分支
可能源自于:develop 分支 必须合并回:develop 分支 命名惯例:均可,不能包含 master, develop, release-* ,hotfix-* 功能分支通常存在开发人员的仓库中,不会出现在 origin 仓库。
创建一个功能分支
当我们开始写一个新的功能时,请从 develop 分支中切换出来 # git checkout -b myfeature develop 新建一个分支并切换到该分支
在develop中加入已经完成的功能
完成的功能被合并进入 develop 分支中 $ git checkout develop 切换到develop分支 $ git merge --no-ff myfeature 合并myfeature分支并保留myfeature分支历史 $ git push origin develop 上传本地指定分支到远程仓库 --no-ff 标记将会在分支合并的时候在创建一个新的提交对象,即使这次合并可以使用 fast-forwark方法进行提交,这就可以避免丢失功能分支的历史信息并且可以把所有的功能在叠加在一起提交上去
发布分支
可能源自于:develop 分支 必须合并到:develop 和 master 分支 分支命名习惯:release-*
创建发布分支
假设我们当前发布的产品版本为 1.1.5 ,并且即将发布一个新的大版本。 develop 分支已经为『下一版』做好了准备,我们决定把版本号改成 1.2,那么,我们要做的只是检出发布分支并给它一个可以反映版本号的名字: $ git checkout -b release-1.2 develop 新建并切换到rel $ ./bump-version.sh 1.2 $ git commit -a -m "Bumped version number to 1.2" 提交所有修改过的 -a 只提交添加的 -a -m 提交添加的和修改过的
直到确定会推出发布版的这段时间里,新分支都会一直存在。在此期间,bug 修复可能会应用到这个分支上(而不是 develop 分支)。bump-version.sh 是一个虚构的脚本文件,用以改变工作副本中的一些文件来反映新版本。(当然也可以手动啦,重点是 那些 改变的文件)然后,碰撞后的版本号就被提交了。
完成并发布你的分支
$ git checkout master 切换到master $ git merge --no-ff release-1.2 $ git tag -a 1.2 打含附注的标签 在文本添加 -m 方便 总结,只要在打标签时添加-m”xxxx”,都可以添加标签说明,并在git show 显示的信息中显示打标签者、打标签日期和标签说明。而git tag -a应该只是声明要打一个含附注的标签,可以用-m添加,又或者是使用它跳转的文本编辑软件添加,总之加上-a的标签必须要有标签说明,而git tag不会强制要求。当使用git tag -m效果和git tag -a -m是一样的。
为了保持发布分支所做的更改一致,我们需要将这些更改合并到 develop 分支中。
$ git checkout develop $ git merge --no-ff release-1.2 这一步可能会导致合并冲突(可能是因为我们已经更改了版本号)。如果是这样,尝试修复它并再次提交。现在我们已经完成了所有步骤,发布分支可以被删除了,因为我们不再需要它了: $ git branch -d release-1.2
热修复分支
分支可能来自于:master 必须合并到:develop 和 master 分支命名惯例:hotfix-* 当生产版本中的一个严重的 bug 必须马上被修复,热修复分支可能从 master 分支上用于标记生产版本的对应标签上创建分支。其本质是当有人准备对生产版本进行快速修复时,团队成员(在 develop 分支)可以继续工作。
创建修复bug分支
修复 bug 分支创建于 master 分支。 例如,1.2版本是当前生产环境的版本并且有 bug 。 $ git checkout -b hotfix-1.2.1 master 新建并切换 $ ./bump-version.sh 1.2.1 bump-version.sh 是一个虚构的脚本文件,用以改变工 作副本中的一些文件来反映新版本。 $ git commit -a -m "Bumped version number to 1.2.1" 打标签 不要忘记在关闭分支后更新版本号! 然后,修复 bug ,一次提交或多次分开提交。 $ git commit -m "Fixed severe production problem"
完成一个修复 bug 分支
bug 分支需要合并到 master 和 develop 分支上,以保证在下一版本中也包含该 bug 修复。 这与完成发布分支完全相似。 首先,更新 master 并对这次发布打上 tag 。 $ git checkout master $ git merge --no-ff hotfix-1.2.1 合并分支并保留历史 $ git tag -a 1.2.1 然后,在 develop 分支里包含 bug 修复分支的改动: $ git checkout develop $ git merge --no-ff hotfix-1.2.1 对于上面的规则,有一点是例外的: 当发布分支已经存在时, bug 修复分支的改动应该合并到该发布分支,而不是 develop 分支。当发布分支完成的时候, 把 bug 修复分支反向合并到发布分支中,最终也会导致 bug 修复被合并到 develop 分支中去。(如果 develop 分支中的工作马上就要这个 bug 修复的改动并且不能等待发布分支完成,那么现在你也可以安全地将 bug 修复合并到 develop 分支中去。)
git分支事务
1、master权限
受保护分支 别人无权限合并和提交到master
先修改项目成员权限 再修改项目分支权限

转载于:https://blog.51cto.com/14124898/2400986
54

被折叠的 条评论
为什么被折叠?



