Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

新人Git/Github研修公開用スライド(その2)

5.789 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

新人Git/Github研修公開用スライド(その2)

  1. 1. Git / Github 研修 後半戦! 2015/6/4,5 株式会社ヴァル研究所 ぷぽ(@pupupopo88) 公開用
  2. 2. このスライドについて 新人研修でやった内容を一部公開用に修正したもの 研修の対象(想定) 開発未経験者(数名程度) 配属も開発とは限らない HTML5とCSS3の基本はレクチャー済み イメージを持ってもらうことを優先しているため、 多少表現に無理(まちがい)があります 2
  3. 3. ざっくりなもくじ Githubとは Githubにリポジトリをつくる 分散型のバージョン管理システム リポジトリをクローンする Githubをつかった作業フロー コンフリクトの解消 リモートブランチをローカルに持ってくる チーム開発・プロジェクト管理(issueなど) 3 p. 7 p. 12 p. 43 p. 69 p. 83 p.149 p.172 p.185
  4. 4. おさらい 4
  5. 5. バージョン管理システムとは 安心してファイルの変更ができる 前のバージョンに戻せる、差分が見られる 自前でファイル変更に関する情報を残さなくていい いつ誰が変更したのかわかる 複数人で作業するときラク 各々の作業をマージできる 5
  6. 6. 特にGitは ブランチ切ったりバージョンの切り替えがラク 安心度が高い 複数人で作業しやすい 6
  7. 7. 特にGitは ブランチ切ったりバージョンの切り替えがラク 安心度が高い 複数人で作業しやすい 
 →まだイメージできないですよね 6
  8. 8. 7
  9. 9. Githubとは リポジトリ(コード)のホスティングサービス ソーシャルコーディングの場 8
  10. 10. _人人人人人人人_ > ファッ!? <  ̄Y^Y^Y^Y^Y^Y ̄ 9
  11. 11. Githubとは リポジトリ(コード)のホスティングサービス ソーシャルコーディングの場 10
  12. 12. どういうこと? 社内の共有サーバをつかってたら外の環境からア クセスできなかった
 
 → 社内ネットワークから(有線LAN)
   じゃないとアクセスできない Githubはネットさえ繋がっていれば使える! 11
  13. 13. どういうこと? 社内の共有サーバをつかってたら外の環境からア クセスできなかった
 
 → 社内ネットワークから(有線LAN)
   じゃないとアクセスできない Githubはネットさえ繋がっていれば使える! 
 → 障害さえ起きていなかったら… 11
  14. 14. イメージ 12
  15. 15. Githubさんにコード (リポジトリ)を 預けてみよう 13
  16. 16. これを預ける 14
  17. 17. https://github.com 15
  18. 18. リポジトリを預ける場所を作る 16
  19. 19. 名前とか決める 17
  20. 20. リポジトリの種類 18
  21. 21. Public 何個つくっても無料! 全世界に公開される
 →Github上の検索だけではなく、ググってもヒッ トする
 →Githubアカウント持ってない人も見られる 扱いに注意 個人情報やパスワードなど、重要な情報をコミッ トしない 19
  22. 22. Private 有料 リポジトリの上限数でプランが異なる 会社アカウントで有料プラン登録してあります
 →作りたい場合は管理者に連絡(おまかせあれ) 非公開 ググってもGithubの検索でも出てこない 権限与えた人しか見られない だけどパスワードとかはコミットしない! 20
  23. 23. リポジトリ作成 21
  24. 24. 預ける場所用意できた! 22
  25. 25. 預ける場所用意できた! 22 カラのリポジトリ
  26. 26. リモートを指定する 23
  27. 27. リモートリポジトリを指定する Github上にあるのが親玉(リモートリポジトリ) それを直接いじるのではなく、個々人のPCに置い てある分身(ローカルリポジトリ)を変更してい くスタイル
 →おや、なんか似たようなことやりましたね 個々人が「分身」で作業したものを、「親玉」に 送る(同期)することで作業を進めていく 24
  28. 28. イメージ 25
  29. 29. イメージ 25 俺の親玉はココ!
  30. 30. 実際にやってみる 26
  31. 31. リポジトリ>リモートを追加 27
  32. 32. httpsの方のパスをコピペ 28 httpsに切り替えてコピペ
  33. 33. 設定ファイルを変更 29 表記違うけど
 気にしないで!
  34. 34. リモートの設定が できました 30
  35. 35. リモートリポジトリに送る 31
  36. 36. リモートリポジトリに送る 32 送りたいブランチを選択
  37. 37. こんな画面出るかも 33
  38. 38. git_practice/master 34 なんか増えた
  39. 39. さっきは場所を用意しただけ 35
  40. 40. 同期できてるっ! 36
  41. 41. プッシュ = リモートに送る 37
  42. 42. これぞリポジトリの ホスティングサービス 38
  43. 43. Githubを利用した開発 Github上にあるのが親玉(リモートリポジトリ) それを直接いじるのではなく、個々人のPCに置い てある分身(ローカルリポジトリ)を変更してい くスタイル 個々人が「分身」で作業したものを、「親玉」に 送る(同期)することで作業を進めていく 39
  44. 44. 40
  45. 45. 40 こっちをいじる
  46. 46. 分散型 といいます 41
  47. 47. 何がいいの? 42
  48. 48. 思い出してください みんなで一つの共有フォルダを使ってたら大変 私編集したのに勝手に変更が上書きされてる! 他の人が作業しているとき手持ち無沙汰 誰がどんな意図でファイルを変更しているかわ からん! ネットが切断されたらファイルがいじれなく なった! 43
  49. 49. 分散型だと ネットに繋がってなくても手元の環境(自分の PC)でファイルの変更ができる 他の人の変更をむやみに壊さない 親玉(リモートリポジトリ)をむやみに壊さない 自分の環境が死んでも親玉や他の人のローカル環 境で生きている! 44
  50. 50. 分散型は安心 45
  51. 51. ネットが死んでも 46
  52. 52. ネットが死んでも 46
  53. 53. ネットが死んでも 46 こっちはいじれる
  54. 54. リモートに問題起きても 47
  55. 55. リモートに問題起きても 47
  56. 56. リモートに問題起きても 47 こっちはいきてる (またpushできる)
  57. 57. ローカルに問題起きても 48
  58. 58. ローカルに問題起きても 48
  59. 59. ローカルに問題起きても 48 こっちはいきてる (複製できる)
  60. 60. ローカルAに問題起きても 49
  61. 61. ローカルAに問題起きても 49
  62. 62. ローカルAに問題起きても 49 こっちも
  63. 63. ローカルAに問題起きても 49 こっちもいきてる こっちも
  64. 64. Gitは ブランチ切ったりバージョンの切り替えがラク 安心度が高い 複数人で作業しやすい 50
  65. 65. これぞリポジトリの ホスティングサービス 51
  66. 66. えっ? 52
  67. 67. コード(リポジトリ)が いろんなとこにあるって 53
  68. 68. しっちゃか
 めっちゃかじゃん 54
  69. 69. Githubを利用した開発 Github上にあるのが親玉(リモートリポジトリ) それを直接いじるのではなく、個々人のPCに置い てある分身(ローカルリポジトリ)を変更してい くスタイル 個々人が「分身」で作業したものを、「親玉」に 送る(同期)することで作業を進めていく 55
  70. 70. ブランチを活用する 基本は直接masterブランチをいじらない 基本は直接masterブランチをpushしない 各々の手元(ローカル)でブランチを作って編集、 pushする リモートにそれぞれブランチを送りつける
 →問題がなければとりこんでもらう(マージ) 問題がないかどうかは、一緒に作業している人 などに確認してもらおう! 56
  71. 71. イメージ 57 push push
  72. 72. 手持ちぶさたに ならない! 58
  73. 73. これぞ ソーシャルコーディング 59
  74. 74. 他にも 60
  75. 75. こんな風に 61
  76. 76. こんな風に 61 指摘してみたり
  77. 77. コードを指定してコメントも 62
  78. 78. 議論する場にしたり 63
  79. 79. いろんなコードが見られたりと 64
  80. 80. いろんな人と関われる ユーザーをフォローしたり、リポジトリをウォッ チする(ブックマーク的な) 自動で活動状況を受け取れる
 →Twitterみたいですね いろんな人、いろんなサービスのコードを読むこ とができる バグ修正などで貢献(コントリビュート)できる 65
  81. 81. ワイワイやろうぜ! 66
  82. 82. これぞ ソーシャルコーディング 67
  83. 83. 詳しくは Web制作者のためのGitHubの教科書
 http://www.amazon.co.jp/dp/4844337009/ 68
  84. 84. とにかく 特に大事なところは さわって覚えよう 69
  85. 85. リモートリポジトリを ローカルにクローンする 70
  86. 86. さっきは 自分の手元にあったものをGithubに送った Github上にリポジトリを作る ローカルリポジトリをプッシュ 71
  87. 87. さっきは 自分の手元にあったものをGithubに送った Github上にリポジトリを作る ローカルリポジトリをプッシュ →次は既にGithubに置いてあるものを手元へ複製 71
  88. 88. さっきはGithubにのっけた 72
  89. 89. つぎはGithubからもってくる 73
  90. 90. SourceTreeで クローンする 74
  91. 91. こちらから ファイル > 新規 / クローンを作成する 75
  92. 92. クローンする URLからクローン 76
  93. 93. リモートの住所をコピー HTTPSの方を選択し、コピーしてください 77
  94. 94. ソースURLにコピペ 保存場所を指定してクローンを押してください 78
  95. 95. クローンできた! 79
  96. 96. こいつら何? 80
  97. 97. originって何よ origin = https://github.com/pupupopo88/ github_practice/ リモートを指す言葉で別名みたいなもの origin/master リモート の master origin/HEAD リモートの HEAD(最新のコミット) 81
  98. 98. origin/masterとmaster 82 リモートのmasterと ローカルのmasterが同じ (同期できてる)
  99. 99. 準備ができました 83
  100. 100. Githubさんを 使ってみよう 84
  101. 101. _人人人人人人人人人人人人_ > 突然のあいうえお作文 <  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y ̄ 85
  102. 102. 86
  103. 103. ローカルリポジトリを編集 試しに、誰かローカルリポジトリを編集してみま しょう backronym.md ブランチを作る 「あ」の文字を編集する 「あいうえお作文と」と書いてね コミットしてプッシュ 87
  104. 104. ブランチをプッシュ 88
  105. 105. 他の人のリポジトリは… 何も変わってない origin/add-a-lineは増える 自分の所には影響していない 完全に独立(分散)している! 89
  106. 106. リモート(Github)の様子 90
  107. 107. Network(ツリー)を見てみる 91
  108. 108. この変更どうするの? さっき少しお話ししました ソーシャルコーディング 「これを取り込んでください」とお願いする! add-a-lineってブランチ投げたから、
 よかったらmasterにマージしてよね!
 →プルリクエスト(プルリク)を出す 92
  109. 109. やってみよう 93
  110. 110. Githubを見てみる 94
  111. 111. プルリクエストの画面 95
  112. 112. 取り込む(食べる)方 プルリクエストの画面 95
  113. 113. 取り込む(食べる)方 取り込まれる (食べられる)方 プルリクエストの画面 95
  114. 114. 96
  115. 115. 96 タイトルは変更点の 概要をわかりやすく
  116. 116. 96 タイトルは変更点の 概要をわかりやすく コメントも!
  117. 117. 差分も見られる 97
  118. 118. 差分も見られる 97 Viewをクリックすると
  119. 119. mdも見やすくなる! 98
  120. 120. mdも見やすくなる! 98 マークダウンでなければ ソースがそのまま表示
  121. 121. 問題なければ 99
  122. 122. プルリクエストが出せた! 100
  123. 123. この後どうするんだっけ add-a-lineってブランチ投げたから、
 よかったらmasterにマージしてよね!
 →プルリクエスト(プルリク)を出す 問題無かったらmasterにマージする 基本的にプルリクを出した人以外が確認し、
 masterにマージしてもらう 101
  124. 124. やってみよう 102
  125. 125. だーくぷぷぽぽさん 103
  126. 126. 変更されたファイルを確認 104
  127. 127. 105
  128. 128. 行選択でもコメントできる 106
  129. 129. コミット単位でも確認できる 107
  130. 130. コミットごとの変更 108
  131. 131. 実際にコメントしてみる 109
  132. 132. コメントできた! 110
  133. 133. いよいよ マージします 111
  134. 134. マージ先問題ないよね 112
  135. 135. 取り込む(食べる)方 マージ先問題ないよね 112
  136. 136. 取り込む(食べる)方 取り込まれる (食べられる)方 マージ先問題ないよね 112
  137. 137. ワンクリックマージ 113
  138. 138. 念押しされるけどそのままマージ 114
  139. 139. マージできた! 115
  140. 140. Network(ツリー)を見てみる 116
  141. 141. Network(ツリー)を見てみる 116 マージされてる!
  142. 142. ブランチも消しちゃおう 117
  143. 143. プルリク形式の良いところ 誰が何の作業をしているかわかりやすい 情報が残る 属人化しにくい 人から指摘をもらえる 自分の勉強にもなる 個人の責任にしない チームに責任を持たせる 118
  144. 144. チーム開発にとって この上ない仕組み!! 119
  145. 145. ところで リモートでマージが行われたけれど、実はローカ ル環境は古いまま… 120
  146. 146. ところで リモートでマージが行われたけれど、実はローカ ル環境は古いまま… 120 手元のmaster
  147. 147. ところで リモートでマージが行われたけれど、実はローカ ル環境は古いまま… 120 手元のmaster リモートのmaster
  148. 148. リモートの変更を
 ローカルに反映する 121
  149. 149. 122
  150. 150. 123
  151. 151. 何か変わった? 124
  152. 152. fetch(フェッチ) リモートの状態をローカルに持ってくる(だけ) 自動で取り込んではくれない SourceTreeさんは(設定で)定期的に情報をもっ てきたりしてくれるので不要だったりする 何もしていないのに、コミットグラフに 「origin/master」とか書いてありますよね 覚えるためにも念のため毎回やりましょう 125
  153. 153. 進めます 126
  154. 154. さっそくマージする 127
  155. 155. 128
  156. 156. マージできた! 同期できた状態! 129
  157. 157. マージできた! 同期できた状態! 129 ローカルのmaster
  158. 158. マージできた! 同期できた状態! 129 ローカルのmasterリモートのmaster
  159. 159. なんでチェックはずすの? 130
  160. 160. コミットつくっちゃったら ローカルのmasterがリモートのmasterよりひと つコミットが増えてしまう origin/master と master が同じではなくな る 131
  161. 161. コミットつくっちゃったら ローカルのmasterがリモートのmasterよりひと つコミットが増えてしまう origin/master と master が同じではなくな る 131 リモートと比べると
 1つ先に進んでるよ
  162. 162. 設定をもどしておこう もう慣れたと思うので、Fast-Foward可能でもコ ミット作るオプションを解除しておく 132 解除!
  163. 163. Next 133
  164. 164. みんな同時に 作業してみよう! 134
  165. 165. 変更する い:言われましても う:うまいこと返せないし え:え…え…。ほら、何も思いつかないじゃん! お:おこだよ! 135
  166. 166. コミット後、そのままプッシュ 136
  167. 167. プッシュできた! 137
  168. 168. もう一方も 138
  169. 169. もう一方も 139
  170. 170. 「い」のプルリク 140
  171. 171. 「い」のプルリクをマージ 141
  172. 172. 「う」のプルリクを作…成…? 142
  173. 173. Can't automatically merge. → 自動でマージできんよ 143
  174. 174. とりあえず作っちゃう 144
  175. 175. 本当にマージできない(戦慄) 145
  176. 176. なんで? 146
  177. 177. 147
  178. 178. 147 origin/master
  179. 179. 147 add-u-line origin/master
  180. 180. _人人人人人人人人人人人_ > どっちが正しいねん <  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y ̄ 148
  181. 181. 複数人で作業していると 同じ部分を修正していると
 競合(コンフリクト)がおきます コンピューターはどっちが正しいかまでは判断で きません どっちが正しいのか教えてあげましょう 149
  182. 182. コンフリクトの解消 150
  183. 183. masterの変更を 取り込む 151
  184. 184. 今こんな状態 152
  185. 185. マージ 153
  186. 186. コンフリクト!(競合) 154
  187. 187. 155
  188. 188. 155 ファイル開く
  189. 189. 156
  190. 190. 156
  191. 191. 156 add-u-line
  192. 192. 156 add-u-line
  193. 193. 156 origin/master add-u-line
  194. 194. 正しいところだけ残して 保存しましょう 157
  195. 195. これが正解! 158
  196. 196. add(ステージング)する 159
  197. 197. コンフリクトがなくなった! 160
  198. 198. コミットする 161
  199. 199. マージ&プッシュできた! 162
  200. 200. プルリク確認してみる 163
  201. 201. _人人人人人人人人人_ > マージできる! <  ̄Y^Y^Y^Y^Y^Y^Y ̄ 164
  202. 202. 165
  203. 203. マージできた! 166
  204. 204. masterの同期もしておきましょう 167
  205. 205. masterの同期もしておきましょう 168
  206. 206. 気をつけたいこと コンフリクト自体は悪いことではない
 チーム開発が活発であれば自然と起こるもの 不用意にコンフリクトしないように気をつける ブランチを作成する際は、
 正しい箇所(最新のmaster等)から作る 同期を忘れない 作業の順番に気をつける 169
  207. 207. Gitは ブランチ切ったりバージョンの切り替えがラク 安心度が高い 複数人で作業しやすい 170
  208. 208. 残りの「え」と「お」 もやってみましょう 171
  209. 209. tips? 172
  210. 210. 他の人が作業していた ブランチをいじりたい 173
  211. 211. こんなこともあります ぷぽさんがブランチAをつくって作業する ぷぽさんがブランチAをpushする ぷぽさんがプルリクを出す ぷぽさんが突然の風邪でおやすみしてしまう だーくぷぷぽぽさんがバグに気づく
 →今すぐ修正したい! 174
  212. 212. こんなかんじで 175
  213. 213. まちがい見つける 176
  214. 214. じぶんのリポジトリにもってくる フェッチしてチェックアウト 177
  215. 215. こうやって 178
  216. 216. もってこれる! 179
  217. 217. もってこれる! 179 origin/add-e-line の状態を利用して
 add-e-lineブランチをつくったイメージ
  218. 218. commit、pushもできるよ 180
  219. 219. プルリクにも反映されてる! 181
  220. 220. 無事にかいけつ! 182
  221. 221. ちゅうい 他の人が同時作業していないか確認する 他の人の変更を上書きしてしまう恐れ 手がかかりそうな場合はおうちゃくしない 元ブランチからさらに別のブランチをつくり、 別途マージさせると安全 183
  222. 222. add-e-line master fix-e-line こんなやつ 184
  223. 223. Next 185
  224. 224. Githubさんは チーム開発をするのに 大変べんり 186
  225. 225. プロジェクト管理 開発作業で出てくる問題 今誰がどんな作業をしているのか 今何が問題になっているのか 次に行うべき作業はなんなのか 期限はいつなのか アジャイル研修思い出して タスク出し、優先順位付け 187
  226. 226. issueをつかってみる 188
  227. 227. こちらから 189
  228. 228. 更にこちらから 190
  229. 229. 提案してみる 191
  230. 230. ラベルもつけられる 192
  231. 231. 自分で設定したいなら 193
  232. 232. こんな風に 194
  233. 233. Milestone issueの親要素となるもの 期間も設定できる Milestone:この期間中にページAを作ります issue:ページAをマークアップ issue:ページAの見出しを青色に issue:ページAの構成を変更 etc… 本研修ではほぼ使いません 195
  234. 234. Assignee 担当者を設定できる 「これ、私がやります!」の意思表示 検索機能により、自分や人が抱えているタスク がわかりやすい 196
  235. 235. issueさくせい 197
  236. 236. issueつくれた 198
  237. 237. ところで 199
  238. 238. これってどうやるの? 200
  239. 239. 絵文字(emoticon)をつかう Githubで実装されている機能 :(コロン)区切りで絵文字が表示される 途中まで入力すると候補が表示される チートシート http://www.emoji-cheat-sheet.com/ 201
  240. 240. そのほかにも 202
  241. 241. 画像とかもつかえる Chrome拡張のLTTMがおすすめ !s でかわいい「寿司ゆき」の画像が! 203
  242. 242. 表現に気をつけよう 文字だけの表現では(意図せず)攻撃的になりがち エラーが出てるから修正して こんな書き方はダメでしょ、修正して こんなクソコード書くとかどんな神経してるの うまく表現を言い換えたり、相手を尊重した発言を 心がける 絵文字や画像で空気をやわらげる 204
  243. 243. たのしく開発するために 205
  244. 244. みんなで工夫する 206
  245. 245. Githubとは リポジトリ(コード)のホスティングサービス ソーシャルコーディングの場 207
  246. 246. 諸刃の剣 Githubはチーム開発を円滑に進めるこの上ない サービス 使い方次第で、良いものにも悪いものにもなる しあわせになれるかどうかはあなた次第 208
  247. 247. 実際にみんなで やってみる 209
  248. 248. これの続きをやりましょう 210 https://github.com/pupupopo88/git_practice このリモートつかって
  249. 249. 手順 こちらから要望(完成図)を出します 機能ごとに作業を分け、issueを作成する 各自役割分担して完成させる  →アジャイル研修思い出してね! 211
  250. 250. 212
  251. 251. とにかくさわるのみ 213
  252. 252. さいごに 214
  253. 253. 本研修の目標はこれだった (なんとなく)「バージョン管理システム」がなん なのかイメージできる (なんとなく)「Git」がなんなのかイメージできる (なんとなく)「Github」がなんなのかイメージで きる GitやGithubを使うことを怖がらない 215
  254. 254. なんとなく イメージできれば おkだった 216
  255. 255. イメージできましたか? 217
  256. 256. 2日間のまとめ 自前で変更管理する大変さ 複数人で作業することのむずかしさ バージョン管理システムとは Gitの特徴 Githubとは 218
  257. 257. バージョン管理システムとは 安心してファイルの変更ができる 前のバージョンに戻せる、差分が見られる 自前でファイル変更に関する情報を残さなくていい いつ誰が変更したのかわかる 複数人で作業するときラク 各々の作業をマージできる 219
  258. 258. Gitの特徴 ブランチ切ったりバージョンの切り替えがラク 処理が高速 安心度が高い 分散型の管理 複数人で作業しやすい 賢いマージ 220
  259. 259. Githubとは リポジトリ(コード)のホスティングサービス ソーシャルコーディングの場 221
  260. 260. おわりに Gitはたくさん失敗して覚えていくもの やらかした数だけ成長します 私もたくさん失敗して、たくさんの人に助けてもら いました Gitは怖くない いくらでも戻せる、やり直せる この研修で伝えたことはほんの一部 開発に配属されたら、ぜひコマンド操作も覚えてね 222
  261. 261. 参考 Web制作者のためのGitHubの教科書
 http://www.amazon.co.jp/dp/4844337009/ 超初心者向け。SourceTreeの使い方多し Github実践入門
 http://www.amazon.co.jp/dp/477416366X/ コマンド使う人向け。Gitそのものについても 入門Git
 http://www.amazon.co.jp/dp/4798023809 入門と思いきや、初心者が買ったら死ぬ 223
  262. 262. おまけ 用語集的なもの 224
  263. 263. リモートリポジトリ 共有ディレクトリみたいなもの ≒Githubに上がっているもの Githubからクローンすると origin という名称が 設定される 参考スライド 基礎 リモートの別称(origin) 225
  264. 264. ローカルリポジトリ リモートリポジトリから複製してきたもの ≒自分のPC上に置いてあるリポジトリ リポジトリを新規作成して、後でGithubなどにアッ プしたい場合、リモートの指定をする必要がある 参考スライド 基礎 リモートの設定方法 226
  265. 265. Publicリポジトリ 公開リポジトリ いくつ作っても無料だが、Googleなどの検索エン ジンでも検索できてしまう 参考スライド 227
  266. 266. Privateリポジトリ 非公開リポジトリ 有料だが、指定したアカウント以外は閲覧も出来 ない 仕事で必要になった場合は、会社アカウントでつ くる(管理者に連絡) 参考スライド 228
  267. 267. clone(クローン) リモートリポジトリからローカルに複製すること Githubからクローンすると、自動でリモートリポ ジトリと紐付けされる(origin) 参考スライド 基礎 SourceTreeでのクローン 229
  268. 268. プルリクエスト(プルリク) 主にローカルリポジトリで作業したものをリモー トリポジトリに取り込んで欲しいときに出すもの 取り込み(マージ)先との差分を確認したり、コ メントすることもできる 行単位、コミット単位でも差分を確認できる 参考スライド 230
  269. 269. fetch(フェッチ) リモートの状態をローカルに持ってくる SourceTreeは(設定で)定期的にfetchしてくれる 自動で取り込んではくれない その情報を取り込みたい場合はマージする必要がある リモートブランチにチェックアウトすると、ローカルリポジ トリにそれと同じブランチを作成することができる 参考スライド 基礎 リモートに存在するブランチをローカルに持ってくる 231
  270. 270. コンフリクト(競合) マージなどをする際、自動で統合できず衝突が起 きてしまった状態のこと 同じファイル、同じ箇所を編集していた場合な どに起きる コンピューターはどちらが正しいか判断できない ため、手動で正しい状態を示す必要がある 参考スライド 232
  271. 271. issue(イシュー) メンバー内で共有したいことなどを記述するもの Redmineでいうチケットみたいなもの マークダウン形式で見やすく記述できる 実はプルリクも1つのissue issueやプルリクに #1 と(issue番号)を記述する と、そのissue(プルリク)へのリンクがつけられる 参考スライド 233
  272. 272. WIP(Work In Progress) まだ作業途中だよという意味 まだマージして欲しくない!というプルリクのタ イトルの頭に[WIP]と記述する 作業途中で意見が欲しくなったときや、変更が 多くなりそうなときなどに
 = 生煮えプルリク 234
  273. 273. LGTM(Looks Good To Me) 「良いと思う」の意味 OK!のようなもの プルリクを確認して問題ないとき、コメントとし て残すことが多い 235

×