Git、GitHubなんて今さら聞けないですよ【名前だけは聞いたことはありますって言う超初心者向けwww】Forインフラ開発者向け
今までは、ソースコードをバージョン管理システム(SCM:Software Configuration Management)で管理するのだから"Git"は、プログラマーが覚えるべき技術だと今までは考えてました。
ですが今の時代、インフラだって「Infrastructure as Code」とコードを書くことが多くなりつつあります。
もちろん、スクリプトだって、ちゃんとバージョン管理をする必要もあります。
また、インフラSEだってただ単にSCMをインストールしプログラマーに提供するだけでなく有効に活用することでプロジェクトを円滑に遂行することも必要と考える。
もちろん、バージョン管理システムを導入することで業務が増えてしまっては本末転倒だとは思いますが・・・。
ましては、"Git"なんてプログラマーの間では一般的かもしれませんがインフラ開発者(私だけかもしれませんが…。)が今さら聞けません・・・w
なので、"Git"とは何なのか？からどうやって運用すべきかのかを調査してみました。
※バージョン管理システムだけでは、ソースコードやコミットメッセージに現れない「ある課題の変更がどのコミットでソースコード上に反映されているか」、「ソースコード上の変更がどういった理由や背景で行われたか」が分らないため、ITSやBTSも同時に活用する必要性があると言われています。
ただし、業務を増やさないためにもそれこそ最初にどのように運用するかルールを決めるのがキモになる。
私は、プロジェクトがウォーターフォール型ならばExcelでWBSと課題管理をしていれば十分だと思いますが・・・w
ITS/BTSに興味がある方は、まず以下を参照して下さい。
(後々で調査レポートを書くかもしれません・・・w)
http://www.atmarkit.co.jp/ait/articles/1301/30/news032.html
●まず、"Git"とは何なのか？
一言で説明すると、"Git"とはバージョン管理システム(SCM:Software Configuration Management)を指している。
バージョン管理システムとはソースコードに対して加えられていく変更について、
・「誰が」
・「いつ」
・「何を変更したか」
というような情報の記録をするシステムのことだ。
このシステムは、過去のある時点の状態の復元や現在と過去のファイルの内容の差分を確認することを可能にしてくれる。
今までは、集中管理方式の「CVS」「Subversion」が多く利用されていましたが、複数人での分散開発の容易さやパフォーマンスに優れた分散管理方式の「Git」「Mercurial」などがスタンダードになりつつあります。
ただし、Gitだけではバージョン管理を複数の人で共有することができないんですよ。
もちろん、Gitサーバを自分で構築すればいいんですが、管理とか面倒ですよね。
そこで出来たのがGitHubです。
●じゃあ、"GitHub"とは？
"GitHub"は、ソフトウェア開発プロジェクトのバージョン管理を共有できるホスティングサービスです。
ようするに"Git"のホスティングサービスです。
この、"共有できるホスティングサービス"っていうのがキモなんです。
また、ソフトウェアのプログラム開発をしていると、「他人のソースコードを見たい」「自分のソースコードをオープンにして色々な人に見てもらいたい」といった要望出てくると思います。
"GitHub"では、バージョン管理機能以外にもその要望を叶える簡単なバグ管理機能やSNSの機能等の「ソーシャル」を"GitHub"は提供しています。
"GitHub"は無料でも有料でも、無制限でリポジトリを作成できますが、無料プランの場合、使える領域が0.30GB（300MB)までとなっています。
それと、ちゃんと押さえておかなきゃならないのは、無料プランではリポジトリを作ると自動的にインターネットで公開されます。
そのため、業務用のプロジェクトを立ち上げる場合は、非公開のプライベートなリポジトリが作成できる有料プランがおすすめです。
もしくは、"Git"サーバを自分で構築するしかありません。
ちなみに現在は「GitHub」の他に複数のGitホスティングサービスがあります。
例えば「BitBucket」「GitLab」「Assembla」「Phabricator」等があります。
有名なGitホスティングサービス
の特徴を以下に示す。
| Gitホスティングサービス名 | ホスティング | 対応するVCS | 無料のプライベートリポジトリ |
|---|---|---|---|
| GitHub | Webサービス型 | Git | なし |
| BitBucket | Webサービス型 | Git, Mercurial | 無制限（ユーザ数5名まで） |
| Assembla | Webサービス型 | Git, Subversion, Perforce | 1個（ユーザ数3名まで） |
| GitLab | インストール型 | Git | 無制限 |
| Phabricator | インストール型 | Git, Subversion, Mercurial | 無制限 |
【GitHubを使ってみる】
●GitHubを使するまでの準備
"GitHub"を実際に使用するまで
以下の流れで準備が必要となります。
(1) GitHubアカウントの登録
(2) GitHubクライアント(SourceTreeなど)のインストール
(3) リポジトリの作成
(4) リポジトリを登録する
(1)GitHubアカウント登録
まずは、GitHubのトップページにアクセスします。
ここで、ユーザ名とメールアドレス、パスワードを入力して、アカウント登録を行ってください。
今回は無料であるFreeプランで登録するので、「Free」を選んでから「Finish sign up」ボタンをクリックします。
登録したメールアドレスに認証のメールが届きます。
メールの内容に従いユーザ認証を行ってください。
以上でGitHubのアカウント登録は完了と簡単です。
と言いたいところですが、Web画面が現状全て英語で表記されアカウント登録以外のWeb画面がちょいちょい変更されているので、先駆者の画面イメージを見ても、「うーーーん」と英語と格闘してばかりです。
Web画面でリポジトリを作成しようとしたが、リポジトリ作成画面に到達するまで結構時間を費やした・・・w
実際の画面は、頻繁に変わるので以下を参考にして下さい。
https://techacademy.jp/magazine/6235#sec2
https://utano.jp/entry/2016/07/github-create-account-or-signup-for-japanese/
後は、GitHUBクライアントの接続はSSHを介しての接続となるため、SSH KeyをWebから登録する必要があります。
(2) GitHubクライアント(SourceTreeなど)のインストール
"GitHub"への接続方法は、Linuxからコマンドベース(gitコマンド)、Web、"GitHub Desktop"(クライアントsoftware)とあります。
"GitHub Desktop"(クライアントsoftware)は、いくつものGUI版GitクライアントがありLinux、WindowsからMAC、Androidと多彩です。
"GitHub Desktop"の特徴としては、
- コマンドライン版と比べ、大幅に機能が制限されている。
- "GitHub"と連携するための機能が実装されている。
- Mac/Windows用があり、ほとんど同じUIを提供している。
メジャーな"GitHub Desktop"
製品によって特長があるとは思いますが
私はとりあえず、Androidで使える
"SGit"とPCに"Git Hub Windows"
を導入してみました。
(3) リポジトリの作成
リポジトリの作成は、GitコマンドでもGitHubクライアントからでの可能ですがGitHubのページを開いて、[New repository]のボタンを押すことで作成も可能です。
詳細は、以下を参考にして下さい。
https://qiita.com/muneo/items/1321bf8cdb21178a73e2
http://www.atmarkit.co.jp/ait/articles/1701/24/news141.html
(4) リポジトリを登録する
"GitHub"へのアクセスは、SSHでは公開鍵と秘密鍵を利用して、よりセキュアな通信をおこなうことができます。
クライアントで公開鍵と秘密鍵を作成し、「GitHub側に公開鍵」「PC(ローカル)側に秘密鍵」をそれぞれ配置して利用します。
SSH用の公開鍵・秘密鍵の生成は、GitコマンドでもGitHubクライアントなどで方法が変わるのでここでは記載しません。
生成した公開鍵をGitHubに登録します。
詳細は、以下を参考にして下さい。
http://vdeep.net/github
GitコマンドでもGitHubクライアントなどで秘密鍵を使用し、"GitHub"へアクセスする設定を行って下さい。
詳細は、以下を参考にして下さい。
http://nilfigo.hatenablog.com/entry/20130705/1373000104
https://nelog.jp/sourcetree-github-settings
●GitHubの使い方(コマンド)
GitHubを使う上で基本的な流れは、linuxのコマンドベース(gitコマンド)では以下のようになる。
(a) Githubでリポジトリを作成（git init）、または複製（git clone）する
(b) ローカルでファイルの作成、編集を行う
(c) ファイルの作成/変更/削除をgitのインデックスに追加する（git add）
作成したファイルをローカルリポジトリに追加し、以下のコマンドでインデックスに追加する。
インデックスとは、リポジトリにコミットする準備をするために変更内容を一時的に保存する場所のことです。
$ git add <FileName>
(d) 変更結果をローカルリポジトリにコミットする（git commit）
・次に、インデックスに追加されたファイルをコミットします。
これまでバージョン履歴と呼んできたものがコミットです。
開発をゲームに例えるなら、コミットはセーブポイントです。
ファイルやディレクトリの追加や変更をリポジトリに記録する操作のことです。
$ git commit -m "add new file"
これで、リポジトリに対してファイルの追加が記録されました。
・ファイルが追加されているか確認します。
$ git status
・さらに、リモートリポジトリに反映させる前に、リモートリポジトリの情報を追加します。
この情報は、先ほどGitHub上に表示された、リモートリポジトリのアドレスです。今回は例を示します。
$ git remote add origin https://github.com//awesome.git
(e) ローカルリポジトリをプッシュしてリモートリポジトリへ反映させる（git push）
・自分のローカルリポジトリをリモートリポジトリと同期し、自分のコミットを反映させることをプッシュと言います。
(f) 他人が更新したリモートリポジトリをーカルリポジトリに反映させる(git pull)
・プッシュでは自分が行った変更をリモートリポジトリに同期させます。
しかし、複数人で開発している場合は自分以外の作業者が変更をプッシュする場合があります。
すると自分のローカルリポジトリの状態とリモートリポジトリの状態が変わってしまいます。
このとき、リモートリポジトリの変更をローカルリポジトリに同期させることをプルといいます。
この他にも以下も覚えておく必要があります。
"ブランチ"
ブランチとはGitのバージョン管理の仕組みで、現在のコミットから分岐した作業履歴を残すことができるというものです。
はじめは「master」ブランチのみがリポジトリに存在していますが、ここからあたかも別の歴史に分岐するように、ブランチを増やしていくことができます。
ブランチを利用すると、同じリポジトリの中で複数の変更を同時に進めることができます。
また、一度分岐したブランチは元のブランチと結合して一つのブランチにすることができます。
これを利用して、多人数で作業する際に簡単に役割分担ができます。
"マージ"
その名の通り、ブランチとブランチを結合することを指します。
あるブランチは、そのブランチが分岐したブランチに統合される場合がほとんどです。
例えばmasterブランチにtestブランチをマージするとき、両方のブランチでのコミットを含んだマージコミットが作成されます。
"プルリクエスト"
プルリクエストとは簡単に言うと、開発者のローカルリポジトリでの変更を他の開発者に通知する機能です。
プルリクエストは次のような機能を提供します。
・ 機能追加や改修など、作業内容をレビュー・マージ担当者やその他関係者に通知します。
・ ソースコードの変更箇所をわかりやすく表示します。
・ ソースコードに関するコミュニケーションの場を提供します。
要するに変更作業完了を管理者に通知し、コードレビューしOKであればマージする行為です。
"Issue"
「Issue」は、日本語訳すると「問題」や「課題」といった意味があります。
GitHubのIssues機能もその名の通り、プロジェクトやソースコードの課題を管理するための機能です。
【Gitの運用ルール】
SCMのキモは、運用ルールにあると私は考えてます。(多分...w)
運用ルールが決まっていないと、いくらいいツールを使っていても
意味がないものになってしまいます。
だから、最初の運用ルールを決めることが重要なのですが
開発規模やそもそもプロジェクトの運用ルールとも照らし合わせて
よりよい運用ルールを適用する必要があります。
Gitの運用方法にも色々とありますが、"git flow"と"GitHub Flow"がメジャーみたいです。
●git flow
"git flow"は、大規模開発に向いている方法です。
masterとdevelopの２種類のブランチが存在します。
・本番でのバグ(hotfix)はmasterをコピーしたhotfix branchにて作業を行い。
作業完了後、master branchにマージします。
・各機能の開発はdevelop branchから作ったfeatureブランチにて作業し、完了後developへマージします。
・ある程度の開発が固まった段階で、release branchをdevelopから作成し、tag付け等行います。
・リリースタイミングに、master branchへrelease branchをマージし、本番環境へ展開します。
ただ、数名のプロジェクトで利用するにはとても重く、
ブランチの移動にオーバーヘッドを感じる事が多いようです。
●GitHub Flow
"GitHub Flow"は、小規模開発やリテラシーが有る程度ある人たちがまとまって開発する方法として向いています。
・基本スタンスは全てはmaster branchに帰属し、必要な機能やbugfixを常にリリースし続けるリリース中心主義です。
・効率はとても良いですが、master branchへのマージは御法度。
基本はpull requestで何人かがレビュー（ok signなど）をしてリリースされます
●運用ルール例
(1)git & GitHub 運用ルール
・本リポジトリは 特定のディレクトリのみを管理
・運用は GitHub Flow の考え方を採用する
(2)各ブランチの役割
■branch
branchは、GitHub Flowで一般的な以下の5種のブランチのみとする。
・master : リリースしたソースコードを管理するためのブランチ。
開発者が直接、このブランチへのコミットは行わない。
・develop : 開発を行うためのブランチ。開発者は、個々にfeatureブランチで開発
を行い。開発者が最終的にマージするブランチとする。
・feature : 主要な機能を開発するためのブランチ。
機能の実装やバグフィックスなど、タスクごとにfeatureブランチを作成し、
作業を行う。
・release : リリースの準備を行うためのブランチ。
リリースする前に、developからこのブランチを作成する。
・hotfix : リリースされたソフトウェアに緊急の修正を行うためのブランチ。
このブランチでの修正内容は、すぐにリリースされるので、hotfixブランチはリリースを管理するmasterブランチへマージする。
(3)issueの運用ルール
■issue
・仕様・要件が確定したものから登録
・バグ報告
・詳細はコメントにて記載
・ラベル : design, refactor, bug, hotfix, docs, feature, priorityHigh, priorityLow
・issue をクローズするときは、クローズコメントを簡潔に記述すること
(完了したのでクローズ、他の issue に引き継ぐ等)
(4)ブランチ運用方法
1.開発者は、featureブランチにて開発し単体試験を実施し、問題がなければdevelopブランチにマージする。
2.マージされたdevelopブランチを開発環境にリリースし、結合試験を実施。
3.developブランチから開発経過の断面を取るためにreleaseブランチを作成する。releaseブランチをステージング環境にリリースし統合試験を実施。
4.統合試験が問題なければreleaseブランチからmasterブランチにマージする。
※緊急でリリースする必要がある場合は、masterブランチからhotfixブランチを作成し
修正結果をmasterブランチに反映しリリースする。
開発ブランチへの修正の反映漏れを防ぐため、hotfixブランチをdevelopブランチにもマージする。
(5)開発者向け運用方法
(a) 各自ローカルリポジトリの master にチェックアウト
(b) git pull （新たに作業用ブランチを切る前に必ずリポジトリを最新化すること）
(c) git checkout -b <new branch name> (作業ブランチの派生元は必ず develop とする)
(d) git add <file name> or git add -A
(e) git commit -m “commit message”
(f) git push
(g)プルリクエスト作成、マージ
(6)featureブランチ名の付け方
featureブランチの名前は担当する issue に付与されたラベル名を冒頭につけ、以後は / (スラッシュ)で記述する
例 : $ git checkout -b "feature/coding_logrotate_shell"
(7)コミットと issue の紐付け
・1つの issue に対して切るブランチは1つ
・issue がクローズまたは develop にマージ後はそのブランチでは作業しない
コミットメッセージにはそのコミットがどの issue の対応をしていたのかが分かるようにするため、
issue 番号を付与し、作業内容を簡潔に記述すること
例1 : $ git commit -m “Change logic line9-12 #9”
issue 番号(#9)をクリックすると該当する issue を参照することができる
(8)プルリクエストについて
手順
(a) 元のリポジトリをローカルに落とす
$ git clone git@github.com:だれそれ/リポジトリ名.git
(b)手元で修正し、コミット作成
$ cd リポジトリ名
$ git checkout -b フィーチャーブランチ名 # フィーチャーブランチ作成
（ファイル編集）
$ git commit -am '変更内容'
(c) GitHub上で元のリポジトリを自分にフォーク
変更がいけそうだとなったら、プルリクエストを送るために
元のリポジトリのページから[Fork]ボタンを押して、自分用のフォーク先のリポジトリを作る。
(d) フォークしたリポジトリをリモートブランチ先として追加
$ git remote add forked git@github.com:自分/リポ名.git
$ git remote -v # 確認
(e) フィーチャーブランチを自分のフォーク先にプッシュ
$ git push --set-upstream forked フィーチャーブランチ名
(f) コミットを更新
（フィーチャーブランチをチェックアウトしている状態で）
$ git push
(g) 元のリポジトリの更新に追従する
$ git checkout master # 基準のブランチをチェックアウト
$ git pull
$ git checkout フィーチャーブランチ名
$ git rebase master
（コンフリクトは頑張って解消する。）
$ git push -f forked
(h) GithubでForkした自分のリポジトリに行き、
左側にあるボタンよりbranchを[your_branch_name]に切り替えます。
右上にあるPull Requestボタンを押して、Pull Requestを送信します。
(*) プルリクエストがマージされた後の後始末
$ git checkout master # フィーチャーブランチじゃないブランチに移動
$ git branch -d フィーチャーブランチ名 # ローカルからブランチを削除
$ git push forked --delete フィーチャーブランチ名 # フォーク先のリモートからも削除
(9)プルリク後のソースコードのレビュー方法
(a) ローカルで master にチェックアウト
(b) リモートブランチと同期
(c) master 上で該当するブランチをマージ $ git merge <branch name>
(d) チェック
(e) コンフリクトがなければ、OK
(f) コンフリクトがあった場合、解消してチェックの後コミット
■参考とした運用フロー
git運用フロー10個のルールGitを実践的に使うために参考にすべき記事20選
●その他機能
"GitHub Pages"
"GitHub Pages" とは、"GitHub" による、静的サイトのホスティングサービスになります。
"GitHub" のアカウントがあればすぐに静的サイトが公開できますので、非常にお手軽です。
・静的サイト (HTML や CSS, 画像など) を公開できます。JavaScript も動作します。
・URLは https://ユーザまたは組織名.github.io/リポジトリ名 となります。(Project Pagesの場合)
・独自ドメインを割り当てることも可能です。(別途簡単な設定が必要)
・無料です。
もちろん、サイトの容量や転送量などには制限があります。
詳細は公式サイトのヘルプをご確認ください。
また、Markdown記法も使えるので、ソースコードの貼り付けや、
写真、表の表示なども簡単にできます（Markdown記法を知っていれば）。
"GitHub Pages"公開方法
(a)任意のリポジトリを作ります
(b)ローカルにクローンして、そのなかにhtmlやcssなど表示に必要なファイルをいれます。
(c)これをGithubにプッシュ
(d)http://ユーザー名.github.io/リポジトリ名/にアクセス
Github Pagesでブログ構築ができる静的サイトジェネレーターなるツールも存在し
レンタルサーバを使用せずともお気軽に公開できます。
まあ、これもサーバレスアーキテクチャにあたるのかなｗ
なかには、静的サイトジェネレータなるものが存在しコマンドラインでのカンタンな操作で
HTML/CSS/JavaScriptなどを生成し、Webページ作成を少ない手間で作ることができる。
Jekyll
Octopress
Pelican
Middleman
Hexo
"Gist" "GistBox"
"Gist"は、ちょっとしたコードを不特定多数の人に共有したいときは、
GitHub Gistが非常に便利である。アプリなどの本格的なものではなく、
だれでも使えるような簡単なソースコードであれば、
Gitツールも不要で共有することができるため、ウェブ上ですぐにはじめることができる。
"Gist"では主に以下のことができる。
・ソースコードの一部をウェブ上で作成・編集ができる
・Gistのバージョン管理ができる
・公開されたGistをブログなどに張り付けることができる
"GistBox"は殺風景な"Gist"の管理画面をメーラーのように表示するサービス。
Githubのアカウントでログインすると、画面はこのようにまるでメーラーそのまま。
Gistの標準の機能にはないタグ（ラベル）付けできて絞り込めるのも使い勝手がいい。
Gistのトップ画面だけで拒否反応を起こしてしまうようなデザイナーさんにも持ってこいだ。
もちろん、「GistBox」からもソースの編集が可能です。
"GitHub Wiki"
Wikiとは、Webブラウザを利用して、独自の記述方法によりWebページ（HTML）を編集することができるシステムの総称である。
"GitHub Wiki"も同様にMarkdown, MediaWiki, Textileなど大抵の記法で書けるgollumというWikiエンジンの"Wiki"である。
また、"GitHub Wiki"はgitリポジトリ一つで完結しており、MySQLなどのDBが不要で、簡単にprivate wikiを立ち上げられる。
ただし、GitHubのスマホ版ページにはWikiへのリンクがなく、画像やファイルを挿入するのが面倒。
画像を挿入するためには、「Fork」→「Clone」→「編集(画像挿入)」→「Push」→「Pull Requests」
リポジトリのimagesから画像のファイル名の「Download」をクリックして、URLを取得し、WikiページにMarkdownの画像記法として貼る。
最初に"Wiki"を作成するには、リポジトリの画面の右にWikiのリンクをクリックし、
Create the first pageをクリックする。
とりあえず今回は作成することが目的なので、一度右下にあるSave Pageのボタンをクリックして保存する。
"GitPitch"
"GitPitch"は、ブラウザ上のGitHubでMarkdown（マークダウン）ファイルを作成し、
そのまま超高機能なスライド資料に変換してくれるサービスです。
GitHubだけで超高機能なスライド資料が作れる「GitPitch」の使い方を徹底解説！
"Atom"
"Atom"は、"GitHub"が開発したオープンソースのテキストエディタ。
■Atomの特長
・タブ型で、使いやすいユーザーインターフェース
・無料で公開されているパッケージで機能追加が可能
・一つのウィンドウで単一のファイル、プロジェクト全体、複数のプロジェクトを開くことができる
最大の特長はなんといってもその拡張性の高さ。一部の文字を入れるとその後の変換予測一覧を表示する「予測変換」や「キーバインド（ショートカット）」など、Web開発者には嬉しい機能が実現されています。
・日本語化するには
[File]→[Settings]
画面右側に「Settings」タブの[+Install]を選択する
入力欄に「Japanese-menu」と入力
「Packages」ボタンをクリックすると検索が開始される。
検索結果に表示された「Japanese-menu」パッケージの「Install」ボタンをクリック
"Git-Bash"
LinuxでGitを使用する場合、"Git-Bash"プラグインを導入することでGitをより扱いやすくすることができます。
シェルのプラグインを同梱した状態で配布されていますが、プラグインはデフォルトではオフとなっています。
プラグインを使用するには、Gitのソースコードから contrib/completion/git-completion.bash ファイルのコピーし、
取得したファイルをどこか適当な場所（例えばホームディレクトリ）へコピーした上で、 .bashrc に次の内容を追加する必要があります。
. ~/git-completion.bash
するとBashでGitコマンドをオートコンプリートしてくれるようになります。
Windowsの場合は、Git for Windowsのインストールが前提となっていますが
"Git-Bash"を導入するとWindowsでもBash風ではあるがGitコマンドをCUIで使用できる。
WindowsでGitを始めたらまず確認！Git Bashの設定&ショートカット
"gist-it"、"github-embed"、"Gistfy"埋め込みコード生成ツール
"gist-it"、"github-embed"、"Gistfy"は、外部サイト用に埋め込みコードも生成するツールです。
・"gist-it"
gist のコードは簡単にブログに貼れるけど、GitHub のリポジトリ内のコードはどうやって貼るには"gist-it"
scriptタグを貼るだけらしいです
たとえば GitHub のコードのアドレスが https://github.com/matsuoshi/wp-small-archives/blob/master/small-archives.css
なら、こんなかんじ
・"github-embed"
"github-embed"はGithubのコードを任意のWebページに埋め込むためのスクリプトです。
Gistライクにリポジトリ内のコードを埋め込める"gist-it"のように先発はいろいろ有った気がしますが、
複数ファイルを1箇所に埋め込めるのは地味に便利な気はします。ライセンスはMIT。
・"Gistfy"
"Gistfy"が対応しているのはGitHub、GistそしてBitBucketです。認証不要で使えますが、
パブリックなリポジトリでしか使えないので注意してください。
カラースタイルを変えたり、シンタックスの変更、表示する行の指定（一部の行だけ表示できます）が可能です。
Gistfyはnode/JavaScript製のオープンソース・ソフトウェア（MIT License）です。
●やってみよう
以下を参考に「GitHub Pages」で
フリーランスプロフィールHP作ってみました。
って本当に簡単に出来ました。
https://legitwhiz.github.io/index.html
たった５ステップ！Githubの機能「GitHub Pages」でホームページを制作しよう
GitHubに公開されているテンプレートをコピーして、GitHub PagesでWebページとして公開する方法github-pages/
●用語集
- repository（リポジトリ）：ファイルや変更内容が保存される場所のことで、パソコン内にあるものをローカルリポジトリ、GitHubなどローカル以外のサーバ上にあるものをリモートリポジトリと呼ぶ
- 作業ディレクトリ：リモートリポジトリをclone（複製）したディレクトリ（ローカルリポジトリ）のことで、作業中のファイルが含まれる
- ステージングエリア：ローカルリポジトリのなかにあるコミットをする予定のファイルを仮置きしておく場所のこと
- Gitディレクトリ：ステージングエリアにあるファイルをコミット（登録）して、変更が確定したディレクトリ
- branch（ブランチ）：並行して作業を進めるためにmasterブランチからコミットの流れを分岐すること（最終的にmasterブランチにマージ（合体）される）
- clone（クローン）：リモートリポリトジを複製して、パソコン内に新しいローカルリポリトジを作成すること
- fork（フォーク）：GitHub上の他人のリモートリポリトジを編集するために、自分のアカウントにリモートリポリトジのコピーを作成すること
- commit（コミット）：変更された記録をリポジトリに登録（バージョン管理）すること
- push（プッシュ）：ローカルリポジトリのコミットをアップロードしてGitHub上のリモートリポジトリに反映させること
- merge（マージ）：複数のブランチやコミットを合体させること
- Pull Requet（プルリクエスト）：自分がおこなった変更をマージしてもらうようにリクエストをすること
- checkout（チェックアウト）：ブランチの切り替えなどによって作業ディレクトリを指定したコミットの状態にすること
- pull（プル）：GitHub上のリモートリポジトリからコミットをダウンロードしてローカルリポジトリに反映させること
- conflict （コンフリクト）：複数人が同じ場所を変更してしまうことから発生するGitが自動でマージできなくなった状態のこと
- Userアカウント：個人のアカウントのことで、Organizationアカウントのメンバーになれたり、リポジトリの共同作業者（Collaborator）になることができる
- Organizationアカウント：複数人の管理者や共同作業者を設定することができる会社やオープンソース向けのアカウントのこと
- Owners：Organizationアカウントで自動的に作られるすべての権限をもったチームのこと
- Read Access：閲覧とclone、wikiの編集をする権限のこと
- Write Access：閲覧とclone、pushとwikiの編集をする権限のこと
- Admin Access：閲覧とclone、pushとwikiの編集、メンバーの追加をする権限のこと