Android-自定义View
分享是最好的记忆--
如需转发请注明出处
[强调]:共同学习 共同进步 不喜勿喷
Git 分支说明 目录
- Branch 分类
- Branch 功能详解
- Branch 命令规范
Branch 分类 :
| 分支名 | 期限 | 备注 |
|---|---|---|
master |
长期 | 与线上同步 |
develop |
长期 | 相对稳定版本 |
feature/* |
短期 | 从develop创建 |
bugfix/* |
短期 | 从develop创建 |
release/* |
短期 | 从develop创建 |
hotfix/* |
短期 | 从master创建 |
Branch 功能详解 :
| 分支名 | 作用 | 备注 |
|---|---|---|
master |
负责记录上线版本的迭代，该分支代码与线上代码是完全一致的 | 主分支 |
develop |
该分支记录相对稳定的版本，所有的 feature 分支和 bugfix 分支都从该分支创建 |
开发分支 |
feature/* |
用于开发新的功能，不同的功能创建不同的功能分支，功能分支开发完成并自测通过之后，需要合并到 develop 分支，之后删除该分支 |
功能分支 |
bugfix/* |
用于修复不紧急的 bug ，普通 bug 均需要创建 bugfix 分支开发，开发完成自测没问题后合并到 develop 分支后，删除该分支 |
bug 修复分支 |
release/* |
用于代码上线准备，该分支从 develop 分支创建，创建之后由测试同学发布到测试环境进行测试，测试过程中发现 bug 需要开发人员在该 release 分支上进行 bug 修复，所有 bug 修复完后，在上线之前，需要合并该 release 分支到 master 分支和 develop 分支 |
发布分支 |
hotfix/* |
该分支只有在紧急情况下使用，从 master 分支创建，用于紧急修复线上 bug，修复完成后，需要合并该分支到 master 分支以便上线，同时需要再合并到 develop 分支 |
紧急 bug 修复分支 |
Branch 命令规范 :
| 分支名 | 命名规范 | 示例 |
|---|---|---|
| 功能分支 | feature/功能名称 | feature/login |
| bug修复分支 | bugfix/bug名称 | bugfix/add-user |
| 紧急 bug 修复分支 | hotfix/bug名称 | hotfix/delete |
| release分支 | release/预发布版本名称 | release/add-user |
进入正题
我们刚刚熟悉了git中常用到的分支，那么这些分支有什么意义呢？ 我就这么说吧，如果你是一个人开发，那么这确实没多大用处，当你在一个团队时这就发挥了很大的作用。
一般情况下，master分支是和线上版本保持一致的，那么我们需要对她非常重视，一切开发任务都不能在这里进行，因为在开发过程中如果出现bug就会弄脏master分支，如果我们在develop分支上
开发，不管出什么错误我们都不需要怕，因为master是干净的，实在不行可以从master重新拉取没有问题的项目对不对？
这个就是分支其中一个作用。
现在是这样的情况：我们在develop分支上完成了项目，那么之后对各个分支怎么处理呢？
过程大致是这样的： 将我们的develop分支合并到release分支，这是以个预发布分支，这个预发布分支是交给测试的同学的，测试同学在release分支上拉取完整项目进行测试，在测试过程中发现了一个bug。
测试同学找到了开发同学，开发同学在release分支上修改好问题，所有问题都解决了，这时release分支合并到master分支和develop分支。这时开发同学的develop分支是最新的，master分支也是最新的。
另外一种情况是这样的：线上产品使用过程中突然出现了一个bug，这是非常紧急的情况，这时需要处理的步骤大致如下：创建一个紧急bug分支名为hotfix（命名规则看上表），将master分支拉取到hotfix分支，
紧急修改完bug之后将hotfix同步到master分支和develop分支，再删除hotfix分支。世界就回复平静了！
总之分支会让你在更安全的环境下开发，git里面什么后悔药都有的。
工作流程：
-
克隆项目
-
签出并创建 dev 分支，使其跟踪远程的 origin/dev 分支。
-
在dev分支基础上创建自己的分支 member* 。
-
在自己的分支上添加文件
-
在自己的分支上修改文件
-
合并到dev分支
-
推送dev分支到origin/dev分支
-
更新 .gitignore 文件从 dev 新建一个分支 ignore （如果预测变更频繁就建立一个远程分支，现在一般都有模板，偶尔有个没有忽略的直接在dev分支上改就可以了）更新忽略文件尽快合并到\推送到 origin/dev 分支 （避免两个组员同时更改该文件造成冲突。）
1 创建本地仓库
$ git clone https://coding.net/tangyikejun/GitTest2.git
$ git checkout -u -b dev origin/dev
$ git checkout -b [MEMBER_NAME];
2.更新本地仓库
$ git add .
$ git commit -m”your comments”
// … // 多次提交后完成了一项新的功能，自己的分支下能正常运行
$ git checkout dev
$ git merge --no-ff [MEMBER_NAME] // [MEMBER_NAME] 是自己的分支名称
$ git push
3.更新 .gitignore 文件
$ git checkout dev
//… // 更新忽略文件
$ git add .
$ git commit -m“更新.gitignore文件”
$ git push
4.常用查询命令
$ git branch // 查看自己所在分支 以及自己所拥有的分支
$ git log --pretty=“%h - %cn(%ci): %s” --graph // 查看自己的提交记录
$ git reflog // 查看自己的操作历史
$ git status // 查看本地仓库当前的文件状态
$ git blame [FILE_PATH] // 查看文件的每一部分最后由谁改动
5.意外情况处理意外：
推送代码到远程 dev 分支时发生冲突。解决方案：先把 远程仓库的 origin/dev 分支拉取下来，解决冲突文件后再推送。平时的时候尽量避免不同组员更改同一个文件。
$ git push
// … // 遇到错误
$ git pull
// … // 解决冲突
$ git add .
$ git commit -m”solve conflict:由于XX原因出错，修改XX文件解决问题”
$ git push
意外：不小心把自己的工作成果push到了master分支。解决方案：先对master进行回退，再使用git push -f将错误的提交删除。意外：错误地把文件添加到git仓库并推送到了远程。解决方案：先将文件从git仓库中移除，但是保留工作目录中的对应文件。然后将该文件添加到忽略文件中，再重新进行提交。命令如下：
$ git rm --cached [FILE_PATH]
… // 将该文件添加到 .gitignore 文件
$ git add .
$ git commit -m"detach file XXX"
$ git push
三、预发布责任人 & 版本修复责任人
1.预发布责任人当需要发布新的版本时，预发布责任人：基于最新的 dev 分支创建一个 release-版本号 分支进行修缮工作合并到 dev 分支合并到 master 分支打标签删除 release-版本号 分支
$ git checkout dev
$ git pull
$ git checkout -b release-1.2
//… // 进行修缮工作
$ git checkout dev
$ git merge --no-ff release-1.2
$ git checkout master
$ git merge --no-ff release-1.2 // 在评论中写入相比上个版本新增的功能，修复的bug等详细内容
$ git tag v1.2
$ git branch -d release-1.2
使用 git show [TAG_NAME]可以查看标签对应的提交信息。
2.版本修复责任人当新发布的版本发现 bug 时，版本修复责任人：基于最新的 master 分支创建一个 hotfix-版本号 分支进行debug工作合并到 master 分支打标签合并到 dev 分支删除 hotfix-版本号 分支
$ git checkout master
$ git pull
$ git checkout -b hotfix-1.2.1
//… // 进行修缮工作
$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag v1.2.1
$ git checkout dev
$ git merge --no-ff hotfix-1.2.1 // 在评论中写入修复的bug等详细内容
$ git branch -d hotfix-1.2.1
3.意外情况处理意外：某组员完成自己的任务后合并到 dev 分支，推送时发现 release 分支的修缮工作更改了自己原来的文件，产生了冲突。解决方案：把 origin/dev 分支拉取下来，将冲突解决后再次提交。(注意这里解决冲突后 master 分支上的文件与该组员的工作成果依旧是有冲突的。除非该组员解决冲突时不更改 relese 时的修缮代码，而仅仅更改自己的代码来解决问题。因此，一旦有冲突产生，最好双方进行合理交流达成一致意见。减少冲突。)四、成员远程仓库当某个团队成员希望其他成员协助完成他的编程任务时，该成员可以为自己的本地仓库创建一个远程仓库作为成员远程仓库，方便其他成员协助。建立成员远程仓库可以避免中心远程仓库的代码交流繁杂混乱。成员远程仓库在在操作上是中心远程仓库的简化版。仅在细微处有所不同。
1.求助者创建成员远程仓库添加成员远程仓库推送自己的分支到成员远程仓库的 master 分支拉取成员远程仓库的 master 分支到自己的分支
$ git remote add [ALIAS_NAME] [GIT_ADRESS]
$ git push [ALIAS_NAME] [BRANCH_NAME]:[BRANCH_NAME_REMOTE]
$ git pull
举例：
$ git remote add binRepo https://coding.net/chenbin/GitTest2.git
$ git push binbin binRepo:master //由于是第一次推送，该操作已经使得分支binbin 跟踪了远程分支 binRepo/mastr
当某个分支 a 跟踪了远程分支 b，即 b 成为 a 的默认拉取来源，也因此，一个本地分支同一时间只能跟踪一个远程分支。让本地某分支跟踪远程分支的命令
$ git branch -u [REPO_NAME]/[REMOTE_BRANCH_NAME] [BRANCH_NAME]
// git branch -u binRepo/master binbin
2.协助者克隆成员远程仓库在 master 分支基础上创建自己的分支 member*在自己的分支上修改代码合并到 master 分支后推送到成员远程仓库
$ git clone https://coding.net/chenbin/GitTest2.git
$ git checkout -b member1;
//… //修改代码
$ git add .
$ git commit -m"我帮你把XX功能完成了"
$ git checkout --no-ff merge member1;
$ git push
git 关于分支的常用命令：
查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name>
创建+切换分支：git checkout -b <name>
合并某分支到当前分支：git merge <name>
删除分支：git branch -d <name>
重命名分支：git branch -m oldbranchname newbranchname
我是ElyarAnwar，在技术的道路上摸爬滚打；
热爱生活，热爱技术；如果喜欢记得点赞；
网友评论