WEBアプリケーション開発のためGit・Sourcetreeを学んだのですが、非常に便利なツールだということが分かったので主な有用性と使い方・一見難解な"Git言語"について簡潔に学習してみました。
Gitの利点
Gitの利点は、誰がいつ、どのファイルを変更したかを管理できるようになることです。またバージョン管理をすることで「ファイルを消しちゃった！」というケアレスミスを予防できます。
Gitを用いればファイルを管理する集中型管理システム・分散型管理システムを簡単に導入することのも利点です。
- 集中型管理システム→システムを必ず中央システムにつなぐ
- 分散型管理システム→ローカルなリポジトリーを作成する。オフラインでも作業できる他、ファイルを共有することでリモートリポジトリーの復旧が容易になる
Git機能の有効活用
複数PCにリモートリポジトリーのクローンを作り、複数人でのマルチタスクや個人での仕事場・リモコンワークでの平行作業に活用できます。リモートリポジトリ－を提供しているサービスとしては Bitbucket・GitHub 等がある。外部には出せない社内プロジェクトはBitbucket、オープンソース系プロジェクトはGithubで管理するのがおススメとありました。
Git言語を理解する
Gitを使う障壁となるのが、一見難解な専門用語（笑）の理解です。ここでは「Git 基本の使い方33」を参考に"Git言語"の使い方をまとめてみました。
-
リモートリポジトリ（中央リポジトリ）
→プロジェクトの中心となる「完成品」を集めるための場所。
プロジェクトの管理者がGithub・Bitbucketなどのリポジトリを提供する
サービスで管理する。 -
ローカルリポジトリ
→リモートリポジトリを複製して必要なファイルを個々人のPCで作成（「部品」）する。
通常ローカルをリモートに反映するにはリモート側の管理者の確認が必要。 -
作業ツリー
→ローカルリポジトリーの中にあるファイル。ステージに追加しないと変更内容には反映されない。 -
ステージ
→ローカルリポジトリー中のファイルの内、コミットするとリモートリポジトリーに送信されるファイル -
コミット
→リモートリポジトリーにステージ上のファイルを送信すること。
コミットには原則、変更内容を伝える「コミットメッセージ」を書く。
コミットは「ステージに追加→コミット」の2段階で行う。
また、コミットは1課題・1タスクごとにこまめな修正ができるようにする。
ファイルに関しては新規追加・削除をするタイミングでコミットする。
変更箇所をコミットすると、後でその変更箇所を検知することができる。
コミットメッセージ→コミットのタイトル、概要＋変更の目的
※「変更をすぐにmasterにプッシュする」を選ぶとマスターとなるリポジトリに即座に反映される。 -
クローン
→リモートリポジトリを複製して自分のPCのローカルリポジトリにする -
フォーク
→リモートリポジトリを複製して別のリモートリポジトリにする。通常ローカルリポジトリはオリジナルのリモートリポジトリではなく、フォークした「自分用」のものにコミットするのが冗長的で便利となる。 -
プル
→フォークしたリモートリポジトリをローカルリポジトリに複製する。
-
プッシュ
→ローカルリポジトリの変更を自分用のフォークしたリモートリポジトリに反映する。プルとプッシュの繰り返して自分用のバックアップと作業の進捗ができる。 -
プルリクエスト
→「自分用」のリモートリポジトリをオリジナルに反映するよう要請する。作業が完了したら「変更を確認して反映して下さい」と管理者に伝えるのに使う。 -
フェッチ
リモートリポジトリの最新状態）を取得する。 -
マージ
ローカルリポジトリをフェッチした内容に変更する。プルはフェッチとマージを順に行うGit上の動作となっている。 -
オリジン
リモートリポジトリのある場所
Git・Bitbucketで作業環境を準備する
共同作業をするための環境をリモートリポジトリ・ローカルリポジトリで管理する方法
①中央リポジトリを作成
②中央リポジトリをクローンしてローカルリポジトリを各PCに作成
③ファイルをローカルリポジトリの管理下にする
④ローカルリポジトリを初回コミット→プッシュし、ファイルを中央リポジトリと同期する
⑤準備完了
ファイルを変更したらコミットしてバグ等を起こさない安定版・追加で機能を追加した不安定版のテストを両方保管する、という使い方ができますね。