バージョン管理とGitの概要

Googleドキュメントに精通していますか？ もしそうなら、ライターと関係者がドキュメントで行われたすべての変更をチェックして追跡できる小さな「バージョン履歴」タブを知っていると想定しても安全です。 任意の時点で。 便利な道具ですね。

ここで、段落でいっぱいのシートの代わりに、数百行のコードでいっぱいのファイルがあると想像してください。 また、単一のドキュメントとは異なり、絶えず更新されるさまざまなファイルがたくさんあります。

このようなシナリオでは、数千行のコードが実行され、最終結果が得られます。つまり、モバイルアプリはビジネスの将来に依存するものであり、すべての変更を監視するソフトウェアを用意することがさらに重要になります。コードファイルで作成されます。

ここで、バージョン管理ソフトウェアが登場します。

ソフトウェア開発でバージョン管理が重要な理由

名前が示すように、バージョン管理ソフトウェアを使用すると、モバイルアプリの開発者はソフトウェア開発サイクルのさまざまなバージョンを追跡し、それらに変更を加えることができます。 コードで発生するすべての変更を追跡するこの機能と、変更を元に戻すオプションにより、バージョン管理は、複数の開発者が関与するモバイルアプリ開発会社のプロセスの重要な部分になります。

現在、バージョン管理に関しては、現在市場に出回っているソフトウェアはたくさんあります。 それらのいくつかを見てみましょう–

バージョン管理に利用可能なソフトウェア

分散ソフトウェアのリーダーは、GitLabサーベイで、ユーザーの98％がGitオープンソースツールを使用し、開発者の92％以上がアプリ開発プロセスのバージョン管理言語としてGitを使用していることを発見しましたが、開発者がGitの代替案を検討する理由のいくつか。 これらの理由のいくつかは、GitHubの価格体系と、GithubがiOSとAndroidの両方で起動されるという事実、Octocatへの嫌悪感、またはGitではないバージョン管理言語を使用した単純な快適性レベルとは異なります。

理由が何であれ、バージョン管理のためのGitの代替手段は次のとおりです–

現在、バージョン管理やAppinventivで利用できる代替案が多数ある場合でも、顧客の要件がさまざまであるため、それらの多くに直接取り組んだ経験があります。実際、Gitに偏っています。 理由をお話ししましょう。

Appinventivがバージョン管理にGitを使用する理由

1.その電光石火の速度のために

市場に出回っているすべてのバージョン管理ソフトウェアの中で、Gitログ要素とコミット要素が機能する速度は他のどのソフトウェアにも匹敵しません。 また、開発者のチームがプラットフォームで作業している場合、ソフトウェアが高速であることが絶対に必要になります。

2.オフラインで作業できるようにするため

インターネットに依存するソフトウェアで作業している場合、移動中に中央リポジトリとの接続が失われるとリスクが生じる可能性があります。 しかし、これはGitには当てはまりません。 Gitを使用すると、ローカルマシンでほぼすべてのタスクを実行できます。コミット、プロジェクト履歴の参照、ブランチの作成、マージなどです。

3.元に戻す救済のために

Gitには、コミット全体を修正して元に戻すことができる「undo」コマンドが付属しています。 実際、Reflogオプションを使用して「削除された」コミットを復元するオプションも提供されます。

4.バックアップ用

チームがGitで作業する場合、チームがマシン上に持つすべてのクローンには、使用可能なバックアップが付属しています。 それに加えて、ほとんどすべてのGitアクションはデータを追加するだけで、データを削除しません。

5.有用なコミットを行うため

開発者チームが一連の無関係な変更をコミットすると（Aからいくつかの機能を取得し、別の機能にバグ修正を加える）、他のチームメンバーが何が起こったのかを理解するのが非常に難しく、ロールバックするのが難しい場合があります。問題を引き起こしている場合のAの機能。

Gitは、段階的なコミットを作成することでこの混乱を解決します。 その「ステージング領域」の概念により、1行だけを見ている場合でも、次のコミットにどのような変更が含まれるかを簡単に見つけることができます。

したがって、これらが、ここAppinventivでGitを使用する5つの主な理由です。 理由を確認したので、次は方法を確認します。 バージョン管理プロセスにGitを組み込む方法。

今それを取得しましょう。

Gitを使用する場合のバージョン管理のプロセス

リポジトリの作成

Gitの目的は、一連のファイル、別名Projectを管理することです。 これを行うために、Gitはすべての情報をリポジトリと呼ばれるデータ構造に保存します。 リポジトリは、アプリのソースコード、リソース、およびデータセットで構成されます。 基本的に、アプリプロジェクトを定義するすべてのものがあります。

現在、Gitでリポジトリを取得する方法は2つあります。 ローカルディレクトリを使用し、コマンドラインを使用してそれをGitリポジトリに変換するか、すでにアップロードされているGitリポジトリを自分のディレクトリにコピーすることができます。

リポジトリを作成すると、通常、パブリックとプライベートの2つのオプションが表示されます。 パブリックリポジトリは、Gitを使用して他の開発者が表示できるリポジトリであり、プライベートリポジトリは、少数のユーザーしか表示できないリポジトリです。

分岐

リポジトリ作成の隣は分岐です。 Appinventivのような会社では、15〜20人を超える開発者が1つのプロジェクトに取り組んでおり、開発者が同じソースコードを共有して作業することも珍しくありません。 何が起こるかというと、一部の開発者は問題の修正に忙しく、他の開発者はいくつかの機能を実装している可能性があります。

このような状況では、同じコードベースで異なるコードバージョンを簡単に処理できるシステムが必要です。

ここでGitflowが登場します。 Gitflowは、体系的かつ効率的に分岐するために使用されるフレームワークです。

分岐プロセスがGitflowでどのように機能するかを説明する前に、例を使用して概念を説明しましょう。

チームに5人の開発者がいて、彼らがInstagramのようなアプリの開発に取り組んでいるとします。 これで、フィードや通知などの個々のアプリの機能は、モジュール1、モジュール2などとして示されます。 現在、これらの異なるモジュールは開発ブランチであり、作業後に親ブランチまたはマスターとマージされます。

開発者がブランチを追加するとすぐに、独立した開発ラインが作成され、チームメンバーの作業から作業が分離されます。 次に、異なるブランチが親ブランチにマージされます。

分岐は、チームメンバーが予想するすべての変更を識別できるようにする方法であり、バックトラックを容易にするものです。

私たちのプロジェクトでは、通常、これらのブランチを保持しています–

• マスターブランチ
• 開発ブランチ
• 機能ブランチ
• リリースブランチ
• ホットフィックスとバグ修正

専念

開発者が個々のファイルに加える変更は、コミットと呼ばれます。 変更またはコミットは、サーバーではなくローカルリポジトリに追加されます。 次に、開発者はコミットメッセージを作成する習慣に従います。このメッセージでは、コミットの説明（ファイルに加えられた変更）が投稿されるため、他の開発者もファイルに加えられた変更の詳細を知ることができます。

押す

ローカルのGitリポジトリでコミットすると、次に何が起こるかというと、変更がサーバーに送信されます。これはプッシュと呼ばれます。

ファイルで作業しているのがあなただけの場合、コミット履歴をサーバーにプッシュするのはかなり簡単ですが、プロセスに他の開発者も関与している場合は、セットをプッシュする前に変更をプルする必要がありますGitにコミットします。

次に、プル変更ステップで何が行われるかを調べます。

プルリクエスト

複数の開発者が同じファイルで作業している場合、他の開発者がプッシュする前に、一部のコミットがサーバーにプッシュされる可能性があります。 そしてそれが起こると、対立が起こります（それについては後で詳しく説明します）。

サーバーに同じコードベースを2回アップロードしないようにするために、開発者は最初にリポジトリから変更をプルし、コードが異なることを確認します。 現在、一般に、2人以上の開発者が同じファイルで作業し、サーバー上でコミットをプッシュすると、「マージ」するオプションが表示されます。

次にマージについて話しましょう。

マージ

マージは、開発者が最初にすべてのブランチを互いにクラブし、次にマスターまたは親ブランチとクラブするステップです。

配信がプッシュコマンドを入力するたびに、マージオプションが取得され、コミットをマージするブランチを尋ねられます。

現在、マージ段階では、競合の発生は非常に一般的です。 競合は通常、マージする予定の2つのブランチが同じファイルの同じ部分で変更された場合に発生します。 ここで何が起こるかというと、Gitはどのバージョンを使用すべきかを判断できないということです。

この競合の問題が発生すると、Gitは自動と手動の2つの解決策を提供します。

名前が示すように、1つは、Gitが問題自体を見つける場所であり、後者の場合、開発者は手動でそれを行う必要があります。 Appinventivでは、バグが発生する可能性がわずかでもなくなるため、競合の手動解決に重点を置いています。

Gitを使用してアプリ開発プロセスのバージョン管理を行っている間、同時に発生するのは問題追跡です。

私たちはアジャイルの大ファンであり、モバイルアプリの開発プロセスについてアジャイルを信頼しているため、複数の開発プロセスを同時に処理することの重要性を理解しています。 また、問題追跡機能を使用すると、テスターがGitサーバーで記述およびプッシュされたコードをリアルタイムで監視することがはるかに簡単になります。

ZenHubボードを使用して、各リポジトリのワークフローを監視します。 ボードを使用すると、提案された変更の優先度を追跡し、開発者がボード上のコメントをリアルタイムで更新できるようになります。