【Git初学者】总结了Git出错时的应对方法

因为我是初学者，所以经常在Git上出错。
我总结了针对失误情况的不同应对方式和案例。

经常做得很好的等级1：那些经常做的人。

由于经常犯错，对此我已经相当习惯了。

情景1：不小心执行了git add命令

% git reset HEAD .
Unstaged changes after reset:
M   app/path/file.php

如果想要取消多个文件中特定文件的暂存（add）操作，只需将当前路径更改为文件的路径。
顺便一提，HEAD是最新提交的哈希别名。
例如，执行git push origin HEAD实际上是将最新的HEAD推送到远程仓库。

顺便提一下，git add后和撤销后的状态区别如下：
＜已添加的状态＞

% git status
On branch feature/update_bootstrap
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   app/config/bootstrap.php

＜撤销添加后＞

% git status
On branch feature/update_bootstrap
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   app/config/bootstrap.php

情况2：不小心执行了git commit。

由于想要从历史上抹去相关内容，一般使用如下选项。

git reset --soft HEAD^

若要撤销已添加到暂存区的文件，可以使用指定选项来进行条件分支，类似于只取消某个文件的add操作。

场景3：提交了错误的git commit内容

git commit --amend

如果想要覆盖当前的工作树内容并同时更改提交信息的话，请参考以下选项：

修改现有工作树并更改提交讯息至：

git commit --amend -m "<コミットメッセージ>"

情景4：不小心执行了git push

首先，将本地索引状态回到HEAD，并将该状态推送。
在推送时，为了避免错误，添加选项。

git reset --hard HEAD
git push -f origin HEAD

情景5：我把分行的名称弄错了。

更改本地分支的名称

git branch -m <ブランチ名（変更前）> <ブランチ名（変更後）>

如果错误地推送了错误的分支名称，就删除错误名称的远程分支，并重新推送到正确的分支上。

git push origin :<ブランチ名>

如果不小心在一个错误的远程分支上进行了多次更改，应该怎么办呢？我想先拉取到本地，然后在本地更改分支名后再次推送吧？可能还有比上述方法更方便的解决办法（如果遇到这种情况就去查一下）。

经常能做到的水平-偶尔出错后会有点气馁的人

我在逐渐熟悉使用git时，克服了一些困难。（有过不能克服而丢失几个小时工作的经历）

情况1: 我不小心把分支推错了。

我希望将在正确的分支上工作的内容反映到本地分支上，直到提交到正确的分支为止。修正错误的推送是不必要的情况。

//push先を指定
git branch --set-upstream-to=origin/<ブランチ名>
git push

情境2：当进行推送操作后，文件的大小变得很大并导致错误，而且在没有察觉到这个问题的情况下继续在本地进行工作。

需要重新从提交开始，但需要进行不包含本地操作的提交，一旦推送完成，我想将本地操作恢复并推送，这就是我们的情况。

我最初考虑的作业流程如下，但只需要一个选项：

1.今のワーキングツリーを退避：git stash
2.リポジトリの巻き戻し：git reset --soft HEAD^
3.git reset HEAD サイズが大きいファイルのパス
4.該当ファイルを.gitignoreに記載 <-記載するとファイルがコミット対象ではなくなるが実は不要な手順
5.再びコミット
6.再びプッシュ
7.退避したスタッシュを適用：git stash apply
8.再びコミット
9.再びプッシュ

4.不需要，原因是因为从3开始已经将其排除在外。
如果执行4，则可以顺利进行到6，但在7时，由于.gitignore的状态不同，恢复存储时会出现冲突并导致错误。
另外，在执行8之前，我曾困惑是否需要add，但由于执行git stash apply后，已经处于已添加的状态，因此是不必要的要点。

难度较高的级别三：极少发生的灾害级别（人为灾害）

情况一：Git的行为完全出现了问题。

无论做什么或不做任何操作，与git相关的行为都会变得异常，这种情况是无法正常考虑的。我认为这就是所谓的”仓库损坏”状态，但损坏肯定有原因…因此，下面总结了发生事件的整理工作，原因的调查以及针对调查结果所采取的措施。

我当时真的觉得处理Git太难了（原因并不是Git问题）。