Download to read offline
![ https://GitHub.com/
[Sign up]をclick
Username、Email Address、Passwordを入力：Usenameは
重複不可。なので「すでに使われている」アカウントの場合、
「Username is already taken」と出る
[Create an account]をclick
Choose your plan
[Unlimited public repositories for free.]を選択(有料でも止
めはしないけど、"後で変更"出来るので、一端は無料でよい
でしょう)
[Continue]をClick](https://image.slidesharecdn.com/git-170924154541/85/Git-38-320.jpg)
![ アンケートへの入力はお好みで。
下に[skip this step]があるので、skipしてもよし。
登録したメールアドレスを確認する。
Gitからmailが来ているはずなので、メールの中にあるリ
ンク(Verify email address)をclickして、メールアドレスの
認証を終了させる。
[Start a project]のボタンを押すとレポジトリの作成画面
になる。
一端作成せず、ここまでで「GitHubのアカウント登録」の
完了。](https://image.slidesharecdn.com/git-170924154541/85/Git-39-320.jpg)
![「新しいレポジトリ」を作成、ファイルを１つ
コマンドプロンプトで以下を打ち込みます
git init
[エクスプローラでテキストファイルを作成： README.txt]
[README.txtを修正] test1
git add README.txt
git config --local user.name "自分の名前"
localの前のハイフンは「二つ」なので注意
お仕事等だと「 --global」が多いが、今回は共有PCなので、localで
スペースが必要なので注意！！
git config --local user.email "自分のメールアドレス"
git commit -a -m "first commit"](https://image.slidesharecdn.com/git-170924154541/85/Git-43-320.jpg)
![ファイルの中身を修正して、commitする
[README.txtを修正] test2
git commit -a -m 'second commit'
git log
git log --oneline
git log --stat
git log --graph --oneline](https://image.slidesharecdn.com/git-170924154541/85/Git-45-320.jpg)
![「どこを変更したか」確認をしてからcommit
[README.txtを修正] test3
git diff
git commit -a -m '3rd commit'](https://image.slidesharecdn.com/git-170924154541/85/Git-47-320.jpg)
![ git remote add origin https://github.com/XX/test.git
「origin」という名前に「 https://github.com/XX/test.git 」のリ
モートレポジトリを紐づける、という意味合い(下で使う)
git push -u origin master
"git push [リモートリポジトリ] [ローカルのブランチ名]：[リ
モートのブランチ名]"が、正式
git push https://github.com/XX/test.git master：master
git push origin master：master
git push origin master
-uは「一端、あまり気にしない」](https://image.slidesharecdn.com/git-170924154541/85/Git-56-320.jpg)
![ファイルを修正して、pushする
[README.txtを修正] test4
git commit -a -m "4th commit"
ブラウザでGitHub(リモート)のレポジトリをみて「まだ反映されて
いない」事を確認する
git push origin master
ブラウザでGitHub(リモート)のレポジトリをみて「反映されてい
る」事を確認する](https://image.slidesharecdn.com/git-170924154541/85/Git-57-320.jpg)
![ cd C:
mkdir git_work2
cd git_work2
git clone https://github.com/[アカウント名]/test.git
コンソールから「cd test」
または
エクスプローラで「C:git_work2test」
で、ファイルの存在を確認する
git config --local user.name "自分の名前(別名で)"
git config --local user.email "自分のメールアドレス(連
絡先)"](https://image.slidesharecdn.com/git-170924154541/85/Git-60-320.jpg)
![(Bさんとして)ファイルを修正
[README.txtを修正] test5
git commit -a -m “5th commit"
git push origin master
ブラウザでGitHub(リモート)のレポジトリをみて「反映されてい
る」事を確認する](https://image.slidesharecdn.com/git-170924154541/85/Git-61-320.jpg)
![「Bさんが修正したファイル」を、Aさん(元の
人)が受け取る
cd C:git_work
git log
[README.txt]を確認、まだ「test3」のままである事を確
認する
git pull
git log
[README.txt]を確認、先ほどの「Bさんの修正」が反映
されている事を確認する](https://image.slidesharecdn.com/git-170924154541/85/Git-62-320.jpg)
![ git pull
"git pull [リモートリポジトリ] [リモートのブランチ名]"が、正
式
git pull https://github.com/XX/test.git master
git pull origin master
git pull](https://image.slidesharecdn.com/git-170924154541/85/Git-63-320.jpg)
Git講習会
- 1.
- 2. 趣旨 Gitについて、基本を学習していきます Git、およびWebサービスGitHubは、学校での学習にお いても、社会に出てからのお仕事でも、使う頻度の高い ツールになります 一端は「授業の前提知識として」のGitの知識を学習して いきましょう
- 3. バージョン管理システムとは？ 「変更履歴」がないと困る 「誰が」「いつ」「どのように」修正したかの経緯が必要な時が ある 「コメントによる」変更履歴 読みにくい(特に量が増えると後半、極端に可読性が落ちる)、 全体を通しての差分がわかりにくい 例 → // 20170325 古庄 修正start //$hoge = hoge(); // 20170901 鵜沢 修正start //$hoge = hoge(1); $hoge = hoge(2); // 20170901 鵜沢 修正end // 20170325 古庄 修正end
- 4. 「ファイル/ディレクトリのバックアップによる」変更履歴 ファイルが増える、差分が解らない、命名を間違えると「どれ が最新かわからない(例：新しい.xls、より新しい.xls、最新.xls、 更新した最新.xls、最新より新しい.xls、新しい最新.xls)」 「日付(＋ナンバリング)」にすればマシだが、差分は相変わら ずある程度不明 「細かい巻き戻し」はできない事が多い(か、極端にファイルや ディレクトリが増えるか) バージョン管理による変更履歴 バージョン管理システムにもよるが基本「差分が見やすい」よ うに出来ているので、わかりやすい 細かい巻き戻しなども可能
- 5. バージョン管理システムがないと「なぜ」困る？メリット は？ 過去の状態や変更内容を確認 変更前の状態を復元することが容易 同一ファイルに対する変更が競合するなどの問題を防ぐ(防ぎ 方は色々) バージョン管理は「プログラムが多い」が、設定ファイル や原稿など、様々なものもバージョン管理できるし、便利 でメリットがある 「テキストファイル」が多く、バイナリファイル(画像、動画など) を適切に差分管理できるものはあまりない
- 6.
- 7.
- 8.
- 9.
- 10.
- 11. 本当は望まれているはず、のソースコード 「Aさんの修正」と「Bさんの修正」が双方とも適切に反映され ている 実際のサーバのソースコード //大本の記述1 大本の記述1-A //大本の記述2 大本の記述2-B 大本の記述3 大本の記述1 //大本の記述2 大本の記述2-B 大本の記述3
- 12. 質問 「Aさんが修正した」修正→ どこに消えた？？？ 現在のサーバのソース↓ これがデグレードです 絶対厳禁！！ //大本の記述1 大本の記述1-A ソースコード管理サーバ：とあるファイル 大本の記述1 //大本の記述2 大本の記述2-B 大本の記述3
- 13. デグレードを防ぐためにはどうすればよいか？ いくつか方法がありますが(後述)、そのために「バージョ ン管理システム」と呼ばれるツールがあります 今日、メインで学ぶGitは、バージョン管理システムの一 つ、になります
- 14. バージョン管理システムの簡単な歴史 SCCS(Source CodeControl System) 世界初のバージョン管理システム。1972年に出来た。 RCS(Revision Control System) 1982年に作られたバージョン管理システム。ファイル単位で管理を 行い、軽い。 CVS(Concurrent Versions System) 1990年に作られた。当初はRCSをベースにしていたらしい。(RCS やSCCSと異なり)「ネットワーク越し」に使えるシステムだったので、 一時期、割とよく使われていた。 SVN(Subversion / Apache Subversion) 2000年に作られた。のちに(2009年)にApacheプロジェクトに入った ので、名前の頭にApacheがつくようになる。 CVSでいくつかある難点を補うために作られた。会社等によっては 今でも現役。
- 15. VSS(Visual SourceSafe/ Microsoft Visual SourceSafe) 2005年作成。Microsoft Visual Studioによるアプリケーション 開発において使用することに主眼をおいたバージョン管理シ ステム。 現在はサポートが終了しており、TFS(Team Foundation Server)が後続になっている Mercurial 2005年作成。Gitと一時期、覇を競っていた時期がある。現状 でもGitとMercurialは「互いの機能を取り入れつつ開発が進 んでいる」。ただし、Gitよりはマイナー。
- 16.
- 17. バージョン管理で使われる用語の簡単な説明 注意 いきなり「全部覚える」のは難しいと思うので、必要に応じて読み返 すようにしてください リポジトリ 概ね「ファイル一式」。１プロジェクトあたり１リポジトリ、が比較的多 いが「複数プロジェクトで１リポジトリ」「１プロジェクトで複数リポジト リ」も、ケースとしては存在する チェックアウト リポジトリからソースコードを取り出す事。バージョン管理システムに よっては「一人がチェックアウトをしたら、ほかの人はチェックアウト できないようにする」事で「１つのファイルを複数人で同時に修正す る(デグレード)」を抑止する(後述の「ロック方式」参照)。 今回メインで学習するGitにはこの概念は存在しない。
- 18. ロック方式 デグレを防ぐために「一人がチェックアウトしたら、ほかの人は チェックアウトできない」ようにしてファイルを守る方法。 シンプルだが、状況等によっては「効率が悪い」事がある。 今回メインで学習するGitにはこの概念は存在しない。 コピー・マージ方式 同一ファイルでも「明らかに異なる行への修正」であれば、コ ンピュータ側である程度把握して自動的に変更分を足していく 方法。 多人数でもある程度まで「同時に同一のファイルを触れる」の で効率的だが、「コンピュータ側で自動で判断できない」状況 になれば最終的には人力に頼る事になるので、過信は禁物。 今回メインで学習するGitはこのパターン。
- 19. バージョン番号、コミットID ある１回の「変更」に対して割り振られる番号。「バージョン番 号」の場合は比較的「1や1.1などの整数」から始まってインク リメントされる事が多い。 「コミットID」の場合は「他とぶつからないユニークでランダム (に見える)文字列」である事が多い。 今回メインで学習するGitはコミットIDが用いられている。 タグ 「この時点での変更(バージョン番号、コミットID)」に対して入 れる、しおりのようなもの。 あってもなくてもよいが、「あるとわかりやすい」ケースも多い ので、折に触れてタグを打つ事、も多い。
- 20. GitHubについて Gitを使いますが、同時にGitHubも少し使っていきます (授業で使う事が多いので)。 Git バージョン管理システム GitHub 「Gitを使う事ができて、リモートにHDDがある」Webサービス。 Gitが持つ本来の機能以外に、いくつか独自の機能も持って いる 認証機能 Issues、 Pull Requests、wiki など
- 21.
- 22. GitHubを使う事によって 多人数でも開発が出来る GitHubの場合「ほかの人にソースを見てもらう事ができる/提 供できる」 なお、単純に「Gitのみ」で開発をしたり(それでも「多人数 で開発が出来る」というメリットは享受できる)、GitHubと 似たような機能を持つOSS(GitLabなど)もあるので、興 味があったら色々と調べてみましょう！！
- 23. OSSについて少し Open-source software/ オープンソースソフトウェア ソフトウェアを、学習、変更、そして配布するための権利 を提供するというライセンスに基づいたソフトウェア 端的には、Linuxがそうで、Gitがそうで、様々なOSSを 我々は使っている GitHubを使うと「ソフトウェアを配布する」ための環境が、 (ライセンスによっては)無料で手に入る
- 24.
- 25. GitHubアカウントを作成する Gitを学習する一貫として、GitHubを使った実習をします また、授業で使う事なども増えてくると思います ですので、GitHubアカウントを作成しましょう 画面は2017年9月のものです まず https://github.com/ をブラウザで開きます。以降、手順を説明していきます 「後でまとめてやる」と、途中でつまづきます。 集中して、しっかりと手順を一緒に追いかけてください
- 38. https://GitHub.com/ [Signup]をclick Username、Email Address、Passwordを入力：Usenameは 重複不可。なので「すでに使われている」アカウントの場合、 「Username is already taken」と出る [Create an account]をclick Choose your plan [Unlimited public repositories for free.]を選択(有料でも止 めはしないけど、"後で変更"出来るので、一端は無料でよい でしょう) [Continue]をClick
- 39. アンケートへの入力はお好みで。 下に[skipthis step]があるので、skipしてもよし。 登録したメールアドレスを確認する。 Gitからmailが来ているはずなので、メールの中にあるリ ンク(Verify email address)をclickして、メールアドレスの 認証を終了させる。 [Start a project]のボタンを押すとレポジトリの作成画面 になる。 一端作成せず、ここまでで「GitHubのアカウント登録」の 完了。
- 40.
- 41.
- 42. 準備 レポジトリ用のディレクトリの準備 コマンドプロンプト(cmd.exe)を立ち上げます cdC: mkdir git_work cd git_work (エクスプローラでやってもよいですが、後でコマンドプロンプト は使います) もし「サブディレクトリまたはファイル git_work は既に存在し ます。」というエラーが出た場合は rmdir /S git_work で削除してから上述を実行してください。 エクスプローラでも同じディレクトリ(C:git_work)を開い ておいてください エクスプローラ設定「隠しファイルの表示」「拡張子の表示」
- 43. 「新しいレポジトリ」を作成、ファイルを１つ コマンドプロンプトで以下を打ち込みます gitinit [エクスプローラでテキストファイルを作成： README.txt] [README.txtを修正] test1 git add README.txt git config --local user.name "自分の名前" localの前のハイフンは「二つ」なので注意 お仕事等だと「 --global」が多いが、今回は共有PCなので、localで スペースが必要なので注意！！ git config --local user.email "自分のメールアドレス" git commit -a -m "first commit"
- 44. git init 「新しいレポジトリ」を作成します git add 指定したファイルを「gitの管理対象」にします git config 色々な設定をします。今回は「自分の名前」と「連絡先」を登録 しました(後で出てきます) git commit 変更をgitに登録します
- 45. ファイルの中身を修正して、commitする [README.txtを修正] test2 git commit -a -m 'second commit' git log git log --oneline git log --stat git log --graph --oneline
- 46. git log gitの変更履歴を表示します。様々なオプションがあります 前Pageで出てきたオプションは、全部「ハイフン２つ」です
- 47. 「どこを変更したか」確認をしてからcommit [README.txtを修正] test3 git diff git commit -a -m '3rd commit'
- 48. git diff 「最後にcommitした」後、どこに変更があったかを教えてくれ ます 実際にはそれ以外にも「色々な"２点"の比較」が出来ます
- 49.
- 50.
- 51.
- 52. 事前準備 Windowsの場合で、かつ共有PCの場合「認証情報」が 残っている可能性があるので、確認して削除しましょう (以下は、Windows 10の場合) コントロールパネル →ユーザーアカウント →資格情報の管理 →Windows 資格情報 汎用認証情報に「git:https://github.com」があったら →削除する
- 53.
- 55. git remoteadd origin https://github.com/XX/test.git git push -u origin master ブラウザをリロードして「GitHubにソースコードが上がっ ている事」の確認
- 56. git remoteadd origin https://github.com/XX/test.git 「origin」という名前に「 https://github.com/XX/test.git 」のリ モートレポジトリを紐づける、という意味合い(下で使う) git push -u origin master "git push [リモートリポジトリ] [ローカルのブランチ名]：[リ モートのブランチ名]"が、正式 git push https://github.com/XX/test.git master：master git push origin master：master git push origin master -uは「一端、あまり気にしない」
- 57. ファイルを修正して、pushする [README.txtを修正] test4 git commit -a -m "4th commit" ブラウザでGitHub(リモート)のレポジトリをみて「まだ反映されて いない」事を確認する git push origin master ブラウザでGitHub(リモート)のレポジトリをみて「反映されてい る」事を確認する
- 58.
- 59.
- 60. cd C: mkdirgit_work2 cd git_work2 git clone https://github.com/[アカウント名]/test.git コンソールから「cd test」 または エクスプローラで「C:git_work2test」 で、ファイルの存在を確認する git config --local user.name "自分の名前(別名で)" git config --local user.email "自分のメールアドレス(連 絡先)"
- 61. (Bさんとして)ファイルを修正 [README.txtを修正] test5 git commit -a -m “5th commit" git push origin master ブラウザでGitHub(リモート)のレポジトリをみて「反映されてい る」事を確認する
- 62. 「Bさんが修正したファイル」を、Aさん(元の 人)が受け取る cd C:git_work git log [README.txt]を確認、まだ「test3」のままである事を確 認する git pull git log [README.txt]を確認、先ほどの「Bさんの修正」が反映 されている事を確認する
- 63. git pull "git pull [リモートリポジトリ] [リモートのブランチ名]"が、正 式 git pull https://github.com/XX/test.git master git pull origin master git pull
- 64. 一端まとめ Git等のバージョン管理ツールは、このようにして「変更 履歴」を管理します まずは「一人で」プロジェクトのソースコードをGit管理し て、ゆっくりと慣らしていくとよいでしょう 慣れてきたら複数人数で。その場合はできれば「ブラン チを使った開発」をした方がよりよいので、このPPTで後 述してある内容を、自分なりに学習してみましょう 最後に整理(ディレクトリの削除) C:git_workとC:git_work2を、ディレクトリごと削除しましょう アカウント情報を削除しましょう
- 65. 付録：多人数で開発するときのコツ 作業を細かく分けてこまめにcommit 「１作業」毎にcommit なので、こまめなcommitのタイミングでpull rebaseは好みが分かれるので、環境やほかの人と相談 しつつ。大体「がっつり使う」か「まったく使わない」か、の 二極化。現場で確認しましょう branchを使う(できれば定期的にリモートにもbranchを push) ぶつかったら諦めて手動merge。その時に「他人の修正 をつぶしたり壊したりしない」用に気を付けよう
- 66. 付録： .gitignoreファイルについて 「管理対象にしたくないファイル」を登録できるファイル 例えば、以下のようなファイルを登録しておくと、便利な 事も多いでしょう .DS_Store等の「OSが作っている」ファイル *.oのような「コンパイル用オブジェクト」ファイル ログファイル 「他から持ってきている」ライブラリ群 「空ディレクトリ」の保持には、 .gitkeep でもよいのです が「対象ディレクトリに.gitignoreを置く」方法もあります * !.gitignore
- 67.
- 68. 付録：ブランチについて学ぶ(操作例) 「一つの例」程度ですが、参考にしつつ、色々と自力で調 べたりしてみましょう #先に「手元のレポジトリを最新にしておく」 git pull # 現在見ているブランチがmaster(またはそれ以外の適 切なブランチ：git flow準拠ならdevelop)であることを一 度確認しておく git branch
- 69. # 作業用ブランチを切って移動する # git branch ブランチ名 # git checkout ブランチ名 git checkout -b ブランチ名 # 移動できたことを確認 git branch # 修正等作業：作業完了してmergeできるところまでもっ てこれた git commit -a
- 70. ブランチ：「リモートにアップしてpull request等をする」流れの場合 # リモートにアップする git push origin ブランチ名 # レビュー等をしてもらう (mergeはおそらく「レビューをしてくれた人」がしてくれる) # merge後、リモートのブランチを削除する(ブランチ名の前 に：を付けると「削除」の意味)(削除してくれている、かも) git push origin :ブランチ名 # localのブランチを削除する git branch -d ブランチ名 git branch 終了
- 71. ブランチ：「自分でmergeする」流れの場合 # 「mergeしてOK」になったら # master(またはそれ以外の適切なブランチ：git flow準 拠ならdevelop)に移動する：コマンド例はmasterである と仮定 git checkout master git branch # レポジトリを最新の状態にしてから、mergeする git pull git merge ブランチ名
- 72. # localmasterの内容をリモートに反映する git push origin master # localのブランチを削除する git branch -d ブランチ名 git branch 終了
- 73. 付録：様々な開発方法の一例/ GitHub flow 使用するブランチ master： 「デプロイ可能」なブランチ topicブランチ： 作業用のブランチ群。命名は決まっていない 下準備 masterブランチを用意します
- 74. 新しい機能の開発や修正、緊急のバグフィックス対応 masterから新しいブランチを作成する git checkout -b ブランチ名 新しいブランチ上で追加や修正の作業を行う リモートのブランチに、定期的にpushをしておく事が推奨されている Pull Request、merge を行う Pull Request → masterへmerge masterに入ったものは、いつdeployされてもよい、とみなす 定期的、或いは即時、といったdeployタイミングが多いと思います
- 75. 付録：様々な開発方法の一例/ Git flow 使用するブランチ master：リリースするためのブランチ。リリース後、タグを切る develop： 開発ブランチ。開発する時の元ネタ featuresブランチ群： 実際に作業をしているブランチ群 hotfixesブランチ群：リリース後の「クリティカルなバグ」などに 対応するためのブランチ群 releases ブランチ群： リリースの準備用のブランチ群 下準備 masterブランチを用意します masterブランチからdevelopブランチを作成します
- 76. 新しい機能の開発や修正 developから新しいfeatureブランチを作成する "feature/ブランチ名"という命名が多いです feature上で追加や修正の作業を行う 以下の作業をします local上で、featureブランチをdevelopにmergeします developブランチをremoteにpushします push後、localのfeatureブランチは削除します
- 77. リリース(deploy)準備 developブランチからreleaseブランチを作成 "release/リリース名"という命名が多いです 必要であれば、 releaseブランチに修正を加えます リリースの準備が完了したら、以下の作業を行います releaseブランチをmasterにmergeして、pushします masterブランチにリリース用のタグをつけます(こちらもpush) releaseブランチの内容をdevelopブランチにmergeして、pushしま す releaseブランチを削除します masterブランチの内容をリリース(deploy)します
- 78. 緊急のバグフィックス対応 masterブランチからhotfixeブランチを作成 "hotfixe/ホットフィックス名"という命名が多いです 修正が終わったら、以下の作業をします hotfixeブランチをmasterにmergeします masterブランチに「緊急対応した」旨のタグをつけます hotfixeブランチをdevelopにmergeします hotfixeブランチを削除します masterブランチの内容をリリース(deploy)します