Githubと4D

Githubと4D ([原文](http://library.4d-japan.com/00_xfer/00_tn/）

はじめに

初心者の開発者あるいは熟練のシニア・デベロッパーであっても、複数の人員がいわゆる生産チェーン連携に加わるために共同作業する傾向があるので、バージョン管理はあらゆる作業環境で必須となっています。シナリオがどのようなものであっても、動作の言語/フレームワークが何であっても、『プログラムやWebページに10行以上のコードが含まれるようになると、GITは必要不可欠なもの、あるいは一部では必要悪と呼ばれるものになる」という１つのアドバイスがずっと存在しています。GITを理解することは、最初は骨の折れる複雑な作業のように思えるかもしれませんが、一旦バージョニングが提供するパワーと安全性を理解すれば、コーディングとコンフリクト管理はもはや面倒ではなくなります。

このテクニカル・ノートでは、GIT = GitHubを使ったリビジョン管理システムを、ホスティング・サービスとして紹介し、インストールから設定手順、GIT bashを使ったGITレポジトリとの相互通信の異なる方法を詳細に説明します。

概要

GITは昔からある同等のもの（CVS、SVN…)と同じように、主にLinux向けに開発されたリビジョン管理システムですが、MacとWindowsシステムでも動作します。GITは急進的なアプローチを取ったので、これまでの遺産的な類似品とは大きく異なります。GITは、中央集中型ではなく分散型であるため、レポジトリの完全なコピーとバックアップを全てのユーザーが持つという点で、従来のGITとは大きく異なる抜本的なアプローチを採用しました。データがローカルに保存されるため、ファイル履歴へのアクセスが非常に効率的になります。

全ての開発者の作業ディレクトリ自体がブランチであるため、GITはチームワークを単純化し、プロジェクトでのコラボレーションをはるかに管理しやすくします。全てのブランチに対するあらゆる変更はマスター・ブランチ内にマージすることができますが、同時に発生する可能性のあるコンフリクトにも対処することができます。

これにより、複数の共同作業者が同じファイルで同時に作業することが可能になり、最終的なファイルをマージするのはそれほど面倒ではないことが分かります。

4Dプロジェクト・モード

4Dは以前のバージョンからチームの開発とテストをサポートしており、4Dサーバー経由でチームメンバーが一緒に作業できるバイナリ・システムを使用していました。v17R5から4Dには、分散したチームが同じソース（プロジェクト・モード）で作業できる新しい方法が導入されました。つまり、バイナリ・ソース（.4DBファイル）をプロジェクト・フォルダに保存し、データベースの全ての要素（フォーム、メソッド…）をテキスト・ファイルとして作成できます。

プロジェクト・モードに変換しても.4DBファイルには影響しませんが、代わりにその隣に新しい「Project」フォルダが生成されます。これには２つの意味があります：

1. これによりバイナリー・データベースの変換を何度も行うことができ、テストに役立つ可能性があります。 　
2. 変換は一方通行の方法だけしかありません。つまり、一度変換すると現在の変更を.4DBに再統合することはできません。

さらに、既存のデータベースを変換することは、プロジェクト・モードにアクセスするための唯一の実行可能な方法ではありません。新しいデータベース・プロジェクトを最初から作成することは、引き続き利用可能なオプションです。

データベースをプロジェクトに変換する

変換のプロセスはシンプルです。デザイン・モードからメニュー・アイテムで、ファイル > 書き出し > ストラクチャからプロジェクト…を選択します。

一度プロジェクトが作成されると以下のプロンプト・メッセージが表示されます。

• Reveal Log /ログを表示する：変換中に生成されたログファイル (JSON)を含むフォルダを表示します。
• Open project /プロジェクトを開く：データベースをプロジェクト・モードで開きます。
• Cancel /キャンセル：変換せずに.4DBモードで残します。このモードにした場合、２度目にこのストラクチャを書き出そうとすると、プロジェクト・フォルダがすでに存在するという警告が表示されます。ユーザーは「置換する」オプションを選択します。

新しいプロジェクトを作成する

新しいプロジェクトの作成はシンプルで、ファイル > 新規 > データベース・プロジェクト…を選択します。

Projectフォルダの中のコンテンツ

一度プロジェクトが生成されると、Projectフォルダはデータベースから（フォーム、メソッド、メニュー、ストラクチャなど）エレメント１つずつがフォルダによって管理されるテキスト・ファイル（.json、.4dm、.4DCatalog、など）で含まれます。

• BuidSettingsフォルダにはBuildapp.xmlが含まれます。
• DerivedDataフォルダにはメソッドとフォームに関するメタデータ（timestamp、destinationなど）が含まれます。
• Sourcesフォルダには、各フォーム、メソッド、トリガー、データベース設定に加えてメニュー、そしてストラクチャのファイルが含まれます。
• Trashフォルダは、Trash Binkから消去されたフォームとメソッドが含まれます。
• Test.4DProject

GITアーキテクチャ

まずはGITのアークテクチャを見て、その背後にあるストラクチャ全体を把握しましょう。

ダイヤグラムは２つの主要なセクションに分かれます：ローカルとリモートです。

ローカル

ワーキング・ディレクトリー：これはデータベースが存在し、.gitフォルダーが生成される場所です。この場所は「トラックされない」エリアとしても知られています。これらのファイルの変更は、ワーキング・ツリーにマークされます。このエリアに変更を加えて、明らかにGITを使ってそれらを保存しなかった場合、データは失われる結果になります。この変更の喪失は、ワーキング・ディレクトリで変更されたことにGITが気づいていないために発生します。要するにGITはワーキング・ディレクトリ上にあるファイルに変更を加えたことに気づいても、正確なコマンドが入力されないとそれらの変更を保存しません。

スターティング・エリア：あるいはインデックス・エリアは、GITがワーキング・ディレクトリ内の各ファイルに発生する変更をステージングする場所です。トラッキングしないファイルとステージングしないファイルの違いはシンプルです。トラッキングしないファイルとは、基本的に以前のレポジトリのスナップショットに存在しなかった全てのファイル（例えば新しいファイル）です。一方、ステージングしない状態は変更に関連しているため、ファイルに変更が加えられる度に、このファイルの内容がワーキング・ツリーからステージング領域まで異なるため、このファイルはステージングしない状態になります。

GITレポジトリ（あるいはローカル・レポジトリ）：これは、コミットが実行される度に全てのファイルが保存される場所です。コミットすると、ステージング・エリア内の全ての変更がローカル・マシンで使用可能なローカル・レポジトリに送信されます。コミットが終了すると、ステージング領域は空のままになります。分散バージョン管理システムの重要な機能の１つは、完全なレポジトリ履歴にローカルでアクセスできることです。

リモート

リモートGITレポジトリ：GITのリモートは基本的に、全てのチーム・メンバーがファイルを送受信できる共通のレポジトリです。リモート・レポジトリは通常ローカルマシンにはなく、例えばGITHUBのようなコードホスティングサービスに保存されますが、内部サーバーで動作するように設定することもできます。チームメンバーは、チームと共有する準備ができたらコミットをプッシュできます。チームが単一の開発者（バックアップとして使用しない限り）で構成されている場合、リモート・レポジトリの使用はオプションであることに注意してください。

GITブランチング

ブランチングは、多くの最新のバージョン管理システムで重要な機能であり、GITでも同様です。ブランチの主な目的は、全てのコミットがプッシュされるマスター・シングル・ブランチの代わりにこのプロセスに別のサイド・ブランチを含めることができる、というユーティリティーにあります。複数のブランチを持つワークフローを実装することで、大きなプロジェクトの可視性が高まり、コンフリクトが少なくなります。マスター・ブランチは正式なリリース履歴を保存し、他のブランチは機能ブランチとして機能し、開発が完了すれば最終的にマスター・ブランチに統合/マージされます。

下記のダイヤグラムをご覧ください：

青のブランチはマスター・ブランチを表し、緑のブランチはフィーチャー・ブランチを表します。プロジェクトの開始時には、両方とも共通のベース（つまりまだ何も機能がないところ）にあり、機能開発が開始されると青のブランチから緑のブランチが分岐し、完了するとマスターにマージされます。

GITインストール

最初のステップはGitHubアカウントを作成することです：

https://github.com/join?source=header

３つのステップがあります。各ステップに従ってアカウント作成を完了してください。

ステップ１： 新しいアカウントの作成

ステップ２： ”The basics of GitHub for every developer”を選択

ステップ３： GitHubを使用するユーザー・エクスペリエンスとプランを指定

WindowsとmacOS上では

1. 最新のGITインストーラーをダウンロード
   • Windowsインストーラー：https://gitforwindows.org/
   • macOSインストーラー：https://sourceforge.net/projects/git-osx-installer/files
2. インストーラーを開始し、ウィザードの「next」ボタンに従い、今は初期設定のまま進めます。
3. ターミナルを開いて、インストールに成功していることを確認するために以下のコマンドを入力します：　GIT —version
4. ターミナルで以下のコマンドのXXXを実際の名称とGitHubアカウントからのメールに置き換えて実行します：

git config ―global user.name “XXXX XXXX” git config ―global user.email XXXX@XXXX.com

特記：オプションですが、強くお勧めします：git credential helper（資格認定ヘルパー）をインストールしましょう：リモートのレポジトリを伴う各指示には、その都度ユーザー名とパスワードの組み合わせの入力が必要で、とても面倒です。GIT credential helper（macではgit-credential-osxkeychain helper for mac）を使って保存するのはシンプルですので、以下をご覧ください：

Windowsでは

GCMを使うには、最新のインストーラーをダウンロードし、GCMW-{version}.exeをダブルクリックして、表示される指示に従います。GIT Bashに対するターミナル・エミュレータを選択する場合には、Windowsの初期設定のコンソール・ウィンドウを選ぶのが正しい選択です。

インストーラーへのリンク：https://github.com/Microsoft/Git-Credential-Manager-for-Windows/releases/tag/1.18.5

macOSでは

ターミナル・ウィンドウを開いて下記のコマンドを入力します：

1. ツールのダウンロード -　curl 　 http://github-media-downloads.s3.amazonaws.com/osx/git-credential-osxkeychain - o git-credential-osxkeychain

2. フォルダの作成 -　sudo mkdir /usr/local -　sudo mkdir /user/local/bin

3. ファイルを正しいディレクトリに移動 -　sudo mv git-credential-osxkeychain /usr/local/bin/

4. ファイルを実行可能にする -　sudo chmod u+x /usr/local/bin/git-credential-osxkeychain

5. Gitをosxkeychainを使う設定にする -　git config -global credential.helper osxkeychain

最初のリモート・レポジトリを作成する

-　https://github.com に接続してログインします -　上部右隅のアイコンをクリックして”Your repositories”を選択します

• 以下はGitHubアカウント内に作成されたリモート・レポジトリのリストを表示しています。

“New”をクリックします。

Repository name： 作成された時にユーザーが入力したリモート・レポジトリの名前

Description： レポジトリのコンテンツを記述するのに使うオプションのフィールド

Public / Private： レポジトリを視覚化する設定

Initialize this repository with a README： プロジェクトの詳細を記述したREADMEを使ってレポジトリを初期化

Add .gitignore： トラックされるべきではない全てのファイルを示すファイル

Add a license： プロジェクトにライセンスを追加 (GNU、OpenBSD…）

4DプロジェクトにGITを実装する

これでGITがインストールされてリモート・レポジトリが作成されたので、ローカル・レポジトリの作成へと進み、4Dデータベースから生成されたプロジェクト、あるいは新しく作成された4Dプロジェクトを実装することが次のステップとなります。この場合、ローカル・レポジトリは4Dプロジェクト・フォルダ内で起動されます。

新しく生成されたプロジェクト・フォルダへ誘導して、右クリックで”Git bash here”を選択します。

これでGIT bashターミナルを開き、GIT操作を実行するコマンドの入力が可能になります。

次のステップはローカルのレポジトリを初期化することです：

git init は空のローカル・レポジトリを作成します。シンプルにテンプレートファイルとサブディレクトリを含む.gitディレクトリを作成しているだけです。

git.init は4Dプロジェクト・フォルダを実行したので、GITはすでにトラックされないファイルのリストを持っています。

git status コマンドを実行すると、ローカル・レポジトリに追加できる修正されたファイル（あるいは新しいファイル）が全て表示されます。結果は、３つの要素がまだインデックスに含まれていないことを示しています。これは、これらの要素を使った変更が現時点でまだコミットできないことを意味します。そのためには、まずこれらのフォルダとファイルをステージング（インデックスへの追加）します。

git addコマンドは、次のコミットに対してワーキング・ツリー内で使用可能なファイルをステージング領域へ導入することによって準備します。

git addパラメータ：

git add ＜directory＞： 特定のディレクトリの全ファイルをインデックスに追加します。

git add ＜file＞： 特定のファイルをインデックスに追加します。

git add .： 新しいファイル、削除されたファイル、あるいは変更されたファイルを探してワーキング・ディレクトリ全体を捜査し、それらのファイルをインデックスに追加します。

git status をもう一度実行して、ファイルがコミットされる準備ができたことを表示します。

Git commitは、ステージング・エリアで利用可能な全てのファイルをローカル・レポジトリに送信し、インデックスを解放します。Commitは、作業ディレクトリ内の要素のスナップショットです。しかし、GITはCommitが行われる度に全てのファイルをコピーするのではなく、あるレポジトリ・バージョンから別のレポジトリ・バージョンへの一連の変更として含めます。

Git commit -m “message”： -aパラメータは、有効期間内に一度追加されたファイルからレポジトリに変更をコミットする場合に便利です。

ワーキング・ディレクトリ内のファイルがローカル・レポジトリへのコミットに成功したので、次のステップはこれらの変更をリモート・レポジトリへプッシュしてチームの他の人と共有することです。１つ重要なことは、リモート・レポジトリに変更をプッシュする前に、チームメンバーが最近実行した変更があるかどうかを事前にチェックすることが不可欠であると考えられます。しかし、これを行う前に、リモート・レポジトリをローカル・レポジトリにリンクすることが優先事項です。

Git remote add origin “link_to_repo”： ”origin”という名称のリモート・レポジトリを追加します（初期設定では、originはリモート・レポジトリの定義に使われていましたが、それ以外の名前は問題になりません）。レポジトリのリンクのコピーは下記のようにできます：

GitHubアカウント / 上部右アイコン / repositories / created_repo.からリンクできます。

Git statusは、ローカル・ブランチをリモートの対応部分（リモート・トラッキング・ブランチ）と比較しますが、これは常にリモート・トラッキング・ブランチが最新であるということではありません。それを確認するには、git fetchを実行して、実際にリモート・トラッキング・ブランチをアップデートすることで、ブランチがリモート・レポジトリ（リモート・ブランチ）とともに最新にすることが可能です。

実行すると、ワーキング・ツリーはコミットもなく、可能な変化もなく、クリーンであることが表示されますが、このケースでは、ローカル・レポジトリに存在しないreadmeファイルを使って、新しく作成されたレポジトリが初期化されました。git pushを実行すると、まさに読んで字の通りのエラー・メッセージが生成されます：

自動生成されたREADMEは、リモート・レポジトリに存在しますが、ローカルには存在しないので、これは特別なケースです。次のステップでは、リモートからの変更でローカル・レポジトリを更新します。これは基本的に次のコマンドを使って行います。

Git pull origin remote branchname： ローカル・レポジトリを使ってリモート・レポジトリから変更をダウンロードしてマージします。

あるいはより洗練された方法として：

Git fetch remote branchname： リモート・レポジトリからコンテンツをダウンロードしますが、ローカル・レポジトリにはそれらを統合しません。

＋

Git merge origin/remote branchname： git fetchによって取ってきた変更をローカル・レポジトリにマージします。

新しく作成されたレポジトリがREADMEファイルで初期化された場合、シンプルなgit pullあるいはgit fetch + git mergeは、リモートと同じファイルを使っているローカル・レポジトリを更新できません。関連性のない履歴を持っているからです。

これを修正するには、git pullコマンドを使ったパラメータ（フラッグ）が必要です。

Git pull origin remote _branchname -allow-unrelated-histories： これは、レポジトリ間の関連性のない履歴を無視してリモート・レポジトリから引き出されます。これは回避策としてのみ使われるべきです。

最初のプルは完了しましたので、README.mdファイルがプロジェクト・フォルダに追加されたことが分かります。プロジェクトをリモート・レポジトリにプッシュすることが可能になりました。

全てのファイルの送信に成功していることを確認するためにリモート・レポジトリを見てみましょう。

重要：以下のGITコマンドはローカル・ブランチとリモート・ブランチをリンク（逆流）するために必要となりました。このケースでは、ローカル・マスター・ブランチをリモート・マスター・ブランチにこのようにリンクします：

一度実行されると、マスター（リモート・メイン・ブランチ）からプッシュやプルがとても簡単になり、シンプルにgit pushあるいはgit pullをタイプするだけで追加パラメータが無くてもうまくいくはずです。

GItでは、ブランチはシンプルに特定のコミットへのポインターとして定義することができます。機能がまだ開発フェーズにあるときはいつでも、マスターとは別のブランチに変更をプッシュすることは、マスターが常にテスト済みの製品対応バージョンしか保持していないことを考えれば、とても賢明な方法と言えるでしょう。ブランチには２つのタイプがあります：

• ローカル・ブランチ： ワーキング・ツリー内でローカルに可能なブランチ
• リモート・ブランチ： セントラル・レポジトリ上のリモートの対応箇所にローカル・ワークするブランチ

新しいブランチを作成して変換するには、下記のコマンドを使います：

• Git branch branch name
• Git checkout branch name

Git checkout -b branch name も２つのコマンドと同じ効果を持っています。

機能が運用準備されれば、この方法でフィーチャー・ブランチをマスター・ブランチとマージすることができます：

Git merge source branch

フィーチャー・ブランチとマージする前に、必ず（その中にいる状態の）マスター・ブランチをチェックアウトしてください。この場合、フィーチャー・ブランチは変更されません（したがって「すでに最新の状態」）。

サンプル・データベース

このテクニカル・ノートでは、サンプル・データベースも提供しています。動作環境によって異なる状況や複雑さの詳細を説明しています。

Demo 1: リモート・レポジトリとの相互通信

１. プロジェクト・フォルダに移り、git bashを起動（右クリック） ２. Git iniを使ってgitレポジトリを初期化 ３. Git remote add origin “link_to_repo”を使ってリモート・レポジトリを追加 ４. Git branch -set -upstream-to = origin/master masterを使って、リモート・ブランチ・マスターへアップストーム（逆流）のリンクを追加 ５. 以下を使用して、プロジェクト・ファイルからローカルでリモートのレポジトリに対してファイルを追加、コミットそしてプッシュします：

• git add
• git commit -m “committing our project folder”
• git push

git statusコマンドを実行し、ブランチの状態（全てがコミットに成功していること）を確認します。

もしも全てのオペレーションが実行に成功している場合は、このような結果になるはずです。

６. サンプル・データベース、my_4D_project (my_4D_project.4DProject)をv17R5で開きます。 ７. メソッド “meth_alert_1”にコメントを加えて修正しましょう。

git statusを実行して、ワーキング・ツリーに生じた変更を捜査します。

８. では、ステップ5と同じコマンドを実行して修正を保存しましょう。（コミット・メッセージの変更を試してみます。）一度実行すれば、git statusはトラックされない、あるいはステージされないファイルを返します。

９. 例えば最後のコミットが不完全な場合、それを元に戻すには以下のコマンドが必要です：

git reset -hard parameter, パラメータは下記のようになります：

Git reset -hard HEAD~1：これは、HEADが現在のブランチを参照することによって、最後のコミットをリセットします。

Git reset -hard commit_number：これは、パラメータとして渡された数のコミットまでの全てのコミットをリセットします。最初にやることは、以下のコマンドを使って全てのコミットのリストを得ることです：git log

結果には、ローカル・レポジトリで実行された全てのコミットが重要な詳細（著者、日付、コミット番号…）とともに表示されます。以下を実行するとワーキング・ディレクトリを以前の状態にリセットします：

Git reset -hard 66148936b9a91903ca2ce2d188a6dddcd3980f5d

リセットされるとコメントが消去されることが分かります。

現在の状況にあるメソッドを使ってリモート・レポジトリをアップデートするのには、最後のプッシュが必要です。シンプルなgit pushを実行しても動作しません。なぜならローカル・ブランチがリモート・ブランチの背後にあるからです（コミットがリセットされたためです）。

メッセージは、git pullの実行を提案していますが、ローカルで実行されたリセットの効果を無効にしてしまいます。これを解決するにはシンプルに下記を実行します：

Git push -force： tipの設置を無視しながら、ローカル・レポジトリからリモート・レポジトリに変更をプッシュします。

Demo 2: コンフリクトのマネジメント

複数の開発者が共同作業を行うような環境でバージョン管理システムを使用する場合、最終的なコンフリクトの管理は日常的なジレンマとなります。4Dメソッド/フォームとGITを使用したコンフリクトの例をみてみましょう。これを実行するには、データ・フォルダ　(my_4D_project.4dbase)を複製してセカンダリ・ユーザー/ローカルgitレポジトリをシミュレートする必要があります。

一度重複したら、複製のデータベースをv17R5のセカンド・インスタンスとして開きます（v17R5フォルダを複製する必要はありません。exeファイルをもう一度実行すれば新しいインスタンスを開きます）。

１. 新しいプロジェクト・フォルダに行き、（右クリックで）git bashを実行します。 ２. コンフリクトのシミュレーションのために、新しいデータベースのmeth_alert_2を開き、以下のように修正します：

Git statusを実行すると、修正されたメソッドを探します。これらの新しい変更をコミットしてプッシュしましょう。

３. 同時に、ユーザー１が同じメソッドを修正すると決めたので、最初のデータベースの同じメソッドの修正が下記の通りになります：

４. 新しい変更をコミットしてプッシュします。

リモート・レポジトリが新しいコミットを持っているかどうかを確認するためにgit fetchを実行するのを忘れたことが重要です。この場合、そうせずにプッシュしようとするとエラーが発生します（更新が拒否されました…）。

５. 提案されたように git pullを実行するとコンフリクトが発生します。下記をご覧ください：

ユーザー２によって行われた変更をローカルの変更にマージすることは、自動的には解決できませんでした。また、masterという単語がmaster|Mergingに変更されたことにも注意してください。 コンフリクトの解決方法には、次の３つの方法があります：

• Gitのマージツール：GITインストールで実装されるツール。他の多くのマージツールが使用可能で、ダウンロードしてGITに統合することができます。

• マニュアルのマージ：4Dデータベースから全ての要素がテキスト・ファイルとして生成されるので、シンプルなテキスト・エディタ (Notepad…)でコンフリクトのマージは可能です。

• 4Dエディター：これはメソッドにのみ有効です。そのjsonファイルはエディターに正確に表示されるからです。サンプルのフォームは表示されません。そのjsonファイルが4Dによってインタプリタにされてレンダリングされなければならないからです。

６. 三番目のメソッド（4Dエディター）を見ると、このケースではメソッドのコンフリクトを扱っています：

メソッド・エディター内では両方のバージョンが有効であり、HEADがローカルの変更を参照していることと59880bc7363992f3b8b7c9381ccb8521d0a81cdがユーザー2のコミット番号を表していることに気づきます。このコンフリクトを解決するには、シンプルにコードの正確なパートを保つことです。

結果的にコンフリクトはシンプルで、コードの正確なパートを拾い、下記のコマンドを実行してコンフリクトの変更とマージを保存します：

一度実行すれば、ユーザー２はgit pullを実行するだけで、ユーザー１による新しい変更を得ることができ、両方のユーザーがmeth_alert_2の中に同じコードを持つことができました。

次は、git mergetoolを使ったメソッドのマージの最初のコンフリクトを素早く見てみましょう。フォームのコンフリクトが発生してしまい解決が必要であると仮定します。（同様にメソッドのコンフリクトも発生します。ステップ2, 3, 4, 5をご覧ください。）ユーザー１とユーザー２の両方が、4Dフォームの”frm_ok_1”で１つのokボタンを含めて修正しました。以下をご覧ください：

ユーザー１

ユーザー２

ステップ２から５に続けて、下記のステップがgit mergetoolを使ってコンフリクトを解決します。

エンターキーを押します：

スクリーンが４つのゾーンに分割されます：

• 上段左：ローカル・フォームの変更を示すjsonファイル
• 上段右：リモート・フォームの変更を示すjsonファイル
• 上段中央：オリジナル・フォームを示すjsonファイル
• 下段：コンフリクトが解決した後のローカルで保存される最終的なjsonファイル

コンフリクトを解決するために、下段を見てみましょう（修正はここで行われます）：

以前のサンプル（メソッド）と同様に、jsonはタグで区切られています (««HEAD and »»» commit_number)。Headタグから”======“までがローカルの変更を表し、リモートの変更は”======“で始まりコミット番号のタグまでになります。

ファイルからタグを削除しながら、テキストの希望するパートを保存するだけです。最終的な結果は下記のようになります：

修正された点：

• タグを削除
• On versionを保持

Demo 3：ブランチとスタッシュ（隠す）を使う

ブランチは明らかにGITの主要な機能で、このデモでは基本的なブランチ機能と操作について説明します。

１. プロジェクト・フォルダへ移動して、git bashを実行（右クリック）
２. 新しいブランチを作成してfeature1と名付けます

現在のブランチの名称がチェックアウト時に変更されることに注意してください。

• git branch branch name：新しいブランチを作成してfeature1と名付ける
• git checkout branch name：git ブランチ間のナビゲーションを可能にするように設計されたgitコマンド。特定のブランチをチェックアウトすると、その特定のブランチに保存されているバージョンに適合するようにワーキング・ディレクトリをアップデートします。
• git checkout -b branch_name：新しいブランチを作成し操作する（チェックアウト）

３. 新しいメソッドを作成して”new_feature_1”と名付け、あるコードを入力します。

４. ローカルとリモートの両方の変更を保存するには、下記を参照してください：

次にリモート・レポジトリに変更をプッシュします。しかし、まだfeature1という名前のリモート・ブランチはありませんので、以下のように行います：

Git push -set-upstream origin feature1：ローカルの変更をリモート・レポジトリにプッシュし、新しくfeature1という名のブランチを作成し、それをそのローカルのレポジトリにリンクします。

新しいブランチはリモート・レポジトリには作成されています。Feature1にはマスター・ブランチと同じファイル+新しく作成されたメソッド (new_feature_1)が含まれます。

また、マスター・ブランチへ切り替えると、新しく作成されたメソッドは存在しないことに注意してください。

new_feature_1メソッドはマスター・ブランチにはまだ存在しません。マスターを変更して、それらを保存しても、feature1ブランチには反映されません。一方から他方へこれらの変更を行う唯一の方法は、マージです。この方法では、各ブランチは想定されるコンテンツのみ含まれ、他には何も含まれません。

５. マスター・ブランチを使って、feature1に変更をマージします：

Git merge feature1：feature1からマスターへ変更をマージします。new_feature_1メソッドは4Dメソッドへ追加されます。

：開発者が最後の２ステップ（４と５）をスキップしてしまったと想像してください。様々な理由で起こり得ることです（コミットの準備ができていない、featureコードが不完全…）。その後、問題点などを修正するためにマスター・ブランチに切り替えます。最初は大丈夫に見えますが、featureブランチから全てのメソッドやファイルを理解しようとすると、マスター・ブランチからは接続できても間違ったブランチにコミットして、プロダクションの失敗やコンフリクトを起こして終了することがあります。</font>

６. featureブランチをチェックアウトして、4Dの中に新しいメソッド、new_feature_2を作成します。マスター・ブランチへ戻り、ブランチのコンセプト全体に対する反対するメソッドがまだ存在することに留意してください。

これは、ブランチ間で切り替えることが必要となるならいつでもgit stashを使って、簡単に保護できます。一方でまだ変更が保留されているのは保存されません。git stashはワーキング・ディレクトリ+インデックスの現状を記録し、ローカルの修正を保存します。

７. git stashはGITでトラックされるファイルを保存するだけです。事前にgit addを実行する必要があります。

８. もう一度マスター・ブランチに切り替えると、メソッドは隠されたため、もう存在しません。

９. 保留している機能を戻す準備をするには、フィーチャー・ブランチに切り替えてgit stash applyを実行して4Dメソッドのnew_fearure_2を得るようにします。

１０. フィーチャー・ブランチは簡単に削除できます：Git branchi d feature1。削除される前に異なるブランチ上にある必要があります。

終わりに

このテクニカル・ノートでは、GITアークテクチャとその機能について全般的な情報を提供しています。加えて、開発者が経験したことの内容な本物そっくりの状況やコンフリクトが、特定の4Dのコンテキストや使い方に合わせて、段階的に詳細に説明されています。

基本となるGITコマンドの多くは、4D開発者が作業環境で直面するであろうことを描写するたくさんのシナリオで使われていますが、さらに高度なコマンドと技術を駆使して、あらゆるディテールを満たし、技術に精通したあらゆるシニア開発者の渇望を満たすことができます。

新しい4Dファイル・システムでバージョン管理を実装することができ、新たに提供された柔軟性が最大限に活用され、コラボレーションの新しい時代の基礎となります。

資料

Convert an existing database into a Project. (2019, April 24). Retrieved May 22, 2019, from https://blog.4d.com/convert-an-existing-database-into-a-project/

4D PROJECT : EMBRACE A NEW ERA OF COLLABORATION. (2019, April 24) Retrieved May 23, 2019, from https://blog.4d.com/4d-projects-embrace-th-era-of-collaboration/

Git commands. (n.d.). Retrieved May 24, 2019, from http://git-scm.com/doc

Git workflow. (n.d.). Retrieved May 24, 2019, from https://stackoverflow.com

Git Credential Caching on Mac OS X. (2013, August 5). Retrieved May 22, 2019, from http://tech.lds.org/wiki/Git_Credential_Cachnig_on_Mac_OS_X