Git Rebase

rebaseを使用すると、merge commitを作成せずに最新のHEADの後にコミット内容を順次貼り付けることができます.
しばらくcommitを回して、再起動させます.

git reset --hard HEAD~

ログの表示

board.txtに戻る前に表示されます.
sourceTreeでマージを行うと、マージプロセスがない場合が表示されます.
(従来、mainはloginブランチに従っていたため、boardブランチの内容をマージする際に競合し、boardブランチをbaseに戻し、順次フォローさせる)
ローカルで作業している場合は、通常、履歴を再作成してクリーンアップします.
遠隔地などに押さないで、基地を作ってください.
更新の瞬間に前のcommitをすべて解決する必要がある場合があるので、もう一度考えて書くことをお勧めします.

コードビュー(GitHub Pull Request)

コードコメント
:1人以上の開発者がコードを記述していない内容をチェックし、フィードバックを提供するプロセス
フィードバックは、エラー、エラーの可能性、開発基準などの意見であってもよいし、良いコードに対する積極的なフィードバックであってもよい.
メリットは次のとおりです.
1.エラーの早期発見
2.開発基準を遵守する
3.コードの重複を避け、モジュールの再利用性を高める
Pull Request
:変更したコードを異なる人がどのようにコメントするか
(コードコメントに類似)
通常、コードコメントは主に新しいブランチを通じてコードコメントを作成します.

qnaブランチの作成、ファイルの作成、コミット

pushは、今回もローカルでしか作成されないため、エラーを引き起こします.
同じプロンプトのコードをコピーして貼り付けて実行すればいいです.

ネットで見ると、よく見えます.

Pull Requestを見て
1分前にqnaが作成されたことを示し、「New Pull request」をクリックします.

「create pull request」をクリックします.

メールの作成

確認できます.

file changedを表示すると、ファイルがどのように変更されたかが表示されます.
このファイルは空なので、Empty fileというファイルが見えます.
ファイルがよく追加されているだけを見て

a.txtを変更しrm boardを使用します.txtを削除

add . すべての変更を追跡してコミットする

a.txtでB文を削除し、C文を追加
変更マークがよくできています.
ここでコメントすると?

該当するコードにマウスを置くと、+記号が表示され、クリックしてコメントすればいいです.

このような方法で?

コメントを書いた.