回答編集履歴
2
追記。最初からやり直してはどうか
test
CHANGED
|
@@ -1,3 +1,5 @@
|
|
|
1
|
+
### \#1
|
|
2
|
+
|
|
1
3
|
エラーメッセージをよく読みましょう。意味もなく何行もメッセージがでているわけではありません。
|
|
2
4
|
```
|
|
3
5
|
% git push -u origin main
|
|
@@ -25,3 +27,22 @@
|
|
|
25
27
|
|
|
26
28
|
つまり、まず`git pull`を実行 (競合が起こりうるのなら`git pull --rebase`のほうがよいでしょう) してから、改めて`git push`すればよいでしょう。
|
|
27
29
|
|
|
30
|
+
### \#2
|
|
31
|
+
|
|
32
|
+
```
|
|
33
|
+
% git pull origin main
|
|
34
|
+
From https://github.com/○○/○○.git
|
|
35
|
+
* branch main -> FETCH_HEAD
|
|
36
|
+
fatal: refusing to merge unrelated histories
|
|
37
|
+
```
|
|
38
|
+
`git pull`はリモートの履歴を取り込みますが、ここでは何か全く関係ない履歴を取り込もうとしているという理由で拒否されていますね。
|
|
39
|
+
|
|
40
|
+
いろいろいじくり回しているうちに、リモートブランチを関係ないローカルブランチのオリジンにしてしまっているのでしょう。
|
|
41
|
+
|
|
42
|
+
最初のエラーメッセージが出た時点で \#1 で述べたように`git pull`を実行していればよかったのですが、こんなことになってしまっては質問者さんの作業スペースがどうなっているのかはもはやだれにもわかりません。素直に最初から作業をやり直すのがいいと思います。つまり、次のとおりです。
|
|
43
|
+
|
|
44
|
+
1. 現在のローカルブランチはとりあえず退避する (作業スペースのディレクトリをリネームする)。
|
|
45
|
+
2. リモートブランチのクローンを作り直す。
|
|
46
|
+
3. 修正作業をやり直す。1. で退避したものと見比べて修正をする。出来上がったものをコミットする。
|
|
47
|
+
4. リモートにpushする。問題が起きたらヒントに従って対応。
|
|
48
|
+
|
1
typo
test
CHANGED
|
@@ -21,9 +21,7 @@
|
|
|
21
21
|
> 更新は拒否された。理由は、お前の現在のブランチの先頭が相手のリモートブランチより遅れているからだ。リモートの変更を取り入れたければ、pushする前に「`git pull`」を実行しろ。
|
|
22
22
|
> 詳しいことは「`git push --help`」の中の「Note about fast-forwards」を読め。
|
|
23
23
|
|
|
24
|
-
つまり、質問者さんが自分のクローン上で作業している間に他の人の新たなコミットがリモートブランチに追加され
|
|
25
|
-
|
|
26
|
-
なぜorigin/mainへの強制`push`やorigin/mainの`merge`をしようと考えついたのか知りませんが、ヒントに書いてある通りにするのがよいのではないですか。
|
|
24
|
+
つまり、質問者さんが自分のクローン上で作業している間に他の人の新たなコミットがリモートブランチに追加されたので、このままでは質問者さんが新たなコミットをリモートブランチに追加できません。追加できるようにするにはリモートブランチの新たなコミットを取り込む必要があります。そのためのコマンドはgit pullです。なぜorigin/mainへの強制`push`やorigin/mainの`merge`をしようと考えついたのか知りませんが、ヒントに書いてある通りにするのがよいのではないですか。
|
|
27
25
|
|
|
28
26
|
つまり、まず`git pull`を実行 (競合が起こりうるのなら`git pull --rebase`のほうがよいでしょう) してから、改めて`git push`すればよいでしょう。
|
|
29
27
|
|