首先

我从2月份开始在Maester Gilde公司工作！由于在技术方面和在Qiita上都还是新手，我希望今后能输出培训内容。请多关照。

我想写一下关于Git的内容。

所学之事

Git是一种版本控制系统。

可以管理编辑内容和历史记录的工具。

使○○显示
修正了××

可以通过留下诸如记录等方式进行管理

本地和服务器有什么区别？

本地是个人的工作场所，
服务器是可以与他人共享的工作场所（如GitHub）。

Git terminology (in Chinese):

犯罪

将编辑内容记录到存储库中

为什么在提交（commit）之前需要添加（add）呢？

当执行add操作时，将文件保管在位于存储库和工作目录之间的索引中。通过这个过程，我们可以在commit时排除不必要的更改，也可以仅提交部分修改内容。

推 (tuī)

我想将本地的3个提交同步到服务器上的2个提交！

→ 按下推送按钮后，将会在服务器上进行反映。

拉 (lā)

在本地端共有两次提交，在服务器上共有三次提交。
「想要将服务器的提交反映到本地！」

当进行拉动操作时，会在本地进行实时更新。

拉取请求

在提交(push)之后，可以在GitHub上发起(pull request)并请求进行审查(レビュー)。

撰写易于审阅的拉取请求非常重要！明确写明工作内容和目标是为了什么。

• タイトル、本文の記載

 

• 変更概要、タスクへのリンクを貼る

 

変更箇所へのコメントの記載

合并

集成以前的分支来导入任务内容。

快速合并

如果合并操作的进行速度不同，即使是相同的修改内容，也会在原有commit之后生成一个称为merge commit的不同commit。

在度量上有差异的情况下，能够进行快速合并吗？

使用rebase可以使分支进度统一 = 可以快速进行合并!

取

将远程最新信息带到本地
仅当原始/分支名称（远程跟踪分支）更新时，本地分支本身不会被更新

从远程的主分支fetch到本地的origin/master分支中的最新信息
从本地的origin/master分支merge到本地的master分支中的最新信息

将这个fetch和merge的组合称为pull。

修改基底

重新创建分支，但更改内容相同，会生成新的commit。

在GitHub上使用的合并（3种类型）

制定合并的规定并进行开发。

创建一个合并提交

重新基准和合并
修改内容相同，但是会产生不同的提交
历史记录被整合成统一的形式，更易于查看

合并和压缩
将原本的多个提交合并成一个全新的提交
如果压缩得太多，就无法撤销合并，所以最好按功能单元进行压缩。

冲突

在多人协作且在同一行进行不同修改后合并时，可能需要手动进行更改。

为了避免发生冲突，可以有意识地掌握。

• プランニングの段階でコンフリクトは予見できるので作業が平行しないように調整する

 

• コードの責務が明確な状態になっている

 

• タスクの範囲とcommitの変更内容を一致させる

 

フォーマッタのルールを統一する

使用Git Bash进行rebase操作。

git重新设置基准点，并进行互动编辑，位于<commit位置>。

进入提交位置的事物

• branch名

 

• commit hash

 

• HEADからの相対位置

「HEAD~~~」とするとHEADから3commit前という意味になる

HEAD是什么？

当前工作地点，操作分支的事项
※ 有时也指代提交(commit)本身

分支的使用方法- Git Flow

将其分为四个阶段来考虑。

开发阶段中会添加新功能。

使用的分支：develop、feature(feat)
父分支：master

应用阶段
应用在正式环境中运行。

使用的分支: 主分支

保守阶段
修复错误
重构

使用的分支：修复（热修复）分支
父分支：主分支、发布分支（在开发后的发布分支上进行修复）

测试阶段（开发已经完成的状态），对添加了新功能、修复了错误和进行了重构的状态进行操作确认。

使用的分支：release
父分支：develop

总结

由于之前对Git没有深入思考，通过参加培训的形式学习，我对Git有了更深的理解。
实际操作中，通过使用SourceTree，我能直观地确认到索引的存在，并且能更容易地理解提交等操作的过程。
由于在Git bash中使用vim以及第一次使用rebase等命令，也遇到了很多新的操作，所以我希望在使用中逐渐记住它们。