高度なGitワークフローと使用法

最近、プロジェクトでソース管理にGitを使用するための基本を確認しました。 これは素晴らしい出発点ですが、日常のコーディング作業でGitを使用して頭を悩ませるのに役立つ他のコマンドやGitワークフローがたくさんあります。

Gitワークフロー

Gitを使い始めたとき、Gitの正しい使い方を知っていると思いました。 私の理想的なアプローチは、ブランチなしですべての変更を1つの場所で行い、それらをリポジトリにコミットして作業を続けることでした。

バージョン管理を使用しないよりはましでしたが、Gitが提供するパワーのほとんどを使用していないことに気付くのに少し時間がかかりました。 Gitを機能させるには、変更を分岐してマージする戦略が必要でした。

それからgit-flowが出てきて、それを戦略として採用しました。 素晴らしい開発者がいた場所にカーテンの後ろを覗いていたような気がしたのを今でも覚えています。 私は今、それらがどのように機能するかについて洞察を得て、それらの1つになり始めることができました。

ただし、git-flowはすべてのシナリオに適合するわけではないため、これから見ていく中で、Gitプロジェクトを整理しておくための他のいくつかの方法についても見ていきます。これには、私が単独の開発者としてプロジェクトを管理する方法も含まれます。

git-flow

今git-flowを見ると、ソフトウェアの状況は10年間で大きく変化しており、git-flowはチームにとって最良の選択肢ではない可能性があることを認識しています。 git-flowが作成されたとき、1日に何度もアプリケーションをデプロイすることはめったにありませんでした。 代わりに、特にアジャイルチームに所属している場合は、おそらくメジャーバージョン番号を作成し、数か月または数週間ごとにリリースします。

git-flowとは何かを見てみましょう。

Git FlowのチャートとGitコマンドを使用した完全な詳細な説明を確認したい場合は、この投稿をお読みください。

git-flowでは、2つのブランチの有効期間は無限です。 まず、メインは、ライブ/本番環境にデプロイする準備ができているコードを反映する必要があります。

次に、開発ブランチがあります。 このブランチには、ソフトウェアの次のリリースに備えた最新の変更が含まれている必要があります。 開発の変更をライブアプリケーションにデプロイする準備ができたら、それらをメインブランチにマージし、リリース番号に対応するバージョン番号でタグ付けします。

2つの主要なブランチのほかに、3つのタイプのサポートブランチがあります。

1.機能

機能ブランチは、開発ブランチからのみ作成できます。 開発ブランチにマージして戻す必要があります。 ネーミングは、作業中の機能を説明するものであれば何でもかまいません。

作業が次のリリースの準備ができると、開発ブランチにマージされ、リリース時間が待機します。

2.リリース

リリースブランチは開発ブランチから作成され、開発ブランチとメインブランチの両方にマージして戻す必要があります。 リリースブランチには、release-x規則を使用して名前を付けます。 実際には、これは通常、使用する予定のリリース番号を次のようにブランチに指定することを意味します。release-2.2

ソフトウェアをリリースするための最終的な準備を行う方法として、リリースブランチを使用します。 これには、ファイルのバージョン番号のバンプ、翻訳が完了したことの確認、または最終的なコードチェックが含まれる場合があります。

3.修正プログラム

ホットフィックスブランチはメインブランチから作成され、ライブアプリケーションですぐに処理する必要のある変更を含めるために使用されます。 これは、修正が必要なバグか、対処が必要なセキュリティの問題である可能性があります。

問題が修正されてメインブランチにデプロイされたら、コードに適切なバージョン番号をタグ付けします。

チームが現在git-flowを使用していない最大の理由は、ソフトウェアのリリース方法が変更されたことです。 大規模なリリースの頻度を減らす代わりに、アプリケーションへの変更を1日に数回リリースすることができます。 準備ができ次第、週に何度もクライアントのサイトに仕事をプッシュしていることを知っています。 サイトのバージョン番号は作成せず、改善を続けています。

標準のgit-flowはこれに対応するためのものではありません。

Githubフロー

多くの人が使用する2番目のオプションはGithubFlowです。

Github Flowの大きなルールの1つは、メインブランチにあるコードはすべて、本番環境に対応しているため、いつでもデプロイできるということです。

すべてのブランチは、メインブランチから作成され、実行していることを表す名前が付けられます。

変更の準備ができたら、プルリクエストを作成します。

プルリクエストは、同じコードで作業している他の人に、それらの変更がメインコードにマージされる前に、実行している作業を確認する準備ができていることを通知します。

プルリクエストを送信すると、作業しているチームが変更を確認してフィードバックを提供できます。 プルリクエストがマージの準備ができていると見なされる場合、プロジェクトのメインブランチにマージされます。

単一の開発者または非常に小規模なチームのGithubフローの欠点の1つは、プルリクエストの管理により、プロジェクトの管理に余分なオーバーヘッドが発生する可能性があることです。 これが、私が仕事でそれらを使用しない理由です。

クライアントプロジェクトでGitワークフローを使用する方法

私のクライアントの仕事では、通常、プロジェクトのコードを毎日書いているのは私だけです。 私のクライアントはWordPressプラグインを更新したり、一部のCSSを変更したりする可能性がありますが、主要なコーディング作業は行いません。 つまり、Githubフローを使用した場合、追加の管理上の問題を引き起こすだけのプルリクエストを確認することになります。 私が使用しているシステムを見てみましょう。これは、git-flowとGithubflowの両方に似ています。

mainとstagingという2つの主要なブランチがあります。 メインブランチは、本番サイトで現在実行されているコードを追跡します。 ステージングブランチは、変更をライブサイトにプッシュする前に、変更をテストするために使用するステージングサイトでテストされているものを追跡します。

すべてのブランチはメインブランチから作成されます。 新しい機能には、feature/32-new-featureのような名前が付けられています。 このコンテキストでは、番号32は、プロジェクト管理システムのチケット番号に対応し、その後の単語は、作業中の内容の簡単な説明です。 バグ修正にも同様の名前が付けられます、bug/20-bug-name。

作成されたすべてのブランチは、最初にステージングブランチにマージされ、次にクライアントによって承認されるか、自分でテストされると、マスターブランチにマージされます。 そのワークフローは次のようになります。

＃機能をステージングブランチにマージ

gitマージ機能/32-新機能

＃機能をデプロイしてテストする

git checkout main

gitマージ機能/32-新機能

＃ライブサイトに機能をデプロイする

私のプロジェクトでは、継続的デプロイを設定しています。つまり、コードをメインにプッシュすると、コードは自動的にライブサイトにプッシュされます。 同じプロセスがステージングブランチにも設定されます。

プルリクエストワークフローでコードをチェックできるチームで作業している場合は、チームでうまく機能するため、このシステムを使用します。 ほとんどが自分で作業している開発者にとって、ワークフローを遅くするのは単に管理オーバーヘッドです。

私が使用する高度なGitコマンド

実用的なワークフローでGitをどのように使用できるかがわかったので、これを実現するために必要となるより高度なコマンドを見てみましょう。 私は顧客のコードを操作するときに、これらの各コマンドを少なくとも週に数回使用します。

GUIアプリケーションを使用する場合でも（Gitに関する前回の投稿でいくつかの優れたアプリケーションについて言及しました）、バックグラウンドで何が起こっているのかを理解することは依然として重要です。 Git GUIアプリケーションによって作成された問題を修正するために、ターミナルを介して何度も作業する必要がありました。

行ごとの変更の追加

ターミナルクリックを介してGitを使用するコマンドの1つは、gitadd-pでした。 このコマンドを学ぶまでは、コードに変更を加えるためにGUIアプリケーションを使用していましたが、変更を加えた理由を説明できるように、特定の行を別のコミットに分割したいと考えていました。 これを行うために、GUIを使用して行を選択しましたが、git add -pを使用すると、インタラクティブなインターフェイスを介して変更をチャンクに追加できます。

私はこれを毎日何度も使用しています。

リモートGitブランチを追跡する

既存のリポジトリをプルダウンしていて、追跡する必要があるがすでに存在しているmainやstagingのようなブランチがある場合は、ローカルバージョンのブランチにそれらのリモートバージョンのブランチを追跡するように指示する必要があります。

これを行うにはいくつかの方法があります。

＃リモートにプッシュするときにアップストリームに設定

git push -u originstaging

＃アップストリームに設定

＃現在リモートで追跡したいブランチにいることを前提としています

git branch -u origin / staging

git branch --set-upstream-to = origin / staging

＃追跡するブランチにいない場合は、最後にブランチを指定します

git branch --set-upstream-to = origin / staging staging

変更をコミットせずに保存する

まだコミットする準備ができていない作業の途中にいることもありますが、その状態を保存する必要があります。 そこでgitstashが役立ちます。 このコマンドは、変更を削除することにより、変更を隠しておきます。 gitstashpopを使用してそれらを取り戻すことができます。 stashを便利にするコマンドは他にもいくつかありますが、これらは私が定期的に使用する2つのコマンドです。

特定のGitコミットをプルする

時々、あなたはあなたの現在の仕事に特定のコミットを引き込む必要があります。 クリーンなHEAD（まだ変更を加えていない）を使用すると、gitcherry-pickを使用して特定のコミットをプルできます。 gitcherry-pickに関する完全なドキュメントはここにあります。

コミットごとに、GitはGitオブジェクトと呼ばれ、一般にSHAと呼ばれる文字と数字の長いシーケンスを構築します。 各コミットは1つを取得するため、SHA値を使用してコミットを参照できます。 Gitオブジェクトの詳細をご覧ください。

不要な変更を破棄する

プロジェクトのある時点で、変更を加えてから、それが機能していないことに気付き、単にそれらを廃棄して最初からやり直す必要があります。 目的の場所に戻るまで元に戻そうとする代わりに、次のGitコマンドを使用して、まだ追跡されていない変更を削除できます。

git reset --hard

上記のコマンドは、現在作業しているブランチの最新のコミットにコードをリセットします。 最新のコミット前の状態に戻したい場合は、このコマンドで<#commitSHA>を使用して、特定のコミットにリセットすることもできます。 ブランチ全体の作業価値は維持したくないので、これを使用して最初のブランチチェックアウトにリセットすることもできますが、作業の一部はすでに追跡されています。

さらに一歩進めるために、git cleanコマンドを使用して、まだgitで追跡されていないファイルまたはディレクトリを破棄できます。

git clean -fd：フラグfとdは、追跡されていないファイルとディレクトリを破棄するようにgitに指示します。

ブランチを削除します

毎週1、2週間、git statusコマンドの結果を見ると、リポジトリで何が起こっているのかを合理的に理解するにはブランチが多すぎることがわかります。 つまり、次のコマンドで解決されたチケットに対応するブランチを削除できます。

＃ローカルバージョンを削除します

git branch -d $ branchname

＃リモコンのブランチを削除します

git push $ remotename --delete $ branchname

バージョン管理を使用する

使用するGitコマンドの専門家ではないかもしれませんが、覚えておくべき重要なことの1つは、バージョン管理を使用する必要があるということです。 プロジェクトに取り組んでいるのがあなただけの場合でも、GitとGitワークフローを使用すると、プロジェクトを整理するのに役立ちます。 動作しなかったコードを記述した後、作業を​​リセットするまで、CTRL+Zを押す必要はありません。

あなたはあなたのシステムを信頼し、あなたのプロジェクトのために仕事を作り続けることができるでしょう。

フルマネージドWordPressホスティングをお試しください

WordPress用に最適化されたホスティングが必要ですか？ NexcessのフルマネージドWordPressホスティングプランを今すぐチェックしてください。