更新日 2021.07.30

#7 Gitでファイルを共有する

ここからは、実際にファイルを編集していく際の操作を学んでいきましょう。

git add

ワークツリー内で変更がなされたファイルを指定し、インデックスへ追加する処理です(「ワークツリー」及び「インデックス」に関しては後述)。
ファイルやディレクトリに対して編集作業を行った後、その作業内容を履歴として残す為に行う最初の処理です。

①新規.txtファイル作成
リポジトリ内にテキストファイル(.txt)を作成しましょう。

名前:個人名
年齢:任意記入
趣味:任意記入

内容はこの程度で良いです。保存する際のファイル名は「個人名_GIT練習.txt」にしてください。

②sourcetree画面左側メニューバーより、「ファイルステータス」をクリック。
③作成・編集した.txtファイルにチェックを入れる。
以上の手順でgit addは完了です。

git commit

インデックスへ追加されたファイルを、変更履歴としてgitに登録する処理です。
git addされた編集内容をgit commitして初めて、あなたの編集は変更履歴としてGitに登録されます。手順は簡単です。

①編集内容を確認後、コミットメッセージを記入。
コミットメッセージは、コミットを行う上で必須の入力項目です。どの様な編集を行ったのか、簡潔に記入しましょう。
画面下部「コミットメッセージ」欄に記入を行います。
今回は「自己紹介_個人名」と簡潔に記入しておきましょう。

②コミットメッセージ記入後、コミットボタンクリック。
この時、必ず
  • 現在チェックアウトしているブランチは正しいか
  • コミットする対象ファイルは間違いないか
  • コミットする対象ファイルの編集内容は間違いないか
ここで再度チェックしておきましょう。
上述した通り、コミットは変更履歴を登録する作業です。
登録内容に誤りが無いか、必ず確認する癖をつけてください。

問題が無ければ画面右下の「コミット」ボタンをクリックして、git commit完了です。

「ワークツリー」とは

git管理下に置かれた、実際に作業しているディレクトリのこと(今回の場合は、practice_git配下を指します)。
リポジトリ上で新たにファイルが作成されたり、既存ファイルを編集したりした場合、それらはいきなりリポジトリに登録はされず、暫定的なファイル置き場であるワークツリーに保存されます。
また、ワークツリーとリポジトリの間には、インデックスと呼ばれる場所が用意されています。

「インデックス」とは

変更したファイルを、リポジトリへコミットする準備をするための場所です。
編集したファイルがgit addされるとこの場所へ来ることになります。
この場所で編集したファイルを取りまとめ、コミットメッセージを添えてコミットすることにより、ローカルリポジトリ上に初めて「変更履歴」として登録されることになります。

「git push」とは

ローカルリポジトリにて登録された変更履歴を、リモートリポジトリへ共有する処理です。
前項のgit addからgit commitの処理で、あなたが編集した内容は無事Gitへ登録されました。
ですが、それはあくまで「あなたのローカルリポジトリ」上での出来事です。
リモートリポジトリには何も登録されていない = 他の開発・製作者へ展開・共有されていません。
そこで登場するのが「git push」です。

実行すると、ローカルリポジトリ内の変更履歴(※正確には、「ローカルリポジトリ上で更新されているブランチ」)がリモートリポジトリにアップロードされ、
リモートリポジトリの変更履歴がローカルリポジトリの変更履歴と同じになります。

①sourcetree画面上部「プッシュ」をクリック。
プッシュ先のブランチは、必ず「自身が変更作業を行ったブランチ」を指定してください。
チェックボックスには初期設定のまま触れずに「プッシュ」ボタンをクリックすれば、git push完了です。
画面右側のグラフに注目してください。
一番上部のアイコンに「ブランチ名」だけのアイコンと「origin/ブランチ名」のアイコンが2つ並んでいると思います。
この「origin」とついているアイコンが、現在のリモートリポジトリ上のブランチの状態を示しています。

今回プッシュを行なったことにより、ローカルリポジトリ上の変更履歴=変更が為されたブランチがリモートリポジトリ上にも反映されたということになります。

「プルリクエスト」とは

開発者が行った変更の履歴を、他の開発者に通知する機能です。
この機能は、元々Git自体に備わっている機能ではありません。
Git用のアプリケーションが提供している機能なのですが、多くの開発・制作現場で使用されています。

プルリクエストを利用するメリットとして、
変更履歴の共有・ソースのレビューをタスク化して管理する事により、その時発生したやり取りを記録しておく事が出来る点が大きいです。
サービス開発において、これが非常に重要なエビデンスとして活用出来る場面も有りえますし、
第三者からのソースレビューは開発担当者が気づけなかったバグの発生を未然に防ぐ事が出来ます。
試しに、プルリクエストを「発行」してみましょう。

①Backlogの該当プロジェクト内「GIT」をクリック。

②該当リポジトリから「プルリクエスト」をクリック。

③画面右側「+」ボタンをクリックし、プルリクエスト発行画面へ遷移する。

④記入すべき全ての箇所に記入する
作業ブランチ
あなたがpushしたブランチを指定しましょう。

マージ先のブランチ
基本的には、作業ブランチの元ブランチを指定します。
今回はmasterブランチからブランチを切っていますので、masterブランチを指定しましょう。

タイトル/メッセージ/担当者
メッセージ欄にレビューしてもらいたいポイント等を書いておくと良いですね。
担当者欄にはあなたと一緒に学習している相手を指定しましょう。

お知らせしたいユーザ
開発・制作現場にもよりますが、基本的には責任者の人やレビュアーを指定します。
今回はあなたと一緒に学習している相手を1名指定しましょう。

上記項目を入力すると、画面右下の「プルリクエストを追加」ボタンが活性化しますので、全て入力したらクリックしましょう。
これでプルリクエストの発行が完了しました。

プルリクエストの承認

次は発行されたプルリクエストを承認する手順をみてみましょう。
この承認の作業は基本的に発行した本人が行わず、レビュアーと呼ばれる、変更内容等に不備がないかを確認する人達が行うことが一般的です。
逆を言えば、経歴の浅いエンジニアやデザイナーが変更内容の正否を判断しきれずに、不用意な承認を行うことは危険です。

ですが今回は、承認の手順を学習するために、発行されているプルリクエストを承認してみます。

①プルリクエスト画面から、発行されているプルリクエストを選択。
プルリクエストの詳細画面へと遷移します。

②画面下部の「ファイル」タブをクリックすると、変更されたファイルが表示されます。
承認する前に必ずここを確認しましょう。
変更内容に誤りや、バグが存在する場合はここでプルリクエストを却下することができます。

③変更内容を確認し、問題が無ければ「マージ」ボタンをクリックします。

④プルリクエストを発行したユーザにコメントを残すことができます。
コメントを記述したらもう一度、「マージ」ボタンをクリックしてください。

⑤プルリクエストのステータスが「Merged」に変わりました。
この状態になればプルリクエストの承認は完了です。
発行したユーザの変更は無事変更履歴として登録されました。
コピーしました
RSS https://cbc-study.com/rss.xml 
質問などあればSlackで! 誰でも無料でできます。
勧誘とかしないよー
cbc-study.slack.com