GitTeam
目录 start
目录 end|2020-04-27 23:42|
- 整理和学习这几种管理方式
Github gitee gitlab bitbucket 等各大平台都是这样一种模式:
个人和个人开发者之间是并行master，只适合偶尔开发提交一些代码
组织就是适合给多个人，等同的稳定开发时，分支就会比较明确，这个笔记就是记录组织中git的使用
- Git Flow常用的分支
- Production 分支
- 也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改
- Develop 分支
- 这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支
- Feature 分支
- 这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release
- Release分支
- 当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支
- Hotfix分支
- 当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release
- Production 分支
-
分支图复杂的一个项目
只是演示分支的复杂度
- 提交之前先更新
- SVN更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且并且自己测试之后，谨慎地提交。
- 如果提交过程中产生了冲突，则需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。
- 如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。
- 保持原子性的提交
- 每次提交的间歇尽可能地短，以一个小时，两个小时的开发工作为宜。如在更改UI界面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。
- 提交时注意不要提交本地自动生成的文件
- 对于Java来说, IDE自身配置文件, 和字节码文件是无需提交的 例如 .idea目录 iml文件
- 不要提交不能通过编译的代码
- 代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库，项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。
- 不要提交自己不明白的代码
- 提交之后, 你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。
- 提前协调好项目组成员的工作计划
- 在自己准备开始进行某项功能的修改之前，先给工作小组的成员谈谈自己的修改计划，让大家都能了解你的思想，了解你即将对软件作出的修改，这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足，完善你的设计。
- 对提交的信息采用明晰的标注
-
+)表示增加了功能 -
*)表示对某些功能进行了更改 -
-)表示删除了文件，或者对某些功能进行了裁剪，删除，屏蔽。 -
b)表示修正了具体的某个bug
-
git commit message 的模板化
commit message 包含三个部分，header, body和footer，其中header必须有，body和footer可以按情况省略。
-
type字段- feat：新功能（feature）
- fix：修补bug
- docs：文档（documentation）
- style： 格式（不影响代码运行的变动）
- refactor：重构（即不是新增功能，也不是修改bug的代码变动）
- test：增加测试
- chore：构建过程或辅助工具的变动
-
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。 也就是写用户会感觉到改变在哪个地方。 -
subject是 commit 目的的简短描述，不超过50个字符- 以动词开头，使用第一人称现在时，比如change，而不是 changed 或 changes 第一个字母小写 结尾不加句号（.）
-
Body部分是对本次 commit 的详细描述，可以分成多行- 使用第一人称现在时，比如使用change而不是changed或changes。
- 应该说明代码变动的动机，以及与以前行为的对比。
-
Footer- 如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。
- 关闭 Issue
- 新建 ~/.gitmessage 文件
- ~/.gitconfig 中添加
[commit]
template = ~/.gitmessage
配置好后 git commit 不指定-m 参数就会调用该模板
诚然, 命令行是高效的, 从学Git开始就是用命令行, 这只是在单兵作战或者说没有使用多分支的情况下是没有问题的
当多人协作时, 需要Review代码时, 知道每个人每次提交更改了些什么, 图形化就很方便了
Github: repo
轻量, 简洁, 跨平台, 正是我想要的
从源码安装是最快最简单的, 而且能安装到最新的
- git clone --depth 1 git://github.com/git-cola/git-cola.git
- sudo make prefix=/usr install
- 功能强大 付费软件
- 美观够用
Official site 仅支持 Windows 和 Mac
master发行分支dev开发主分支dev-*开发者分支fea-*开发者自己的功能性分支
- 在码云上创建私有仓库，然后管理成员，将开发者一一邀请进来，然后这时候就有了一个问题：
- 所有的开发者都具有master的所有权限，所以这时候就会很容易出现冲突,所以就需要设置master和开发主分支dev为保护模式，只有管理员负责进行推送
- 管理员， 新建若干分支：
git branch 分支提交到远程git push --all - 对应的开发者克隆项目，然后
git checkout 对应的自己的分支就可以开始工作了- （ 如果没有分支就下拉命令
git fetch origin 对应的分支）
- （ 如果没有分支就下拉命令
- 然后各个开发者写自己的，然后提交
git push就行了 - 管理员需要
git fetch origin 分支得到所有分支- 针对每个分支进行拉取： 切换过去
git checkout 开发者分支，然后git pull 开发者分支下拉最新 - 然后选择合并
git merge --no-ff 开发者分支，处理冲突然后提交
- 针对每个分支进行拉取： 切换过去
- 开发者下拉自己的分支 或者开发主分支 dev 即可
分支的处理的一次实验 2017-10-21 23:57:34
-
git fetch --all获取远程所有分支（新分支） -
git pull --all获取所有分支最新提交 这个就会自动合并？？？越来越不理解了 -
dev-test 分支进行修改，然后提交一次，然后push
-
master：
git merge --no-ff dev-test进行合并，就会在分支图上得到一个环- master 分支本地会多出2个提交
-
dev-test 进行修改，然后1次提交，push
-
master :
git pull origin dev-test执行merge命令就会提示没有可以合并的修改。- 这是为什么？？？？
双方都有修改
- 开发人员提交完后，主分支管理人员切换到开发人员的分支然后
git pull 开发人员分支，然后切换回主分支上git merge --no-ff 开发人员分支（填写注释） 然后push- 然后切换到开发人员分支上执行
git merge master 然后 git push还是git pull origin master - 然后通知开发人员下拉其自己的开发分支即可
- 然后切换到开发人员分支上执行
只有一方修改
-
主分支进行修改了开发分支没有动，那么开发分支 直接下拉
git pull origin master下拉修改代码即可 -
如果是开发分支修改，主分支没有动，那么管理员负责切换到开发分支 然后pull 然后merge 然后 push 然后切换开发分支 然后 pull