Skip to content

Git

Git-Basics

Tutorial

（教程）

协作开发基本教程

更加规范的协作开发教程

Advanced-Commands

（进阶命令）

以下文字只是简单记录思考，实际问题尚未解决（因为已知的够用了，剩下的等有实际应用场景再看，这样性价比（知识/时间）更高）。

场景

正确的 github 工作流 bilibili.com中讲解的 提交 PR 时发现远程有新提交 的情况。

git rebase

  • 原理：改写提交历史，将一个分支的提交历史“重新应用”到另一个分支上

  • 优点：解决冲突

  • 缺点：

    • 改写提交历史，可能导致冲突。

    • 如果其他人基于你的分支工作，强制 rebase 会破坏他们的提交。

  • 替代品：git merge

git push -f origin my-feature

  • （强制推送）强制将本地分支覆盖远程分支的内容
  • 缺点：
    • 破坏团队协作：其他开发者基于远程分支工作的代码可能被覆盖。
    • 数据丢失风险：被覆盖的历史无法轻易恢复。
  • 替代品：不知道

Reflection

（思考）

场景：由 Github 的 squash and merge（将多个 commit 合并为一个）， 想起了做 mini-spring 时作者根据 tag 版本号作为 commit 的归类，由此引发对 commit 的思考。

首先产生的疑问：将多个 commit 合并会引发以下问题：

  • 不够详细：可能隐藏开发过程中的细节。
  • 团队协作中不便回溯中间提交内容。

然后理解了 dev 分支与 master 分支的作用：

  • dev 分支：保留详细的开发提交历史（分类提交），方便调试和回溯。
  • master 分支：提供更清晰的提交历史。

至于 tag ，可以在之后编写项目时采用这种方法，阶段性完成项目即可使用 tag 当作“里程碑”记录，也可方便归类 commit 。

.gitignore

（大一下写的，再次看到的感受：杂乱+没必要，不想花时间重构，先放着吧）

  1. 空行不会匹配任何文件

  2. # 用于注释，\ 用于转义（如果要使用\,要加"\"）

  3. * 可以匹配任何字符（0次或多次）,? 可以匹配任何字符（1次）（注意，都不可以匹配\）

  4. /用于分割目录

    • 当/在开头时，表示从.gitignore文件所在目录开始匹配，否则下级都将匹配

    例如：/src表示只匹配，如果是src，那么/x/ax，/x/y/ax都将被匹配

    • 当/在末尾时，只匹配目录，否则同名的目录和文件都将匹配

    例如：/a/b/c/只匹配c下的目录，/a/b/c会将c文件和下级所有的文件都匹配到

  5. 原先被排除的文件，使用!后该文件将会被重新包含。但是如果该文件的父级目录被排除，那么加!也没有用

  6. [] 用于匹配一个字符列表（暂时用不到）

  7. ** 用于匹配多级目录（暂时用不到）

//判断.gitignore的某个文件的忽略是否生效
git check-ignore 文件名或目录路径
//如果生效，就会显示这个文件名

//查看在.gitignore中具体是如何被忽略的
git check-ignore -v 文件名或目录路径

注意事项

  1. .gitignore只能忽略掉那些没有被追踪的文件，所以先纳入版本管理后写入.gitignore是无效的

  2. 同样的，已被.gitignore忽略的文件也是无法加入版本库的

两个都有破解之道，等有实际应用场景的时候再看吧

Github

PR

提交 PR 有分支和 Fork 两种方式

  • 如果你对仓库有写权限，可以直接创建一个分支，在分支中开发后提交 PR。
  • 如果你没有写权限，需要 fork 仓库到自己的账户，在 fork 的仓库中开发后提交 PR。