5分後にデキるようになっていること
- Githubを使って、文書ファイルをチームメンバーとレビューし合える
- Github上で新しいファイルの作成や編集ができる
このページの対象者
このページは以下の様な方を対象にしています:
- Github/Gitを使って文書を共有したい
- 今まで利用規約やプライバシーポリシーなどの文書を作成するのにWordを使っていた
- 今までWordの校閲機能は使ったことがあるが、流行りのGitとやらを使ってみたい
- チームの開発者がGithubを使っていて、そこに混ざりたい
- 共有フォルダの中が日付の付いたコピーフォルダでいっぱい
- 共有フォルダの中身を間違って消してしまったことがある
- 共有フォルダから最新だと思って開いたファイルが何故か古いものだった
- やたらとファイル名に「最新版」と付けたがる
- 黒い画面を使うなと医者に禁止されている
このページで説明しないこと
以下の事項はこのページでは説明しません:
-
gitの説明,gitコマンドの説明 - Githubのアカウント/レポジトリの作り方
- チームにGithubを導入させるノウハウ
- マークダウン記法の書き方
- 消してしまった共有フォルダのファイルの復元方法
このページを読むための前提作業
- Githubアカウントを作成して、メールアドレス認証を完了しておいてください
- Githubのレポジトリをあらかじめ作成しておいてください
- レビューを担当してくれるメンバーがいるとわかりやすいです
用語説明
注意 この用語説明はGithub初心者向けなので、わかりやすさを優先しているため正確ではないものがあります。
- Github / ギットハブ
-
gitというツールをWeb上で使えるようにしたサービス
-
-
git/ ギット- ファイルのバージョン管理をするツール
- ソースコードやプライバシーポリシーなどテキストを管理するのに向いている
-
master/ マスター- Githubや
gitで「最新の状態（本流）」を指し示す
- Githubや
-
branch/ ブランチ- フォルダやファイルの「状態」を指し示す
-
masterは 「マスターブランチ」の略 - 「
masterからブランチを切って作業する」のように使う -
master（本流）から分岐することから 「ブランチ（枝分かれ）」と呼ぶ
-
commit/ コミット- ブランチ上で行ったファイルの変更の履歴
- ファイルを変更すると自動的に「コミット」される
-
Pull Request/ プル・リクエスト- ファイル作成・変更をしたブランチを他メンバーにレビューしてもらうための差分を作る作業
- 1つのプル・リクエストは1つのブランチに対応し、複数のコミットを含む
- プル・リクエスト中は
masterブランチへの変更途中で、まだ反映されていない - レビューが完了すると「マージ」という作業を行うことで
masterブランチへ反映することができる - そのため、複数人で同じファイルを編集しても、「コンフリクト」する危険が少ない
- コンフリクト / 競合
- 同じファイルを同時に複数のメンバーが変更すると発生することがある
- 自動的に解決することはできずに、手動でどちらかの差分を修正しないと作業を続けられなくなる
-
merge/ マージ- あるブランチの変更を他のブランチ（大抵の場合
masterブランチ）へと一気に反映する作業 - 「コンフリクト」があるとマージできない
- あるブランチの変更を他のブランチ（大抵の場合
- レビュー
- Github上では「特定の行」に対してレビューを行うことができる。
- Wordの校閲機能に相当する
Github入門
いくつかのステップに分けてGithub上でのファイル作成・変更を解説していきます
二人の登場人物がいます
- Aさん (
ファイル作成・変更者) - Bさん (
レビューワー)
ステップごとに役割があるので、「今はどちらの担当か」を意識して読み進めてください。
1. 新しいファイルの作成（A.ファイル作成・変更者）
ここでは、ファイル作成・変更者 が、「新しくプライバシポリシーを作成する」という業務を想定して進めていきます。
Githubのページ上から新しいファイルを作成して プル・リクエスト を作るまで
- TOPページから新しいファイルを変更するページヘ移動
- 新しいファイルのタイトルと内容を記入
- プル・リクエストを作成します
- タイトルと概要を作成するとレビューワーに優しくなります
- プル・リクエストの作成が完了しました
- コミットの確認と、
- ファイル変更点を確認しておきましょう
次は、レビューワーにレビューを依頼します。
2. 変更点のレビュー（B.レビューワー）
次はレビュワー（レビュー担当者）の作業です。
残念ながら、変更点にミスがあったみたいです。
コメントをつけて指摘をしてあげましょう。
- ファイル変更画面（「Files changed」と書いてあるタブ）からレビューしたい行をクリックします
- 行に対してコメント
- コメントが完了したら、変更者に伝えてあげましょう
3. レビューの指摘の修正（A.ファイル作成・変更者）
レビューされたので、変更者が修正します。
- 修正するには、左上の「鉛筆マーク」を押します
- 指摘された部分を修正します
- 修正した概要を記入すると、レビューワーが楽になります
- プル・リクエストのタイムラインに追加されました
4. 再レビュー（B.レビューワー）
修正されたので、もう一度レビューします。
今回は一度でレビューが完了しますが、実際の業務ではこのやり取りが複数回往復します。
- 再度レビューします
- 今回で修正が完了したので、「OKです」と伝えてあげましょう
5. masterへマージ（A.ファイル作成・変更者）
レビュワーのOKがでたので、 master へ反映して作業を完了です
- 修正点がすべて直ったのでマージ作業に入ります
- 「Confirm merge」というボタンを押すと、
masterブランチに変更点が反映されます
-
masterブランチのファイル` が反映されているか確認しましょう
6. 次の変更作業を始める
次の作業を始める場合は、今までと同じ流れを繰り返せばOKです
- 「鉛筆マーク」からファイルを変更して
- プル・リクエストのタイトルと概要を記入し、新しいブランチを作成し
- 変更点を確認して、プル・リクエストを作成します。
- この後の流れは、最初と同じです。
Github / git の注意点
- 実は、ブランチやプル・リクエストを作成せずに
masterブランチを直接変更してしまうことは可能です。ただし、レビューの意味がないのでやめましょう - Github上で行ったファイル作成・変更はコミットとして永遠に残ってしまいます。 過去の変更を削除することはできません 。パスワードや個人情報は記入しないように注意しましょう
以上です
わかりにくい点があれば、ご指摘お願いします。