首次使用git
我最近才开始使用Git，关于我大概理解的部分进行了备忘录，以免忘记。
这可能适用于那些对Git不太了解的人。
我会讲一些非常基础的内容，请多多指教。
请在我有错误的地方指正我。
请用中文进行改写
– 请将以下内容用中文进行改写，只需要一种选项：
在中文中，可以这样来表达：git是什么？
分散式版本控制系统……
因为被说了这样的话，我还是不太明白，所以能不能更简单点？
- ディレクトリの中身をそのまま保存して自由に書き戻したりできるシステム
还有
-
- たくさんの人と同じディレクトリを共有したり
- そのディレクトリの新しいとこ同士をマージしたり
可以的。很方便！
我觉得是这种感觉。
使用Git
请自行搜索如何安装。
关于提交和使用的方法，如果搜索就能找到，所以不必写出来，没问题吧。
Git的工作原理
Git是由许多称为”commit”的块组成的。 “commit”是记录目录在创建时的状态的一个对象。它只是一个物体，一个块。这是非常重要的。Git的职责就是创建并存储许多这样的”commit”。通过检出特定的旧”commit”（将”commit”的内容写回工作目录），Git就像是在进行版本控制一样运作。
提交要指向自己的亲人
每个提交都有自己的ID（虽然以SHA1哈希表示，但我们称之为ID）。
而且，每个提交中都包含着自己的父提交的ID。
通过查看提交，我们可以了解到该提交的源提交。
コミットA ←(親を指し示す)コミットB
那么，在这个父提交中也有一个父提交，一直追溯下去的话…………….
... ← コミット8 ← コミット9 ← コミットA ←(親を指し示す)コミットB
成功生成了日志。
git log命令是从当前提交（称为HEAD）开始一直追踪并显示所有父提交的命令。
HEAD是什么意思？Branch是什么意思？
无论是HEAD、分支还是标签，它们都是指向特定提交的别名。在这些中间，标签是最容易理解的。顾名思义，它们是用来命名的，
- 特定のコミットに貼り付けるタグ
是这样的。就是这样。
那么，“branch”是什么意思呢？
- 特定のコミットに貼り付けられたタグ
是的，这与标签的解释是一样的。
换句话说，创建或删除分支只是给它起名为“分支”标签，或者把它的标签去掉而已。
总而言之，这意味着
我的日志通常都是这样的。
↓HEADという名のタグ
コミット11 - コミット22 - コミット33 - コミット44 - コミット55
↑masterという名のタグ(ブランチ)
如果在提交33后命名为branch01进行提交，就会变成这样。
↓HEADという名のタグ
コミット11 - コミット22 - コミット33 - コミット34 - コミット35
↑branch01という名のタグ(ブランチ)
我们都是一个线，但如果一起显示的话……
↓master
コミット11 - コミット22 - コミット33 - コミット44 - コミット55
＼ コミット34 - コミット35
↑branch01
分支已经创建了！跟踪父对象的日志在中途合并了！看起来像是个分支→就是一个分支→这就是分支的特性。
使用中文进行本地化修改，只需要一个选项：
添加标签”tag01″到提交号为55的版本上
添加标签”tag02″到提交号为35的版本上
删除分支branch01
尝试执行。
↓tag01タグ
コミット11 - コミット22 - コミット33 - コミット44 - コミット55
＼ コミット34 - コミット35
↑tag02タグ
根据日志来看，现在只添加了一个普通的标签，但它看起来却像是一个分支。
Can you please provide the original sentence that you would like me to paraphrase in Chinese?
分支 = 只是一个标签
分支和标签有什么区别？
当我们提交时，自动切换到一个新的子版本的分支。
保留在一个提交上的就是标签。
HEAD指示工作目录的位置，所以每次提交或检出时都会移动。
“合并提交是什么意思?”
提交指向其父节点。
你什么时候开始误以为只有一个父母？
一次提交可以指向两位父亲，也就是说有这样的情况。
コミット11 ＼ ←親が2人！
コミット33
コミット22 ／
这个……
コミット10 ← コミット11 ＼ ←親が2人！
コミット33
コミット20 ← コミット22 ／
这样……
コミット00 ←コミット10 ← コミット11 ＼ ←親が2人！
＼ コミット33
＼コミット20 ← コミット22 ／
这是合并了
如果根据日志进行追踪后分成两部分，那么说明在那里进行了合并。
请在其他地方找一下关于解决冲突之类高级话题的相关资料。
用 “git reset HEAD^” 命令可以将提交的内容还原到以前的状态，就好像这个提交从未存在过一样。
我经常看到这个解说，但是由于理解很困难，所以我不喜欢。
git reset HEAD^ 不等于 把提交恢复为未曾存在的命令。
最终结果是没有提交，而不是一个能使之成为不存在的命令。
就像前面所写的那样，git的commit结构体中含有父提交的ID。通过追踪这个ID，就可以显示提交的历史记录。就是这个意思。
コミット1 ←(親を指し示す)コミット2 ← コミット3
↑HEADです
在这种情况下，我们想要撤销提交3。
虽然从”git reset HEAD^”这个命令中，若仅从”reset”这个词来看可能不太理解，但更准确的翻译应该是”重新设置（Re-Set）”。
根据字面意思，就是将[HEAD]重新设置为[HEAD^]（即HEAD的父提交）。
这样做会有什么结果呢……
コミット1 ←(親を指し示す)コミット2 ← コミット3
↑HEADです
当你查看 git log 时，你会这样看到。这就是全部了。
コミット1 ←(親を指し示す)コミット2
↑HEADです
是这样的。
正如上面提到的，git log会按照”从HEAD开始依次追溯父节点”的方式进行显示，
因此无法从HEAD追溯到的提交3就消失了。
因此，无法再追溯到提交3，
所以提交3被成功撤销了！
提交3当然还存在，但并没有任何链接指向它，只是在宇宙空间中漂浮着。
如果直接将HEAD与提交3的ID连接起来，就可以回到最初的状态。
改写这个提交？
git 提交 –修改
git 变基 branch-xxx
git 合并 –压缩
有很多指令被称为修改提交的命令。
但是，提交在创建后不是一个不变的存在吗？
把这个东西这样这样做。
コミット11 - コミット22 - コミット33 - コミット44 - コミット55
↑HEAD&master
修改了提交55的commit
コミット11 - コミット22 - コミット33 - コミット44 - コミット55
＼コミット55を書き換えたものでござる
↑HEAD&master
提交历史
コミット11 - コミット22 - コミット33 - コミット44 - コミット55を書き換えたものでござる
↑HEAD&master
這就是這樣的。
这是什么意思？
“没有参考方法的“提交55”不会在日志中显示吧？”
在应用中，可以在进行rebase等操作之前创建并叠加一个分支，这样可以保留之前的分支并进行rebase操作。
就是说，git
- 無数の「コミット」という名のかたまりが、それぞれ他の「コミット」を指し示しているだけの空間
在实际使用git时，
- 「コミット」を作ったり、「コミット」を指定しているタグ(タグだったりHEADだったりブランチだったり)をつけたり外したり動かしたりして運用する
听起来非常简单，也很有趣。
创建一次提交后，提交本身将永久且唯一存在（太好了，那怕是GC们在清理）。但是，你可以通过更改引用该提交的标签来撤销提交，或者创建将多个提交合并为一个的提交等等，你可以非常自由地进行操作。
因此，实际运用时，我认为你可以像按Ctrl+S（保存）一样，大量提交。反正后面可以自由修改。由于储藏只是一个普通的提交，所以我认为你可以使用储藏，也可以使用提交。两种方法都可以。
已提交的内容大多数情况下都可以提取出来，但未提交的内容一旦消失就完全消失了，所以请注意这一点。
结束
虽然最后只谈论了一些低级的话题，但我已经理解了git的基本原理，所以接下来将会更加有趣。请再次指出我的任何错误之处，谢谢。
