取消
清空记录
历史记录
清空记录
历史记录
e等进行代码托管,均基于Git。下面聊一聊研发人员必会的几个Git技巧和团队协作的一些Git工作流。
根据远程分支创建本地分支,但是不会切换到新分支,需要手动checkout
最后一个参数默认为HEAD,HEAD~2表示上上一个版本,也可以是某一个commit id处。
--mixed 将之前的提交删除,但是将改动移动到stage区(也就是index中)。
(1)windows 下,输入上述命令之后, 输入i 进入编辑窗口,更改rebase策略。详细解释都有提示,只需根据提示输入即可。
(2)选好rebase策略之后按Esc推出 输入:x 执行 刚才的rebase操作,然后会看到修改提交的信息界面
Centralized WorkFlow 这种模式对比熟悉SVN的研发人员非常容易适应。在Git 远程仓库有一个主分支,研发人员也在自己的本地克隆了一个完全一样的分支,研发人员可以在本地的分支上随意的进行代码编写,测试。当完成当前开发工作之后,可以直接push到远程主分支上。就算是有冲突也可以快速的解决。
中心仓库式工作流对于小型开发团队比较适用,人员少,改动也就相对比较少,出现冲突的几率也要少很多。就算是有冲突,合并也不会有太大问题。显然这种工作方式却不适合大型团队,几个开发组同时开发维护一个项目,这样代码会非常混乱,每个人的提交都会影响其他组开发的工作。如果再有不同组的开发任务上线时间点不一样,那么就是一场灾难。
基于Feature Branch WorkFlow 的Git工作流,其基于一个中心仓库,主分支(也可以是其他的生产代码分支)代表了项目历史。每次有新的开发任务的时候,基于主分支新创建一个Feature分支,和当前任务相关的代码都提交的这个Feature分支。
当开发工作进行到一定阶段,就可以提一个Pull Request代主分支,这个时候就可以让同事去Review自己的代码了。此时Review阶段可能会有一些小问题,或者同事给出了更好的建议,我们都可以针对性的修改代码。
最后让测试等工作都完成之后,就可以将Feature 分支合并到主分支上。最终测试完成之后就可以部署到生产上面。之后Feature分支可以视情况删除,或者保留一段时间之后再删除。
Main/Master Branch(主分支):维护着项目的历史记录,会记录每一次上线的标签,并且可以看到每一次上线的一些新特性等。
Develop Branch(开发分支):基于主分支,主要是为了下一次上线所使用的开发分支,可以接受Feature分支的Pull Request。当所有的新特性都已经合并完毕,那么就创建。
Release Branch(部署分支):当开发分支已经合并了足够的特性分支代码之后,会创建一个Release分支。此时Release分支不会接受任何Feature分支的Pull Request,仅接受一些Bug fix的Pull Request。Release分支部署上线之后,测试全部通过后会将代码合并到Develop 分支和主分支。
Feature Branch(特性分支):一般会基于开发分支创建出一条针对某个功能的分支,开发人员会基于这条分支进行开发和单元测试的工作,当本Feature开发完成之后。会将代码合并到Develop分支上,之后可以选择适时删除次分支。
Hotfix Branch(修补分支):针对与线上出现的紧急问题,从主分支,也就是上一次上线的标签出创建一个Hotfix 分支。当问题解决之后,可能会有一次紧急的上线来解决之前发现的问题。当问题解决之后,会将代码合并到主分支,和开发分支。以便下一次上线也会包含本次的紧急修复代码。
Support Branch(备用支撑分支):这个分支的应用比较灵活,有时候如果项目上线的时候基于各种可能性, (比如某个依赖的系统上线失败,或者其他不必要的特性上线失败) 可能会需要准备多个版本,那么Support Branch 就可以作为一条备用分支来使用。这个分支可以根据项目的实际情况来看是否需要使用!
我们也可以使用git flow 的一些命令来使用这个工作模式,会有一些既有的命令,使用起来会比较规范,但是也会有一定复杂,项目中可以根据实际情况使用!
Forking WorkFlow 相对与上面的几种协同工作方式有较大的不同。
开发人员一般会从公共远程仓库Fork一份完全一样的代码仓库到自己的私人远程仓库。对于私人远程仓库来说,开发人员是拥有者,拥有所有的权限。开发人能在本地仓库提交之后随时push到自己的私人远程仓库,随时进行Revert、Reset、Rebase等操作。
公共远程仓库为项目的组织官方仓库,保留有不同的分支,以及标签等。可以由私人远程仓库提交Pull Request到公共远程仓库的某个分支,待同事或者一些Owner Review过之后,就可以合并到公共仓库。
Forking WorkFlow 也是比较推荐的一种方式,研发人员push代码之后,可以随时在自己的提交基础之上进行Rebase操作,合并之前的许多提交,这样提交历史比较整洁,同时Review也比较方便。
使用Github合并PullRequest的时候,如果代码有冲突,通过网页解决冲突合并之后。Github会进行
关于Git协作,可以考虑Git Flow与Feature flow 还有Forking flow结合使用,Forking Flow有利于整理提交历史,Feature branch对于代码的管理比较友善。
本地的代码跑完一次测试的时候就可以提交一版,然后在需要push的时候在rebase合并一次。尽量完善自己的commit信息,写好每一次提交记录。
如果merge有问题能够正常的使用git merge --abort 解除merge, 然后再重新合并。