Git でよくある 10 の状況

You are currently viewing Git でよくある 10 の状況

Git でよくある 10 の状況

状況 1: 競合の処理

チームで作業する場合、コードの競合は避けられません。これは、2 人のメンバーが同じモジュールでタスクを実行するときによく発生します。競合がいつ発生するか、そしてその解決方法を見てみましょう

最初に、dev ブランチで、Teo と Ti は 2 つの異なるブランチをチェックアウトし、Teo はブランチをチェックアウトしcreate-user、Ti はブランチをチェックアウトしview-user、Teo と Ti は一緒にファイルの最初の行を次のように編集します。user.js

次に、Teo はブランチをcreate-userdev ブランチにマージします。これで、Ti がブランチをview-userdev ブランチにマージするまではすべて問題なく動作します。ブーム。マージできずエラーが表示されるCONFLICT (content): Merge conflict in user.js

この問題を解決する方法は、競合したブランチを持つ人がそれを処理することですが、ここでは、Ti のブランチである Ti は、コードの競合に関連するメンバーと話し合って、次の手順を実行する必要があります。

1. 競合するコードを特定します。

git status競合するファイルを見つけるために使用します

user.js ファイルには、次の内容が表示されます。

<<<<<<< HEAD
code of Tèo
======= 
code of Tí
>>>>>>> view-user

2. 紛争の解決:

Teo と話し合って、どのブランチのコードを保持するか、両方を結合するかを決定してから、<<<<<<<、=======、および >>>>>>> を削除します。

git add user.jsandコマンドを使用してgit commitマージプロセスを完了します

3. もう一度確認してリモートにプッシュします。

次を使用して、競合が正常に解決されたかどうかを確認しますgit status

次に、それを使用してgit push、マージされた変更をリモートにプッシュします。

注: コードの競合を制限するには、定期的にコードをプルし、コードをコミットする必要があります。

状況 2: git でコミット履歴とアクティビティ履歴を表示する

git logコミットハッシュ、コミッター、コミット時間、コミットメッセージなどのコミット履歴を表示するために使用します

commit 7a2cbffba6023df7f37dd1808f46d5a6b59d810b
Author: teo <teo@gmail.com>
Date:   Fri Feb 11 10:05:00 2024 +0700

    Create log

git reflogアクティビティ履歴として、git 上で実行されたアクティビティを保存するのに役立ちます。たとえば、Teo は master ブランチを通じてチェックアウトしたばかり、Ti はコミットをリセットしたばかりなど、git reflog使用中の間違いに非常に役立ちます。状況の間違い 4)

2de6d93 (view-user) HEAD@{11}: checkout: moving from view_user to master
6303151 (create-user) HEAD@{12}: reset: moving to HEAD@{3}

状況 3: コミットを削除する

タスクに取り組む長い一日、Teo はついにタスクを完了し、Teo はコードをコミットして眠りに就きました。

翌日、Teo が再度コードを開いたところ、コードがまったく問題ないことがわかりました。Teo はすべてのコードを削除するか、コードを再度編集する必要がありました。git resetTeo はこの問題を解決するためにまたはを使用できますgit revert(ここでは を紹介しますgit reset)

Git リセットには、mixed(オプションが渡されない場合のデフォルト) などのいくつかのオプションがあります--soft。--hard

  • git reset <commit>: コミットされた変更をステージングに保持します
  • git reset --soft <commit>: 作業ディレクトリに変更を保持します
  • git reset --hard <commit>: 作業ディレクトリとステージングの両方ですべての変更を破棄します。

状況 4: コミットを復元する

状況 3 と同様に、Teo はコードを編集するためにコミットをリセットしようとしましたが、Teo が誤ってコミットを使用してしまい、--hardコードが消えてしまいました。Teo は混乱してリーダーに助けを求めました。リーダーは Teo に次の操作でコードを取り戻すように指示しました。後：

  1. コミットハッシュを取得するために使用しますgit reflog。
627f5d1 (HEAD -> master, conflict-2) HEAD@{0}: reset: moving to 627f5d161bff441840d5b34a77abe16561f505f8
ec02ce2 HEAD@{1}: reset: moving to HEAD@{1}
  1. コミットを復元するために使用しますgit reset --hard。
git reset --hard ec02ce2

テオは喜んで応援し、リーダーに感謝しました

状況 5: 複数のコミットを 1 つのコミットにマージする

Ti には、CRUD を含むユーザーを管理するタスクが割り当てられました。私はリーダーのアドバイスに耳を傾けました。「コードは継続的にコミットする必要があります。」

Ti はファイル userRouter を作成し、Ti はコミットします

userController ファイルの作成を続け、コミットを続けます

Ti は userService ファイルを作成し、Ti はコミットを継続します

私はタスクを完了し、喜んでリーダーにコードをレビューしてもらいました。リーダーはプル リクエストを見て、「コミットを 1 つに結合させてください。継続的にコミットする必要がありますが、合理的なコミットを行う必要があり、回避する必要があります」と言いました。冗長性または重複が多すぎる」

ティはもがきながら頭の中でこう考えた。「それで、私はこれから何をすべきだろう？」

リーダーは、次のように Ti にコミットをマージするよう指示し続けます。

  1. gitリベースを使用する
git rebase -i HEAD^n
(n là số commit muốn gộp)
  1. pickGit は対話型ウィンドウを開き、マージしsquashて保存するコミットを選択します。
  2. Git は引き続き対話型ウィンドウを開き、メッセージを選択するか、任意のコミット メッセージを入力して保存します。終わり

シナリオ 6: コミット メッセージを編集する

ある時、Ti が間違ったメッセージをコミットし、Ti がそのメッセージを編集しました。Ti はとても嬉しかったので、Ti はすぐにフォーラムで共有しました Ti の処理方法は次のとおりです。

最新のメッセージの場合: を使用しますgit commit --amend -m "new_message"(最新のコミットのメッセージのみ変更できます)

同時に複数のメッセージの場合は、古いメッセージでも新しいメッセージでも問題ありません。

  1. 使用しますgit rebase -i HEAD~n(n はメッセージを変更するコミットの数です)
  2. Git は対話型ウィンドウを開き、変更したいコミットpickに変更して保存できます。reword
  3. Git はインタラクティブ ウィンドウを開き続けます。新しいメッセージを変更して保存すると、変更したいコミットの数と同じだけ、メッセージを変更するためのインタラクティブ ウィンドウが開きます。

状況 7: ブランチの名前を変更する

またある時は、Ti がブランチの名前を間違え、Ti がブランチ名を修正しました。Ti はとても喜んで、Ti はすぐにフォーラム X でそれを共有しました。著者 (私) はたまたま Ti の共有投稿を見たので、ここにコピーして貼り付けました。Ti の処理方法は次のとおりです。

ブランチ名が間違っている場合は、次のコマンドを入力してください。git branch -m new_branch

状況 8: 別の支店経由でチェックアウトできない

Ti と Teo は A Bo Co 社の 2 人のインターンで、Ti は Teo の 2 日前に入社しました。

ある日、Teo はブランチでコーディングしていましたauthが、Teo のブランチが Ti のブランチに依存していたため、Ti のブランチを熱心にチェックアウトしてuserTi のコードがどこにあるかを確認しました。

Teo がコマンドgit checkout user「BOOM」を入力しましたが、チェックアウトに失敗し、このエラーが表示されましたerror: Your local changes to the following files would be overwritten by checkout: auth.js Please commit your changes or stash them before you switch branches. Aborting

テオは混乱し、テオはティに尋ねようとした。なぜなら、ティはテオの2日前に働いていたので、ティは対処方法を知っているだろうと思ったからである。

Ti はエラーを見て、「何か問題があるはずです。コードをすべて削除してみてください。」と言いました。隣にいたリーダーは驚いたので、振り返って、まだこの人生を経験していない二人の子供たちに対処しなければなりませんでした。

リーダー氏は、「Teo が現在のブランチで不適切なコーディングを行っているため、別のブランチにチェックアウトできません。Teo が別のブランチにチェックアウトできるようにするには、最初にコードをコミットする必要があります。」

Teo は、「まだコーディングが終わっていないので、コードをコミットしたくないです。」と答えました。

リーダー氏は続けて「分かった、じゃあ私のために使ってください。git stash」

git stashコードを一時的に保存し、再び開発に戻ったときに使用するのに役立ちますgit stash pop

状況 9: マージ前の状態を復元する

誰もが間違いを犯すでしょう、そしてリーダーも間違いを犯します

リーダーは Ti にタスクを割り当て、Ti がそれを完了した後、リーダーはそれを開発ブランチにマージしました。

マージ後、リーダー氏はコードが期待どおりに機能しないことに気づきました。そこでリーダーは次のコマンドを使用して、git reset --hard ORIG_HEADマージされたコミットを削除し、Ti にコードを編集するように指示しました。

状況 10: コミットを別のブランチにマージする

テオは製品管理の任務を割り当てられました

Teo は製品作成機能を完了し、Teo はコミットします

Teo は製品ビュー機能を完了し、Teo はコミットしました

Teo は製品アップデート機能を完了し、Teo はコミットしました

Teo は製品の削除機能に取り組んでいますが、Teo はまだコミットしていません…

このとき、顧客はリーダーに「プロダクトの作成とプロダクトの表示機能を至急リリースしてほしい」と電話をかけてきました。

リーダー氏は、予期せぬリクエストを行う顧客に精通しているため、すぐにコマンドを使用してgit cherry-pick <commit>これら 2 つのコミットをメイン ブランチにマージし、顧客にリリースしました。

git cherry-pickこれは、ブランチ全体ではなく、任意のコミットを別のブランチにマージしたい場合に便利な git コマンドです (git Cherry-pick は競合することがよくありますが、このコマンドを使用するとgit add .処理git commit -m “message”できます)。

終わり

そこで、 Git でよくある 10 の状況を調べました。この記事があなたに価値をもたらし、git についてより深く理解するのに役立つことを願っています。さらに、「プロジェクトに役立つ 15 の git コマンドの概要」という記事があります。これを読んで git について詳しく学ぶことができます。読んでくれてありがとう

出典 : https://viblo.asia/p/10-tinh-huong-thuong-gap-trong-git-yZjJYgPOVOE

Please follow and like us:
fb-share-icon
Tweet
Pin Share

コメントを残す