新人「GitとGithub」研修のスライドを公開用に調整したもの

1. Git / Github 研修
2015/6/4,５ 株式会社ヴァル研究所
ぷぽ（@pupupopo88）
前半戦！
1
公開用

2. このスライドについて
新人研修でやった内容を一部公開用に修正したもの
研修の対象（想定）
開発未経験者（数名程度）
配属も開発とは限らない
HTML5とCSS3の基本はレクチャー済み
イメージを持ってもらうことを優先しているため、
多少表現に無理（まちがい）があります
2

3. ざっくりなもくじ
複数人でのファイル変更
バージョン管理システム
Git・基本操作
歴史を分岐させる（ブランチ）
歴史を統合させる（マージ）
歴史をなかったことにする（リセット）
総合れんしゅう
おまけ
3
p. 7
p. 46
p. 52
p.123
p.150
p.199
p.267
p.282

4. 自己紹介
「ぷぽさん」「ぷぽ氏」と呼ばれてたり
します
総務です
新卒文系未経験で入社後、２年間エンジ
ニア（エンジニアとはいっていない）を
やってました。今年で入社４年目です。
Gitを触り始めたのは丁度２年前くらい
まだまだぺーぺーです
みなさんと一緒に学んでいきたいです
4

5. 本研修の目標
（なんとなく）「バージョン管理システム」がなん
なのかイメージできる
（なんとなく）「Git」がなんなのかイメージできる
（なんとなく）「Github」がなんなのかイメージで
きる
GitやGithubを使うことを怖がらない
5

6. なんとなく
イメージできればおk
6

7. はじまりはじまり
7

8. 突然ですが
8

9. 複数人で
ひとつのファイルを
扱ったことはありますか
9

10. たとえば
10

11. たとえば2
11

12. チームで開発（お仕事）することが増えてきます
12
これからは

13. まずはイメージを
つかんでいただくために
13

14. 実際のPJを想定して
作業をしてみましょう
14

15. ＿人人人人人人人＿
＞ 突然の課題 ＜
￣Y^Y^Y^Y^Y^Y￣
15

16. ひとりで作業する
16

17. - うちわネタ多数により省略 -
17

18. やったことは
社内用共有サーバにファイル（HTML）を配置
各自、そのファイルに手を入れてもらう
ファイルを修正する
さらにファイルを修正する
（退社という体で）エディタを閉じる
（翌日という体で）元に戻してという
→うそやん！！！
18

19. もう一度やります ※ファイルリセット
19

20. - 再びの省略 -
20

21. やったことは
先ほどと同様のファイルに手を入れる
Aさんから修正依頼
Bさんから修正依頼
（翌日）Aさんから追加修正依頼
Cさんから「Bさんの修正」を元に戻す依頼
（更に翌日）Bさんから再度修正依頼
→ …。
21

22. ＿人人人人人人人人＿
＞ 理不尽なっ！ ＜
￣Y^Y^Y^Y^Y^Y￣
22

23. どうでした？
ひとりひとり感想をどうぞ
23

24. どうでした？
ひとりひとり感想をどうぞ
「変更を自前で管理する」ってつらいですよね
23

25. Next
24

26. 複数人で同時作業する
25

27. やること
社内用共有サーバに置いてあるファイル
（HTML）に対して、複数人で変更を加える
作業は個別にメールで指示
26

28. どんな方法があるかな
自分がやる作業しか見えていないですよね
同じファイルを変更しなければならないですよね
方法はお任せします
が、作業に入る前に考えを聞かせてください
3分程度で案出してね！
27

29. ヒント
たとえば
各自変更点を共有、変更すべき点をまとめて誰
かが全部やるとか？
たとえば
各自共有サーバにあるファイルをコピー、それ
ぞれ作業した後に変更点を合わせるとか？
28

30. どうでした？
ひとりひとり感想をどうぞ
29

31. どうでした？
ひとりひとり感想をどうぞ
「チームで１つのことをする」って大変ですよね
29

32. 困ることってなんだろう
いつ変更したか
誰が変更したか
どこを変更したか
何のために変更したか
やった本人にしかわからない
（本人も数日後、数か月後、数年後わからなくなる）
ネットが切れると終わる（しかも社内ネットワーク）
30

33. 大変なのは
わかったけど
31

34. これらの問題
どうやったら解決できる？
32

35. ご意見ください！
33

36. 解決……?
コードに全部コメントで書く？
コードが肥大化する！見にくい！
別にファイルを用意して記録しておく？
プログラムはよく変更されるもの
管理が大変
すぐにわからなくなる
34

37. これらの問題を
解決するために
35

38. バージョン管理システム
というものが存在します
36

39. バージョン管理システムとは
安心してファイルの変更ができる
前のバージョンに戻せる、差分が見られる
自前でファイル変更に関する情報を残さなくていい
いつ誰が変更したのかわかる
複数人で作業するときラク
各々の作業をマージできる
37

40. かんたんにいうと
38

41. こんなかんじ
39

42. Git
40

43. バージョン管理システム
41

44. バージョン管理システム
41

45. Gitの特徴
手軽にバージョンの切り替えができる
処理が高速
安心度が高い
分散型の管理
複数人で作業するのに適している
賢いマージ
42

46. Gitを使ってみよう
43

47. CUI vs GUI
黒い（文字ばっかりの）画面
後々がっつりやるなら絶対こっちがいい
最初は難易度高め
私も普段はこっち
ソフトウェア
イメージをつかむにはもってこい
今回はこっちを使います
44

48. 45

49. まずは準備から
作業スペースを確保しましょう
Finderからどうぞ
documents/git_study/git_practice
このディレクトリ以下で作業していきます
46

50. Gitで管理はじめる
47

51. Gitで管理はじめる
48

52. • ん…何か出来ている…!
Finderで確認
49

53. そのディレクトリ以下で行われたファイルを管理
したりします
.git ディレクトリ
50

54. 51

55. リポジトリ
51

56. 管理して欲しくない
ファイルがある場合
52

57. .gitignoreさん
.gitignoreというファイルに記述してあるディレ
クトリやファイルは、いくらリポジトリ内にあっ
ても、バージョン管理の対象になりません
.DS_Storeとか、*.xlsとか、/logとか
そんなの管理しなくてもいい
53

58. リポジトリ
54

59. かき方（例）
55
全部ハブられる

60. もどります
56

61. リポジトリにファイル置いてみる
index.htmlをつくってください
ひとまず中身はカラで大丈夫
57

62. 58

63. 歴史を刻んでいく…
gitさんがこんなファイル知らんぞと言ってます
ファイルを追加したことを歴史に刻みましょう
59

64. チェックを入れると
60

65. 上のエリアに移動します
61

66. インデックスに追加
先ほどの操作をインデックスに追加（add また
は ステージング）するといいます
この状態では、まだ完全に歴史として刻まれてい
ません
62

67. 実際に記録する
63

68. 64

69. 65

70. コミットメッセージ
66

71. 思い出してください
ファイル変更の際、必要とされる情報ってなんで
したっけ？
「いつ」「だれが」「どこを」「なぜ」変更した
か
「なぜ」を残すことを心がけましょう
「なぜ」は機械には判断できない
67

72. 68

73. 記録できた！（変更点なし）
69

74. もうちょっとわかりやすく
70

75. 71

76. 思い出してください（再）
ファイル変更の際、必要とされる情報
「いつ」
「だれが」
「どこを」
「なぜ」変更したか
72

77. 73

78. いつ
73

79. だれが いつ
73

80. だれが いつ
どこを
73

81. だれが いつなぜ
どこを
73

82. ＿人人人人人人＿
＞ あら便利 ＜
￣Y^Y^Y^Y^Y￣
74

83. コミットメッセージ
「なぜ」を残すことを心がけましょう
「なぜ」は機械には判断できない
長くなる場合
１行目に概要
１行空ける
３行目に詳細を書く
75

84. もう一度
やってみましょう
76

85. index.htmlの変更
index.htmlにHTML5のテンプレタグを追加
77

86. SourceTreeをみてみる
78

87. にょきっと生えた
コミット（記録）していない
変更点があるよ
79

88. 直前の記録からの変更
変更されたファイル
80

89. 直前の記録からの変更
追加された箇所
（+で背景が緑色）
81

90. add, commitしてください
82

91. 記録できた！
83

92. もう一度
やってみましょう
84

93. CSSファイルの追加
デザインも変更したいのでCSSファイルを追加
「サイト全体の文字をセンター寄せにしたい」
css/common.css
body {text-align: center;}
85

94. index.htmlの変更
index.htmlでスタイルシートを読み込む
86

95. SourceTreeをみてみる
87

96. 直前の記録からの変更
変更されたファイル
追加されたファイル
88

97. 直前の記録からの変更
追加された箇所
（+で背景が緑色）
追加されたファイル
89

98. add, commitしてください
90

99. 記録できたー！
91

100. ちょっとまって
92

101. add
93

102. add
93

103. add
commit
93

104. この操作必要？
addしてcommitってめんどくないですか？
なんで一回前置きが必要なの？
94

105. 結論：あると便利
95

106. 別のシーンで
やってみましょう
96

107. index.htmlを変更する
センタリングしたのにタグしか書いてなかった
(body以下に何も書いていなかった)
<header>タグを追加しよう
<h1>タグで見出しも追加しよう
あれ、cssのパス指定が間違ってた
×：common.css ○：css/common.css
97

108. index.htmlの変更
あ、<title>タグに何も書いていなかった
そういえばメニューも追加したい
リスト形式でメニューを作ろう
それならそれぞれページも追加しなきゃ
98

109. common.cssの変更
メニュー
リストだけど先頭の「・」をなくしたい
左側の余白が余計なのでなくしたい
99

110. 100

111. その結果
101

112. その結果
102

113. 103

114. ＿人人人人人＿
＞ カオス ＜
￣Y^Y^Y^Y￣
104

115. 一気にファイル変更
しちゃったけど
これ一気にコミットするとダメ…だよね？
コミットメッセージどうするの？
「いろいろ変更」じゃ伝わらない
まずはcssのパスが間違ってたやつをコミットし
たい
そこだけadd（ステージング）すればいい！
105

116. 選択してステージング
※選択行が連続していないと
一度にaddできないため、
一行ずつaddする
106

117. 指定したところだけaddされている
107

118. それ以外は残ったまま
108

119. コミットできた！
109

120. もしステージングエリアがなかっ
たら
記録したくないところまで記録するはめになる
記録したい部分だけ残し、他の変更点を一度破棄
する。それをコミットしてから、さっき破棄した
変更を復元するはめになる
わかりにくいしめんどくさい
110

121. 好き勝手できるところ
次の歴史に刻むものを選出
歴史として記録！
（ワーキングツリー、ワーキングコピー）
（ステージングエリア）
111

122. add
好き勝手できるところ
次の歴史に刻むものを選出
歴史として記録！
（ワーキングツリー、ワーキングコピー）
（ステージングエリア）
111

123. add
commit
好き勝手できるところ
次の歴史に刻むものを選出
歴史として記録！
（ワーキングツリー、ワーキングコピー）
（ステージングエリア）
111

124. 気をつけたい
コミットの粒度
一度にコミットしても分からない
いろいろ修正 → 何を？なんで？
こまめにコミットしすぎても分かりづらい
見出しを追加 → それをセンタリング →
→ それの色を変更 → それの余白を調整 →
→ それの…
ひとつの機能ごとにコミットしましょう
112

125. 練習問題
先ほど変更したものを全部コミットしましょう
ポイント
どんな単位でコミットすればいい？
コミットメッセージはどう書くのがいい？
113

126. 歴史を分岐させる
114

127. 思い出してください
バージョン管理システムの特徴
安心してファイルの変更ができる
前のバージョンに戻せる
特にGitは
手軽にバージョンの切り替えができる
→どういうこと？
115

128. 枝（ブランチ）分かれ
116

129. えいっ
枝（ブランチ）分かれ
116

130. えいっ
やぁっ
枝（ブランチ）分かれ
116

131. えいっ
やぁっ
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
枝（ブランチ）分かれ
116

132. とぉっ
えいっ
やぁっ
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
枝（ブランチ）分かれ
116

133. ブランチの種類
今まで操作していたのはmasterブランチ（本流）
基本masterブランチは直接いじらない
何か作業をする時は、その作業ベースでブランチをつ
くる
バグの修正、新規ページの作成 etc…
ブランチの名前は自分で命名する
作業終了後、問題なければmasterに合流させる
117

134. master（本流）
118

135. master（本流） ＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
118

136. ブランチ
master（本流） ＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
118

137. ブランチ
master（本流） ＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
118

138. ブランチ
master（本流） ＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
＿人人人人＿
＞ 合流 ＜
￣Y^Y^Y￣
118

139. たとえば
サイトをリニューアルしたい
A案とB案があります
だいたいどんな感じになるかな
実物見てどっちが良いか決めたいな
119

140. master（本流）
それぞれのブランチで
ファイルを変更していく
120

141. master（本流）
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
それぞれのブランチで
ファイルを変更していく
120

142. master（本流）
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
それぞれのブランチで
ファイルを変更していく
120

143. A案用のブランチ
master（本流）
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
それぞれのブランチで
ファイルを変更していく
120

144. A案用のブランチ
master（本流）
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
それぞれのブランチで
ファイルを変更していく
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
120

145. A案用のブランチ
master（本流）
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
それぞれのブランチで
ファイルを変更していく
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
120

146. A案用のブランチ
master（本流）
B案用のブランチ
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
それぞれのブランチで
ファイルを変更していく
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
120

147. 実際にやってみよう
ブランチを生やす
121

148. 今回編集するところ
バージョン管理システムとは（index.html）
安心してファイルの変更ができる
前のバージョンに戻せる
差分が見られる
自前でファイル変更に関する情報を残さなくていい
いつ誰がどこを変更したのかわかる
複数人で作業する時ラク
各々の作業をマージできる
122

149. ブランチを生やす
枝分かれさせるには名前が必要
それは何の作業をするために分岐させるのか
沢山切ってたら何がどれか分からなくなる
必ず意味のある名前を！
命名規則はプロジェクトなどによって違うので
注意！
123

150. こちらから
124

151. 125

152. ブランチつくれた
作成したブランチ
126

153. 127

154. チェックアウト#とは
指定のコミット（時点）へ移動する操作
あの頃に戻りたい…。
リポジトリをその頃の状態に戻せる
新規ブランチをチェックアウト
ブランチを作成して、そのブランチの最新のコミッ
トに移動する
コミットをすると、チェックアウトしている（今
いる）ブランチで枝がニョキニョキ増えていく
128

155. ブランチを作成してチェックアウトした後、
コミットしていくの図
master（本流）
129

156. ＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
ブランチを作成してチェックアウトした後、
コミットしていくの図
master（本流）
129

157. ＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
＿人人人人人人人人人人人人人人人＿
＞ ブランチAにチェックアウト ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣
ブランチを作成してチェックアウトした後、
コミットしていくの図
master（本流）
129

158. ＿人人人人人人＿
＞ コミット ＜
￣Y^Y^Y^Y^Y￣
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
＿人人人人人人人人人人人人人人人＿
＞ ブランチAにチェックアウト ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣
ブランチを作成してチェックアウトした後、
コミットしていくの図
master（本流）
129

159. ブランチA
＿人人人人人人＿
＞ コミット ＜
￣Y^Y^Y^Y^Y￣
＿人人人人人人＿
＞ コミット ＜
￣Y^Y^Y^Y^Y￣
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
＿人人人人人人人人人人人人人人人＿
＞ ブランチAにチェックアウト ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣
ブランチを作成してチェックアウトした後、
コミットしていくの図
master（本流）
129

160. チェックアウト
忘れてたの図
130

161. チェックアウト
忘れてたの図
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣ 130

162. ブランチA
チェックアウト
忘れてたの図
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣ 130

163. ブランチA
チェックアウト忘れてた
チェックアウト
忘れてたの図
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣ 130

164. ブランチA
チェックアウト忘れてた
チェックアウト
忘れてたの図
＿人人人人人人＿
＞ コミット ＜
￣Y^Y^Y^Y^Y￣
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣ 130

165. ブランチA
チェックアウト忘れてた
チェックアウト
忘れてたの図
＿人人人人人人＿
＞ コミット ＜
￣Y^Y^Y^Y^Y￣
master（本流）
＿人人人人人人＿
＞ コミット ＜
￣Y^Y^Y^Y^Y￣
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣ 130

166. 131

167. master（本流）
現状
132

168. master（本流）
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
現状
132

169. master（本流）
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
＿人人人人人人人人人＿
＞ チェックアウト ＜
￣Y^Y^Y^Y^Y^Y^Y￣
現状
132

170. add-about-vcs
次コミットしたらこうなる
master（本流）
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
＿人人人人人人人人人＿
＞ チェックアウト ＜
￣Y^Y^Y^Y^Y^Y^Y￣
現状
132

171. ファイルを変更する
バージョン管理システムとは（index.html）
安心してファイルの変更ができる
前のバージョンに戻せる
差分が見られる
自前でファイル変更に関する情報を残さなくていい
いつ誰がどこを変更したのかわかる
複数人で作業する時ラク
各々の作業をマージできる
133

172. 134

173. コミットできた！
135

174. その結果
136

175. なんかイケてない…
137

176. ページレイアウト
どうするか
試行錯誤したい
138

177. A案用のブランチ
master（本流）
B案用のブランチ
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
それぞれのブランチで
ファイルを変更していく
＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
139

178. ＿人人人人人＿
＞ これだ ＜
￣Y^Y^Y^Y￣
140

179. その前に
一旦変更を本流に取り込みましょう
これ
141

180. ！注意！
親（master）ブランチから
子ブランチ（add-about-vcs）を統合させる
まず親ブランチにチェックアウトしてから統合
142

181. 143

182. masterをチェックアウト
ダブルクリック
or
右クリックから
144

183. 145

184. 146

185. 147

186. マージできた
148

187. なんかブランチ
一本になってるけど
149

188. master（本流）
150

189. master（本流） ＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
150

190. ブランチ
master（本流） ＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
150

191. ブランチ
master（本流） ＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
150

192. ブランチ
master（本流） ＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
＿人人人人＿
＞ 合流 ＜
￣Y^Y^Y￣
150

193. ブランチ
master（本流） ＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
＿人人人人＿
＞ 合流 ＜
￣Y^Y^Y￣ココと
150

194. ブランチ
master（本流） ＿人人人人＿
＞ 分岐 ＜
￣Y^Y^Y￣
＿人人人人＿
＞ 合流 ＜
￣Y^Y^Y￣ココと
ココが同じ内容
になるなら
150

195. ブランチ
151

196. ブランチ
こうしちゃえ！
master（本流）
151

197. はやおくり！
Fast-Forward
152

198. ちなみに
マージと同時に新しくコミットを作りたい場合
こういう
表示にしたい
153

199. 154

200. マージできた
155

201. Next
156

202. 実際にやってみよう
ページレイアウト変える
157

203. プランAとプランB
プランA
このまま全体がセンター寄りのレイアウト
プランB
文字は左寄せで中のコンテンツが真ん中寄り
どっちがいいかな
158

204. ブランチを生やす
centering-style
このまま全体がセンター寄りのレイアウト
left-justify-style
文字は左寄せで中のコンテンツが真ん中寄り
159

205. 160

206. ブランチを切りかえて
ファイルを変更していく
161

207. centering-style
162

208. body {
text-align: center;
margin: 10px auto;
display: table;
}
nav {
background: #e0e0e0;
}
nav ul {
padding: 0;
}
nav ul a li {
list-style: none;
}
article {
margin-top: 1em;
padding: 0 1em;
border: 1px solid #e0e0e0;
}
section ul {
text-align: left;
}
コピペ用
163

209. 164

210. 165

211. 166

212. 167

213. centering-style
168

214. left-justify-style
プランB
文字は左寄せで中のコンテンツが真ん中寄
り
チェックアウトを忘れずに！
ブランチ切った時点の
状態に戻った！
169

215. left-justify-style
170

216. nav {
background: #e0e0e0;
}
nav ul {
padding: 10px 20px;
}
nav ul a li {
list-style: none;
}
article {
margin-top: 10px;
padding: 10px;
border: 1px solid #e0e0e0;
}
コピペ用
171

217. 172

218. 173

219. 174

220. left-justify-style
175

221. left-justify-style
176

222. 枝っぽくなった
177

223. centering-style
ブランチにきりかえて
index.htmlをみてみる
178

224. centering-styleだ！
179

225. ＿人人人人人＿
＞ すごい ＜
￣Y^Y^Y^Y￣
180

226. こんなに簡単に出来たら
安心してファイルの変更ができる
ファイル変更によって何か問題が起こっても、
その問題が起きる前の状態にすぐ戻れる
試行錯誤しやすい
181

227. NEXT
182

228. masterにマージしよう
よし！これでOKとなったら本流に取り込みたい
全部センター寄りの方が統一性あるのでは？
今回はプランAを採用したい
centering-styleをマージする！
183

229. master
184

230. master
184

231. centering-style
master
184

232. centering-style
＿人人人人人＿
＞ マージ ＜
￣Y^Y^Y^Y￣
master
184

233. やってみよう
185

234. masterに
チェックアウト
186

235. centering-styleを選択
選択
187

236. マージできた
188

237. NEXT
189

238. ファイルの変更を
なかったことにしたい
（reset/リセット）
190

239. 世の中には
理不尽なこともあります
191

240. いや、B案にするのだ
192

241. ＿人人人人人人人＿
＞ ファッ！？ ＜
￣Y^Y^Y^Y^Y^Y￣
193

242. 思い出してください
元に戻してって言われても戻せなかった
「元」がなんだったか覚えてない
エディタ閉じちゃったらバックも使えない
index_yyyymmdd.html
index_old.html
ファイルが多くてどれが本当か分からない
194

243. Gitなら簡単に
戻せるんですよ！
195

244. 戻したい時点のコミットを選択
右クリック
選択
196

245. モードをHardにする
197

246. 198

247. 199

248. 無視して進めましょう
200

249. 元に戻った！
201

250. で、
202

251. さっきのモードって何？
203

252. ひとつひとつ
やってみましょう
（だってすぐ戻せるんだもん）
204

253. もう一度マージ
205

254. もう一度リセット
206

255. モードをMixedにする
207

256. あれっ
208

257. ファイルを変更した状態に
209

258. 確認その１
210

259. centering-styleブランチで
変更した内容は保持されるが
211

260. 確認その２
212

261. インデックスをリセットする
（addする前の状態にする）
213

262. もうひとつやってみましょう
（だってすぐ戻せるんだもん）
214

263. その前に
215

264. 変更をなかったことにする
216

265. 変更が破棄された
reset（hard）した時と
同じ状態に！
217

266. centering-styleを
再びマージ
218

267. モードをsoftにしてリセット
219

268. ファイルを変更した状態に
220

269. 確認
221

270. centering-styleブランチで
変更した内容も保持されて
222

271. ステージングした状態にする
（addした後の状態にする）
223

272. 224

273. つまり
225

274. リセットのモード
Soft
ファイルを変更してaddした状態まで戻す
mixed
ファイルを変更してaddする前の状態まで戻す
Hard
ファイルを変更する前に戻す
226

275. リセットのモード
Soft
ゆる〜いリセット
Mixed
そこそこゆる〜いリセット
Hard
つよいリセット
迷ったらSoftに
しておけば安全
227

276. 228

277. 229

278. 改めて
left-justify-style
ブランチをマージ
230

279. tips
231

280. マージ時は常に新しい
コミットを作る
いちいち毎回チェック入れるの面倒
SourceTree > 環境設定から設定
これ
232

281. マージ時は常に新しい
コミットを作る
233

282. left-justify-styleを選択
最初から
選択されている
234

283. マージできた
235

284. 思い出してください
元に戻してって言われても戻せなかった
「元」がなんだったか覚えてない
エディタ閉じちゃったらバックも使えない
index_yyyymmdd.html
index_old.html
ファイルが多くてどれが本当か分からない
236

285. 思い出してください２
バージョン管理システムの特徴
安心してファイルの変更ができる
前のバージョンに戻せる
特にGitは
手軽にバージョンの切り替えができる
237

286. ＿人人人人人人人人人＿
＞ 気軽にやり直せる ＜
￣Y^Y^Y^YY^Y^Y^Y￣
238

287. 直前のコミットを
やり直したい
（上書きしたい）
239

288. headerのスタイル変更
目立たせたい
濃いめの背景（#000000）
テキストの色を白にしたい（#FFFFFF）
トップページへのリンクも付けたい
ブランチ名：change-header-style
240

289. 241

290. 242

291. 243

292. やっぱり真っ黒って
イケてない
243

293. やっぱり真っ黒って
イケてない
それだけのために新し
いコミット作るのも
243

294. 244

295. 245

296. 246

297. 上書きできた
247

298. こんな時につかおう
コミットした後にtypo（タイピングミス）を
見つけてしまった
コミットした後に変換ミスを見つけてしまった
わざわざ新しいコミットを作るまでもない時に
→ 直前のコミットしか上書きできないので注意！
（この方法では）
248

299. ヘッダ変更の続き
249

300. この辺の
余白いらない
250

301. 251

302. 252

303. 253

304. 変更できたので
マージする
254

305. 右クリックからでも
マージできる
255

306. 右クリックからでも
マージできる
256

307. 右クリックからでも
マージできた！
257

308. 総合れんしゅう
※あくまで操作に慣れるためで
課題については特に意味ないです
258

309. 1. リポジトリを作成
「my_profile」というリポジトリを作成
「yourname.md」(自分の名前)というファイルを
作成
一行目に「# 自己紹介」と記述
add、コミットしてください
259

310. 2. 基礎情報を追記
「yourname.md」を編集
## 基礎情報
+ 名前：あなたの名前
+ 誕生日：YYYY年M月D日
+ 出身：
+ 血液型：
作業は「add-basic-info」ブランチを作成してから
260

311. 3. add-basic-infoをマージ
「add-basic-info」ブランチをmasterにマージ
マージ時には新しいコミットを作成するように
261

312. 4. 自分の好きなものを追記する
ブランチは「add-favorite-things」
## 好きな食べ物
+ 寿司
+ カニ
## 好きなお酒
+ ビール
+ 日本酒
262

313. 5. add-favorite-thingsを
masterにマージ
マージ時には新しいコミットを作成するように
263

314. 6. 自分の嫌いなものを追記する
ブランチは「add-unfavorite-things」
嫌いな食べ物
嫌いな生き物
嫌いな季節
264

315. 7. 自分の嫌いなものを編集する
「嫌いな食べ物」「嫌いな生き物」「嫌いな季節」
とコミットしたけれど、動物愛護団体に怒られる
のは嫌なので「嫌いな生き物」の記述を削除
（だけど「嫌いな季節」はのこしたい）
ヒント
「嫌いな食べ物」をコミットした時点までの歴史
を取り消して、「嫌いな季節」の部分だけコミッ
トしなおす
265

316. 8. add-unfavorite-thingsを
masterにマージ
マージ時には新しいコミットを作成するように
266

317. 9.自分の経歴を追加
「yourname.md」を編集
## 経歴
+ 幼稚園：なんちゃら幼稚園
+ 小学校：なんちゃら小学校
+ 中学校：なんちゃら中学校
作業は「add-my-career」ブランチを作成してか
ら
267

318. 10.自分の経歴の詳細を追加
あっ、せっかくなので一言二言追加したい！
新たに「add-detail-my-career」ブランチを作成
してから作業する
## 経歴
+ 幼稚園：なんちゃら幼稚園
+ 結構活発だった気がする
268

319. 11. add-detail-my-career
ブランチをマージ
「add-detail-my-career」ブランチを
「add-my-career」ブランチにマージ
269

320. add-my-career
master
add-detail-
my-career
こんなイメージ
270

321. 12. 再び自分の経歴を追加
高校と大学の項目をそれぞれ追加
今度は詳細も同時に追加していくスタイルで
追加できたらmasterにマージする
新たにこみt(ry
271

322. こわくないGit
神スライド
本当は怖くない！デザイナーがGitを大好きになっ
た５つの理由
絵がかわいい、例がわかりやすい
LearnGitBranching
触りながら学べるけど日本語訳わかりづらい
学習のすすめ
272

323. おまけ
用語集的なもの
273

324. リポジトリ
ファイルを管理するプロジェクトの単位
.gitがあるディレクトリ＝gitのリポジトリ
参考スライド
274

325. add（ステージング）
コミットする前に必要な動作
ファイルの変更をした後、コミットしたい部分を
選ぶこと
参考スライド
基礎
行単位でadd
commitとの関係
275

326. commit（コミット）
実際にファイルの変更を記録する動作
commitする前にaddしないと何も記録できない
参考スライド
基礎
addとの関係
276

327. branch（ブランチ）
ある一連のコミットの連なりを、ほかと区別する
ために設定するもの
リポジトリを新規作成してコミットすると、
masterというブランチが作られる
一般的に、作業ベースでブランチを作ってmaster
に統合させる作業フローが多い
参考スライド
277

328. checkout（チェックアウト）
あるコミット（時点）へ移動する操作
リポジトリ内はその時点の状態に変化する
参考スライド
278

329. merge（マージ）
branchどうしを統合させる動作
新たにコミットを作るマージと、
早送りマージがある
参考スライド
基礎
早送りマージ
279

330. reset（リセット）
変更（コミット）を取り消す操作
Soft, Mixed, Hard の３つのモードがある
参考スライド
基礎
リセットのモード
280