advanced git commands
このチュートリアルでは、Git Stash、Git Reset、Git Cherry Pick、Git Bisectなどの便利なGitコマンドについて説明し、GitHubをJiraと統合する方法について説明します。
このシリーズの以前のチュートリアルでは、GitHubのほとんどの機能を見てきました。
このチュートリアルでは、以下を見ていきます。
- リリースの作成
- AtlassianJiraとの統合
- 開発者向けに最も一般的に使用されるGitコマンド
- Git Stash
- Git Cherry Pick
- Gitリセット
- Git Bisect
qaテストリードインタビューの質問と回答
学習内容：
リリースの作成
GitHubのリリースは、ソフトウェアをバンドルし、リリースノートとバイナリ（WAR、EAR、JARファイル）を追加して、顧客と人々が同じものを使用できるようにするために使用されます。
リリースを作成するには、リポジトリのメインページに移動し、 リリース 下のタブ トピックを管理します。
クリック 新しいリリースを作成します。
タグとリリースタイトルを提供します。バイナリもリリースに追加されます。完了したら、をクリックします リリースを公開します。
これで、ソースコードとバイナリを使用してリリースの準備が整いました。
GitHubとJiraの統合
重要なトレーサビリティの側面の1つは、GitHubのコミットでJiraの問題を参照することです。 GitHubをJiraと統合して、問題を参照するだけでなく、Jira内からブランチやプルリクエストを作成することもできます。
したがって、通常、開発者がタスクまたはバグの作業を開始すると、開発者によってブランチが作成されます。開発を投稿するか、バグを解決するために、Jiraからプルリクエストを作成してメインにマージできます 主人 ブランチ。その後、開発者が作成したブランチを削除できます。
統合を設定するために、プラグインを使用しました JiraのGit統合。 これは商用プラグインです。プラグインはからダウンロードできます ここに
からJiraにプラグインをインストールします 管理者->アドオン。
プラグインがインストールされたら、 アプリケーション-> Gitリポジトリ GitHubに接続します。
GitHubのユーザー名とパスワードを入力します。クリック 接続する 。
ユーザーアカウントに記載されているリポジトリが表示されます。クリック リポジトリのインポート 統合のセットアップを完了します。
GitHubがJiraの問題に取り組む
コミットメッセージの一部として、以下に示すように入力します。クリック 変更をコミットする 。
例1： 以下はの例です スマートコミット これにより、開発者はコミットメッセージからJiraの問題に対してアクションを実行できます。そのようなコマンドの1つは ＃コメント 以下に示すように、JiraIssueにコメントを追加するIssueキーとともに。
コメントセクションが更新されました。
例2： ユーザーに割り当て、4時間として費やされた時間を更新します。
使用 ＃割当 そして ＃時間 コミットメッセージ内のスマートコミットコマンド。
両方のアクションが完了しました。
例3： 問題のステータスをに変更します 進行中 。
ブランチを作成する
タスクとバグが開発者に割り当てられると、開発者は開発に取り掛かる必要があります。このために、彼らは取り組んでいる問題のブランチを作成し、開発アクティビティを実行し、マスターブランチにマージするためのプルリクエストを発生させます。
下部にあるJiraの問題で、 ブランチを作成します。
クリック ブランチを作成します。
GitHubで、上記で作成したブランチのファイルに変更を加え、同じものをコミットします。
開発が完了すると、ユーザーはJiraからプルリクエストを発行できます。
問題の下部にあるをクリックします プルリクエストを作成します。
クリック 作成します。プルリクエストはオープンとして表示されます。
次のステップは、GitHubでプルリクエストをマージすることです。
それに応じて、Jiraでステータスが更新されます。
開発者向けの高度なGitコマンド
この最後のセクションでは、開発者が一般的に使用するGitコマンドのいくつかを見ていきます。 GitHubとは何の関係もありませんが、開発者が変更をGitHubにプッシュする前に支援します。
Git Stash
新しい機能や拡張機能に取り組んでいるほとんどのプロジェクトシナリオでは、突然、報告されたショーストッパーである緊急の欠陥に取り組む必要があります。新しい作業の途中で完了していないため、半分完了した変更をコミットしても意味がありません。
したがって、途中で完了した作業を一時的に一時停止または保存し、バグに取り組み、新しい機能または拡張機能に戻って作業することをお勧めします。 Git stashは、これに対する解決策を提供します。変更を行うコンテキストをすばやく簡単に切り替えることができます。
例1 ：自分に割り当てられたタスクに取り組んでいると仮定し、ステータスを見ると、現時点では追跡されていないことが示されています。
突然、優先度の高いバグが割り当てられました。したがって、現在作業中の作業を一時的に保存または隠しておく必要があります。
次のコマンドを実行します。
git stashsave「メッセージ」
この時点で、作業ディレクトリはクリーンです。新しいコミットを行うことができ、バグがある場合は、ブランチを切り替えて作業することができます。
残した変更を再適用する場合は、コマンドを使用します。
git stash pop
上記のコマンドは、リストからスタッシュを削除し、最後に保存された状態を適用します。
次のものも使用できます。
git stash apply
上記のコマンドは、変更をスタッシュに保持し、削除しません。
これで変更が再適用され、変更をコミットできます。
例2： 変更を隠し、ブランチを切り替え、変更をマージします。
のHtmlファイルに変更を加えます 主人 ブランチとスタッシュの変更。
次はに切り替えることです バグ 分岐し、変更を加え、変更をコミットします。
git checkout-bバグ
Htmlファイルに変更を加えます。
git commit -a-m「修正された電子メールの問題」
に切り替えます 主人 stashから変更を分岐して再適用します。
今からマージします バグ に分岐します 主人 ブランチ。マージ後に変更をコミットします。
例3： 複数のスタッシュの操作。
ローカルリポジトリには、2つのHtmlファイルがあります。したがって、複数の開発者が複数のファイルで作業し、必要に応じて変更を隠して、変更を修正するためにやってくる緊急の要求に取り組む可能性があります。
開発者1はhello.htmlで動作し、開発者2はindex.htmlで動作します。
開発者1
スタッシュリストには現在1つのエントリがあります。
開発者2
スタッシュリストに2つのエントリが追加されました。最新のスタッシュは、スタックの最初のstash @ {0}です。これで、両方の開発者が他のコミットを緊急に実行するか、他のブランチで作業してから、 主人 分岐して、スタッシュの変更を適用します。
最新のスタッシュを適用するには、実行するだけです
git stash pop
スタックに特定のスタッシュを適用するには、次のコマンドを実行します。
git stash pop stash @ {1}
2番目の隠し場所を適用しましょう stash @ {1}
同様に、他の隠し場所を適用することができます。
Git Cherry Pick
今日、開発者は機能、拡張機能、バグなどの複数のブランチに取り組んでいます。
いくつかの特定のコミットのみを選択する必要があり、ブランチ全体を別のブランチにマージしない場合があります。これはチェリーピックと呼ばれます。このプロセスにより、他のブランチから任意のGitコミットを選択し、それを作業ツリーの現在のHEADに追加できます。
例1：
ローカルのgitリポジトリには、次の6つのファイルがあります。
file5.txtなどの1つのファイルが削除されます。
変更をコミットします。
今すぐログを見てください。 File5.txtが削除されます。
したがって、file5.txtを追加したコミットをチェリーピックします。 file5.txのコミットIDを見つけて、コマンドを実行する必要があります。
gitチェリーピック
この場合、file5.txtが追加されたときのコミットIDは a2f0124
File5.txtが復元されました。私たちはコミットをチェリーピックしました。
例2：
変更してみましょう file6.txt で変更をコミットします 主人 ブランチ。
の2行目を見てください file6.txt メールが正しく指定されていない場合。
バグブランチを作成し、問題を修正します。同時に、file5.txtも変更して、バグブランチで複数のコミットが実行されるようにしますが、file6.txtで実行されたコミットのみをCherry-Pickします。
File6はで変更されました バグ ブランチ。
したがって、全体として、 file5およびfile6 バグブランチで。
に戻ってみましょう 主人 ブランチとチェリー-file6.txtに対してのみ行われたコミットを選択します。
ご覧のとおり、マージする代わりに バグ に分岐します 主人 ブランチでは、特定のコミットのみをチェリーピックしてマスターブランチに適用しました。
Gitリセット
Gitリセットは、ローカルの変更を元に戻すための強力なコマンドです。したがって、ステージングを解除するには、このコマンドが使用されるすべてのステージングされたファイル。
例
ファイルを変更して、ステージングに追加します。ステージングされた変更がステージングされていない場合に示されているように、コマンドを使用してリセットします。
のパラメータ gitリセット コマンド。
-柔らかい： このパラメーターは、HEADを別のコミットにポイントします。すべてのファイルは元のHEAD間で変更され、コミットがステージングされます。作業ディレクトリはそのままです。
現在のHEADの場所を見てください。
履歴の5つのコミットに戻りましょう。
変更を再コミットします。
–混合： このオプションは、softパラメーターに似ています。通常、悪いコミットがある場合は、それらを削除して後で修正し、コミットし直します。したがって、基本的に、を使用してインデックスに追加する必要があります git add その後 gitcommit。 変更は作業ツリーに残されます。
履歴の2つのコミットに戻り、ファイルが追跡されていないことを確認しましょう。
次に、ファイルをステージングに追加し、変更をコミットします。
-ハード： このパラメーターは、特定のファイルが存在するポイントまで残ります。変更は作業ツリーでは利用できません。
上記のログを見ると、ファイル1のみがコミットされたポイント、つまり最後のエントリに戻ることができます。
使用する git reset –hard
Git Bisect
コードを壊した正確なコミットを見つけてください（結局のところ、私たちはすべて人間です）。多くの場合、アプリケーションのテスト中に、バグがあるか機能が壊れているとテスターから聞いています。開発者としてのあなたは先週それが機能したと言うでしょう。では、何が起こったのでしょうか。なぜこのバグが発生したのでしょうか。
他のコードの変更が機能に影響を与える場合があります。時間がかかり、どの変更がコードの破損を引き起こしたかを追跡するのが難しいコミットがたくさんある履歴を調べるのに時間を費やす必要があります。
Git Bisect バグが発生したときの正確なコミットを見つけるコマンドです。 Gitバイセクトでは、良いコミットと悪いコミットの2つのコミットを選択する必要があります。両方のコミットの約半分がチェックアウトされます。バグまたはコードの破損の原因となったコミットが見つかるまで、各コミットを不良または良好のいずれかでチェックします。
例：
- 新しいローカルgitリポジトリを作成し、index.htmlというファイルを作成します
- 示されているファイルの初期内容。
- ステージングに追加し、リポジトリにコミットします。
- 図のようにコミットの履歴を作成して、良いコミットと悪いコミットのどちらかを選択できるようにします。ここで、最初のコミットが完了したら、示されているように他の変更を行い、同じようにコミットします。全体として、7つのコミットを実行します。
2番目の変更
3番目の変更
4番目の変更
5番目の変更
6番目の変更
7番目の変更
ここでやめましょう。したがって、7つのコミットがあります。
Htmlページを見ると、「4つのイベントすべて…」の後の行が間違っているため、ドキュメントが正しくありません。したがって、エラーが発生したコミットを見つけて、そのコミットに頭を置くことができるようにする必要があります。
ログを見て、 悪い そして 良いコミット。
最新のコミットは正しくないため、悪いコミットになる可能性があります。コミットは3回目のコミットの後に導入されたため、 3番目の変更 良いコミットとして。
二等分するプロセスは git bisect start そしてで終わる gitbisectリセット。
git bisect bad //最新のコミットが悪いので。コミットIDを指定する必要はありません。
git bisect good
これで、HEADが悪いコミットと良いコミットの半分の間にあることがわかります。
index.htmlのコンテンツを見て、適切なコミットがあるかどうかを確認します。そうでない場合でも、エラーは見つかりません。
エラーがまだ存在しているわけではありません。最後の行が間違っています。だから、私たちは「 git bisect bad ’。 まだ悪いコミットがあり、現在のコンテンツは受け入れられません。
上記の内容は正しく、許容範囲内です。
「gitlog–oneline」と「gitbisectgood」を実行します。
だから、 5番目の変更 最初の悪いコミットでした、そして本当にそうです。エラーが識別されます。
現在の内容は、最終的なドキュメントに含まれている必要があります。
不正なコミットが特定されたら、最後の良好なコミットである4番目の変更にヘッドをリセットする可能性のある変更を修正するように開発者に通知できます。
実行 ‘ gitbisectリセット ’を使用してプロセスを終了します。
結論
このGitHubハンズオン入門書では、開発者が作業する必要があるすべてのこと、つまりバージョン管理と追跡の観点から説明しようとしました。
GitHubシリーズの最初の3つのチュートリアルでは、バージョン管理アクティビティ、リポジトリの作成、プルリクエスト、ブランチ、コードレビュー、組織とチーム、リポジトリのフォーク、ラベル、マイルストーン、問題、プロジェクトボード、Wiki、リリース、統合について学習しました。 Jiraと開発者向けに一般的に使用されるいくつかのGitコマンドを使用します。
すべての開発者が、GitHubとGitコマンドのこの実践的なアプローチがプロジェクトで役立つことを心から願っています。
=> EasyGitHubトレーニングシリーズをお読みください。