Git を使用して複数のフィーチャーを同時に処理する
場合によっては、未完成のものを使って別のタスクに切り替えてから、それらに戻る必要があります。AppCode はあなたの作業を失うことなくいくつかの異なる機能に便利に取り組むためのいくつかの方法を提供します:
スタッシュの変更は、シェルブに非常に似ています。唯一の違いは、パッチの生成方法と適用方法にあります。スタッシュは Git によって生成され、AppCode の内部または外部から適用できます。変更がシェルブされたパッチは AppCode によって生成され、IDE からも適用されます。また、スタッシュにはコミットされていないすべての変更が含まれますが、変更をシェルフに配置する場合、すべてをシェルフする代わりに、ローカルの変更の一部を選択できます。
ブランチを作成して、関連のないさまざまな機能を操作できます。
変更をシェルフに退避
シェルフは、まだコミットしていない保留中の変更を一時的に保存しています。これは、たとえば、別のタスクに切り替える必要があり、後で作業するために変更を脇に置いておきたい場合に役立ちます。
AppCode を使用すると、個別のファイルと変更リスト全体の両方をシェルブできます。
保留にすると、必要に応じて何度でも変更を適用できます。
変更をシェルフに退避
コミットツールウィンドウ Alt+0 で、シェルフに配置するファイルまたは変更リストを右クリックし、コンテキストメニューから変更をシェルフに退避を選択します。
変更をシェルフに退避ダイアログで、変更されたファイルのリストを確認します。
コミットメッセージ: フィールドに、作成するシェルブの名前を入力し、変更をシェルフに退避ボタンをクリックします。
また、変更をシェルフに退避ダイアログを表示せずにサイレントに変更を保存することもできます。これを行うには、保存するファイルまたは変更リストを選択し、ツールバーの確認なしでシェルフに退避アイコン 
をクリックするか、Ctrl+Shift+H を押します。シェルフする変更を含む変更リストの名前がシェルフ名として使用されます。
同じ名前の多数のシェルフ（たとえば、デフォルトなど）が表示されないようにするには、ファイルまたは変更リストを <ブランチ> にコミットするタブからコミットツールウィンドウのシェルフタブにドラッグし、アクティブになるまで 1 秒待ちます。マウスボタンを離したときに、新しいシェルフ名をオンザフライで編集します。
変更をアンシェルブ
保留中の変更は、延期された変更をシェルブから保留中の変更リストに移動することです。切り詰められていない変更は、ビューから除外したり、シェルフから削除することができます。
シェルフタブで、シェルフを解除する変更リストまたはファイルを選択します。
Ctrl+Shift+U を押すか、選択項目のコンテキストメニューからアンシェルブを選択します。
変更をアンシェルブダイアログで、名前フィールドに、保留されていない変更を復元する変更リストを指定します。リストから既存の変更リストを選択するか、保留されていない変更を含む作成する新しい変更リストの名前を入力できます。コメントフィールドに新しい変更リストの説明を入力できます（オプション）。
新しい変更リストをアクティブにする場合は、アクティブにするを選択します。それ以外の場合、現在アクティブな変更リストはアクティブのままです。
AppCode が非アクティブ化時に新しい変更リストに関連付けられたタスクのコンテキストを保持し、変更リストがアクティブになったときにコンテキストを復元する場合は、コンテキストを追跡するオプションを選択します（詳細については、タスクとコンテキストを参照してください）。
アンシェルブしようとしている変更を削除したい場合は、正常に適用したファイルをシェルフから除去するオプションを選択してください。保護されていないファイルはこのシェルフから削除されて別の変更リストに追加され、適用済みとしてマークされます。それらは、ツールバーの
をクリックするか、コンテキストメニューからすでにアンシェルブされたものをクリーンを選択して明示的に削除されるまで完全には削除されません。OK をクリックします。パッチされたバージョンと現在のバージョンの間に競合が発生した場合は、競合の解決の説明に従って解決してください。
また、変更をアンシェルブダイアログを表示せずにサイレントに変更を取り消すこともできます。これを行うには、取り消したいファイルまたは変更リストを選択し、ツールバーの確認なしでアンシェルブアイコン 
をクリックするか、Ctrl+Alt+U を押します。アンヘルになったファイルは、アクティブな保留変更リストに移動されます。
ファイルまたは変更リストをシェルフタブから <ブランチ> にコミットするタブにドラッグして、サイレントに解除することもできます。Ctrl キーを押しながらドラッグすると、シェルフから削除されずにブランチにコミットするタブにコピーされます。
保留された変更を破棄
シェルフビューで、これ以上保持しない変更を含む変更リストを選択します。
それを右クリックして、コンテキストメニューから削除を選択するか、Delete を押します。
保留されていない変更を復元する
AppCode を使用すると、必要に応じて保護されていない変更を再適用できます。ツールバーの アイコンをクリックするか、コンテキストメニューからすでにアンシェルブされたものをクリーンを選択することによって明示的に削除されるまで、保留にされていない変更はすべて再利用できます。
すでにアンシェルブされたものを表示
ツールバーオプションが有効になっていることを確認します。復元するファイルまたはシェルフを選択します。
選択のコンテキストメニューから復元を選択します。
外部パッチを適用する
AppCode の内部または外部に作成されたパッチをインポートして、保留変更として適用することができます。
シェルフビューで、コンテキストメニューからパッチのインポートを選択します。
表示されたダイアログで、適用するパッチファイルを選択します。選択したパッチがシェルフタブにシェルフとして表示されます。
パッチを適用して新しく追加されたシェルフを選択し、選択したコンテキストメニューから変更をアンシェルブを選択します。
ベースリビジョンの自動シェルフ
Git バージョン管理下にあるファイルの基本リビジョンを常にシェルブするように AppCode を構成すると便利な場合があります。
Ctrl+Alt+S を押して IDE 設定を開き、を選択します。
分散バージョン管理システム下にあるファイルのシェルブベースリビジョンオプションを選択してください。
このオプションを有効にすると、ファイルのベースリビジョンが、シェルフを適用すると競合につながる場合に 3 方向マージ(英語)で使用されるシェルフに保存されます。無効にすると、AppCode はプロジェクト履歴のベースリビジョンを探しますが、時間がかかることがあります。さらに、矛盾するシェルフが基づいていたリビジョンが失われている可能性があります（たとえば、リベース操作の結果として履歴が変更された場合）。
デフォルトのシェルフの場所を変更する
デフォルトでは、shelf ディレクトリはプロジェクトディレクトリにあります。ただし、デフォルトのシェルフの場所を変更することができます。これは、作業コピーをクリーンアップするときにシェルブを誤って削除しないようにする場合や、別のリポジトリに格納してシェルブをチームメンバー間で共有できるようにする場合などに便利です。
Ctrl+Alt+S を押して IDE 設定を開き、を選択します。
シェルブロケーションの変更をクリックし、開いたダイアログで新しい場所を指定します。
必要に応じて、退避済みの変更を新しい場所に移動を選択して、既存のシェルフを新しいディレクトリに移動します。
未完成の作業を失うことなく、別のタスクに切り替えるためのシェルブからの恩恵を受ける方法に関するこのビデオチュートリアルを参照してください。
変更のスタッシュ
時には、HEAD コミットと一致するように作業コピーを元に戻す必要があるかもしれませんが、すでに行った作業を失いたくない場合もあります。これは、おそらくやっていることに関連する上流の変化があるか、あるいは緊急の修正が必要な場合に起こります。
スタッシュには、HEAD コミットと作業ディレクトリ（スタッシュ）の現在の状態との違いを記録することが含まれます。インデックスへの変更も隠しておくことができます。
スタッシュ解除は、ブランチに格納されたスタッシュを適用することを含みます。
既存のブランチにスタッシュを適用するか、それに基づいて新しいブランチを作成することができます。
スタッシュは、必要なブランチに何度でも適用できます。必要なブランチに切り替えるだけです。それを念頭に置いて:
一連のコミット後にスタッシュを適用すると、解決する必要がある競合が発生します。
「ダーティ」な作業コピー、つまりコミットされていない変更を含む作業コピーにスタッシュを適用することはできません。
変更をスタッシュに保存する
メインメニューから を選択します。
開いているスタッシュダイアログで、適切な Git ルートを選択し、正しいブランチがチェックアウトされていることを確認します。
メッセージフィールドには、隠そうとしている変更を記述します。
スタッシュのローカル変更を行い、検査およびテストのためにインデックスにステージングされた変更を作業ツリーに持ち込むには、インデックスを保持するオプションを選択します。
スタッシュの作成をクリックします。
スタッシュを適用する
メインメニューから を選択します。
スタッシュを適用する Git ルートを選択し、正しいブランチがチェックアウトされていることを確認してください。
リストから適用したいスタッシュを選択します。
選択した stash で影響を受けるファイルを確認するには、表示をクリックします。
選択したスラッシュを適用した後に削除するには、スタッシュを pop オプションを選択します。
スタッシュインデックスの変更を適用するには、インデックスを戻すオプションを選択します。
現在チェックアウトされているブランチに適用するのではなく、選択したスタッシュに基づいて新しいブランチを作成する場合は、そのブランチの名前を新規ブランチとしてフィールドに入力します。
スタッシュを削除するには、リストからスタッシュを選択し、ドロップをクリックします。すべてのスタッシュを削除するには、クリアをクリックします。
変更を異なる変更リストにグループ化する
関連するいくつかの機能に取り組んでいる場合は、変更をさまざまな変更リストにグループ化すると便利な場合があります。このアプローチには、機能ブランチを使用して複数のタスクを処理するのとは対照的に、長所と短所があります。
長所 :
異なる論理セットの変更を簡単に切り替えて、相互に別々にコミットすることができます。
同じ目的でブランチを使用するのとは異なり、ブランチを切り替えることなくすべての変更を手に入れています。ブランチは、プロジェクトが本当に大きい場合には時間がかかります。
さまざまな機能がどのように連動するかをテストすると便利です。
ビルドサーバー上で変更リストをリモート実行できます。
短所 :
変更リストを使用すると、ブランチに比べて軽量のオプションに見えるかもしれませんが、コミットしてプッシュするまで、変更のバックアップがないため安全ではありません。ローカル作業コピーに何か問題が発生した場合、Git プロジェクトの履歴に含まれていない変更はすべて失われます。
機能のアトミックなテストは不可能です。
同じ機能の共同作業は不可能です。また、メールによる変更を加えたパッチを送信しない限り、別のマシンからの貢献はできませんが、これはあまり便利ではないかもしれません。
すべての変更リストは、<ブランチ> にコミットするタブのローカルの変更ビューに表示されます。変更されたすべてのファイルは、アクティブな変更リストに自動的に配置されます。これは、別のファイルを作成してアクティブにしない限り、変更変更リストです。
変更リストはローカルの変更ビューに表示されます。最初は、デフォルトの変更リストが 1 つあります。これは変更と呼ばれ、すべての新しい変更は自動的にこの変更リストに配置されます。まだ VCS に追加されていない新しく作成されたファイルをグループ化するバージョン管理外ファイル変更リストもあります。
必要な数だけ変更リストを作成して、いつでもアクティブにすることができます。コミットされていない変更を変更リストに移動できます。
新しい変更リストを作成する
ローカルの変更ビューで、ツールバーの
をクリックし、新規変更リストを選択します。新規変更リストダイアログで、新しい変更リストの名前を指定し、説明を追加します（オプション）。
アクティブな変更リストを設定する
ローカルの変更ビューで、非アクティブな変更リストを選択して Ctrl+Space を押すか、それを右クリックしてコンテキストメニューからアクティブな変更リストを設定を選択します。新しい変更はすべて、この変更リストに自動的に配置されます。
変更リスト間で変更を移動する
ローカルの変更ビューで、別の変更リストに移動する変更を選択します。
選択範囲を右クリックするか、ツールバーの
をクリックして別の変更リストに移動 Alt+Shift+M を選択します。表示されるダイアログで、既存の変更リストを選択するか、新しい変更リストの名前を入力します。
ターゲットの変更リストをアクティブにし、そのコンテキストを追跡することを選択できます（AppCode は、この変更リストに関連付けられたコンテキストを保存し、この変更リストがアクティブになったときに復元します）。
変更リストを削除する
変更リストを右クリックし、コンテキストメニューから変更リストの削除を選択します。
機能ブランチを使用
Git のブランチは独立した開発ラインを表するため、作業の結果を共有して master に統合する準備が整う前に、完了してテストする別の機能に取り組んでいる場合は、ブランチ機能最高のソリューションです。こうすることで、不安定なコードがプロジェクトのメインコードベースにコミットされていないことを確認し、必要に応じて簡単に他のタスクに切り替えることができます。
長所 :
変更リストを使用して変更をグループ化するのではなく、機能ブランチを使用するのが安全です。Git への変更をコミットした後、それらは Git プロジェクトの履歴に含まれるため、作業ツリーを破壊しても Git 参照ログ(英語)を介してコミットをいつでも復元できます。変更をプッシュしたら、それらはバックアップされます。
並列でない非関連フィーチャを開発し、それをアトミックにテストすることができます。
ブランチでの開発が終了したら、コミットの順序を変更したり、コミットをスカッシュしたりして、履歴を直線的でクリーンなものにすることができます。
機能を簡単にコラボレーションすることも、別のマシンから開発することも簡単です。
短所 :
ブランチを本当に大規模なプロジェクトに切り替えるには時間がかかることがあります。
関連する機能を一緒にテストするのはあまり便利ではありません。
機能ブランチを使用して変更をメインコードベースに統合するには、主に 2 つの方法があります。
マージを使用して、フィーチャからの変更を統合するブランチ
マージオプションの主な利点は、完全なトレーサビリティです。メインコードベースにマージされたコミットが元のハッシュと作成者を保持し、1 つのフィーチャの一部であるすべてのコミットをグループ化できます。
このワークフローは、既存のブランチがまったく変更されないため、メインコードベースへの変更のコミットにプルリクエストまたは階層的な承認手順が含まれるプロジェクトに適しています。
このアプローチの主な欠点は、変更を組み込む必要があるたびに外部のマージコミットが作成され、プロジェクト履歴を激しく汚染し、読みにくくなることです。
リベースを使用して機能ブランチからの変更を統合する
このオプションの主な利点は、他の人が読んで理解しやすいクリーンなプロジェクト履歴を取得できることです。あなたのログには、merge 操作によって生成された不要なマージコミットが含まれていないため、移動や検索が容易な線形履歴が得られます。
ただし、このワークフローを採用する場合は、元の機能ブランチのコミットごとに新しいコミットを作成するため、rebase はプロジェクトの履歴を書き換えるため、異なるハッシュを持つため、トレーサビリティが阻害されます。
別の開発ライン用にブランチを作成します。
開発中は頻繁に変更をコミットしてください。
ブランチをリモートリポジトリにプッシュします。これはバックアップのために行う必要があります。これにより、さまざまなマシンで共同作業や作業を行うことができます。
機能ブランチを
masterにリベースすることがあります。これを行うのは、機能ブランチが長い場合にのみ意味があります。これは次の場合に役立ちます。機能ブランチと
masterが離れすぎないようにしてください。最終的に変更をメインコードベースに統合する際に、多数の競合を解決することは避けてください。定期的にリベースすると、反復的に競合を解決し、長い間の競合で苦しんでしまうことはありません。
ブランチ間の切り替えが十分に発散するとすぐに遅くなるため、ブランチのチェックアウトを高速化します。
リベースには次のステップが含まれます。
機能に関連していない作業を実行する必要があるときは、
masterに切り替えます。あなたの機能ブランチに戻ったら、チェックアウトして現在のブランチでリベースを実行してください。機能を見直してテストし、必要な修正を加えてください。
機能が完了したら対話式リベースを実行します。これにより、コミットを並べ替えてスカッシュして、機能のブランチ履歴をきれいに表示することができます。
作業結果をメインのブランチ（
masterなど）に統合する準備ができたら、次の手順を実行します。
関連ページ：
シェルブタブ
このタブは、変更または変更リストをシェルブするとバージョン管理ツールウィンドウに追加され、すでにアンシェルブされたものやインポートされた外部パッチを含むすべてのシェルブされた変更を完全に削除するまで表示されます。デフォルトでは、このタブにはまだ解除されていないすべての保留中の変更が表示されます。変更はシェルフにグループ化されます。シェルフは、変更を保留したときに作成される変更リストです。シェルフはコミットメッセージによって識別されます。AppCode にアンシェルブされた変更を表示させることが...
タスクとコンテキストを管理する
プロジェクトで作業する場合は、完了する必要のある小さな作業で作業を整理できます。これらは、自分で設定したタスクです。AppCode では、大きな作業を小さなタスクに分割し、変更リストに関連付けることができます。これらは、課題追跡システムからのタスクである可能性もあります。例: AppCode から直接割り当てられたタスクやバグを処理できます。これを可能にするには、IDE とトラッカーアカウントを接続します。課題追跡との統合を構成する：AppCode は次のものとの統合をサポートします。Jira...
競合の解決
バージョン管理システムによっては、状況によっては競合が発生することがあります。チームで作業をしているとき、誰かが現在取り組んでいるファイルへの変更をコミットするという状況に遭遇するかもしれません。これらの変更が重複しない場合（つまり、異なるコード行に変更が加えられた場合）、競合するファイルは自動的にマージされます。ただし、同じ行が影響を受けると、バージョン管理システムはランダムに片側を選択することができず、競合を解決するように求められます。ブランチをマージ、リベースまたはチェリーピックするときに...
Git ブランチの管理
Git では、分岐は強力なメカニズムであり、たとえば、機能で作業する必要がある場合や、リリースのためにコードベースの特定の状態をフリーズする必要がある場合などに、メインの開発ラインから分岐することができます。AppCode では、ブランチでのすべての操作は Git ブランチポップアップで実行されます。これを呼び出すには、ステータスバーの Git ウィジェットをクリックします (現在チェックアウトされているブランチの名前が表示されます)。Git ツールウィンドウのブランチペインで、ブランチを管理し、複...
Git リポジトリに変更をコミットしてプッシュする
Git リポジトリに新しいファイルを追加した後、またはすでに Git バージョン管理下にある変更されたファイルを追加し、それらの現在の状態に満足したら、作業の結果を共有できます。これには、リポジトリのスナップショットをプロジェクト履歴に記録するためにローカルにコミットしてから、プッシュをリモートリポジトリにコミットして、他のユーザーが利用できるようにすることが含まれます。Git ユーザー名を設定する Git は、コミットを ID に関連付けるために、ユーザー名を知っている必要があります。ユーザー名...
Git プロジェクト履歴を編集する
Git を使用すると、プロジェクト履歴を編集できます。これは、機能ブランチで作業していて、他の人と共有する前に、それをクリーンアップして希望どおりに表示したい場合に便利です。例: コミットメッセージを編集したり、同じ機能に関連する小さなコミットをまとめたり、無関係な変更を含むコミットを個別のコミットに分割したり、前のコミットに変更を追加したりできます。コミットメッセージを編集する：変更する必要があるのがコミットメッセージだけであれば、このコミットをプッシュする前にそれを編集できます。Git ツー...