社内Git勉強会向け資料
•
0 likes•2,746 views
社内勉強会向けに資料を作りましたので公開します。自分も初心者なので間違っているところもあると思いますので、是非教えてください。
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to 社内Git勉強会向け資料
社内Git勉強会向け資料
- 1. 【Save Your History】 社内 Git 勉強会資料 株式会社エースユニオンデザイン part.1
- 2. 今日のアジェンダ 1. Git 2. SourceTree（ぼっちドリブン編） ウソを教えちゃわないように頑張ります（｀・ ω・´） 僕も初心者なので大目に見てね …
- 3. 1. Git Gitってそもそもなに？ ・ バージョン管理をするツール。 ・分散型バージョン管理システム ・「分散型」？ 基準のデータに対して自分の作業を反映させるのではなく、「自分を基準」とし て、あくまでも自分のデータに対して作業する。 マスターはひとつではなく、作業をする全員の手元にあるのが「それぞれのマ スター」になる。 「公開サーバのデータ」 ≠「マスターのデータ」のこともある。
- 6. まず最初に覚える用語その3 ・origin（オリジン） ・origin: リポジトリの場所(URL)の別名 ・「origin」はデフォルトのリポジトリ ・cloneした時にgitが自動で作成する。
- 8. Gitを使うために（GUI? CLI?） ・GUI (Graphical User Interface) ・CLI (Command Line Interface) GUI＝操作が見た目で直感的にわかる。 Gitの操作の流れを知らなくてはいけないのは CLIと変わらない。 データの量によっては操作が重くなることがある。 CLI＝すべて黒い画面からの操作。軽い。 強制的な修正のために使う必要があるケースも。 最初にターミナルの使い方が第一関門になる。 → GUIの「SourceTree」を使う （Mac用、Win用両方ある。一緒にgitがインストールされる）
- 11. 最初に覚える用語その1 ・ブランチ(branch)には種類がある 【役割】・master branch ・topic branch ・(head) 【所属】・local branch ・remote branch ・tracking branch（追跡ブランチ）
- 12. 最初に覚える用語その1(branch・役割) ・マスター(master branch) ・リポジトリに最初のコミットを行ったときに Gitが作るブランチ。 【運用ルール】 ・このブランチ自体では作業しない ・新たな作業をするときは「ブランチを切る」 ・masterへは「push」するだけ → 「push？」次回。 ・リリースできないものを masterに入れない。
- 13. 最初に覚える用語その1(branch・役割) ・トピックブランチ(topic branch) ・あるブランチから「ブランチを切って」作られたブランチ。 【運用ルール】 ・これが作業用のブランチ（通常「ブランチ」と言ったらこれを指す） ・topic branchはremote repositoryにも存在しうる ・ローカルではいくつ作っても OK ・ある程度自分でルールぎめして管理すればお k ・途中でやめてまた別のブランチを切って作業してもいい ・ブランチの数だけworking treeがどんどん分岐していく → 「working tree？」あとで
- 14. 最初に覚える用語その1(branch・役割) ・ヘッド(head)→ ブランチ名ではない ・いま現在どのブランチで作業しているのかを示す「ポインタ」 → 「head」は「git」が監視するために自動で付与する ・作業しているローカルブランチの先頭に「 head」がつく ・headが外れている状態で作業した時はアラートが出る ！ ・headが移動することで、使用するブランチが変更される。 ・branchの切り替えはcheckoutで。 → 「checkout？」あとで
- 15. 最初に覚える用語その1(branch・所属) ・ローカルブランチ(local branch) ・local repository 内に作られたブランチ。 ・まずはローカルだけで gitに慣れましょう。 【運用ルール】 ・local repository のlocal branchが作業用のブランチ ・topic branchのローカル側のブランチが local branch ・通常はlocal repository のlocal branchの中でcommitしていく。 → 「commit？」あとで
- 16. 最初に覚える用語その1(branch・所属) （参考）リモートブランチ(remote branch) ・remote repository 上のブランチ 【運用ルール】 ・このブランチは直接作業しない（ push、fetchするくらい） ・remote branchのmasterはremote repository にある ・remote branchのmasterが「本公開サーバのソース」である ・masterではないremote branchが「テストサーバ用のソース」 ・誰か独りが管理するのではなく「 全員でメンテナンスする 」つもりで
- 17. 最初に覚える用語その1(branch・所属) （参考）追跡ブランチ(tracking branch) ・これ大事（混乱しやすいので） → 今回は触りません。 ・追跡ブランチはlocal repository 上に作られる。 ・remote branchの情報を持っているブランチのこと。 ・「remote branchの情報」にはこれが表示される。 ・remote branch = tracking branchじゃないこともある。 【運用ルール】 ・最新のremote repository の情報を取得するには fetchする。 → 「fetch？」次回
- 19. 最初に覚えるコマンドその1 ・add ・作業ディレクトリ内の変更をステージングエリアに追加するコマンド。 ・個々のファイルのアップデート内容を次回コミットの対象として指示すること。 ・「git add」コマンドだけでは実際にはローカルリポジトリに何の影響も与えない。 ・選択したファイルをトラック対象（ Git上で変更内容を追跡できる）にしている。 【運用ルール】 なんでステージングが必要なの？ → gitにcommitする内容を選べるから
- 20. 最初に覚えるコマンドその1 ・コミット(commit＝預ける) ・ステージされたスナップショットを local repository に記録するコマンド。 （スナップショット＝git addされたファイル群のこと） ・スナップショットは常にlocal repositoryにcommitされる。 ・local repository にcommitを蓄積することができる。 【運用ルール】 ・commitは出来る限り細かい粒度で行う。 → ひとまず、複数のバグの修正をひとつの commitのまとめる等はNGで。 ・commitの際に必ず適切なコメントをつける 。 → 他の作業者が見た時に commitの内容がわかるように
- 21. 最初に覚えるコマンドその1 ・コミット(commit＝預ける) 【運用ルール・コメントの書き方編】 ・以下のフォーマットで。 1行目 ：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降 ：変更した理由（内容、詳細） 日本語でも英語でも OKだが、リポジトリ内で統一するのが吉。
- 22. 最初に覚えるコマンドその1 ・コミット(commit＝預ける) 【運用ルール・コメントの記述例編】 ・commitの種別 fix ：バグ修正 hotfix：クリティカルなバグ修正 add ：新規（ファイル）機能追加 modify：機能修正（バグではない） change：仕様変更 clean ：整理（リファクタリング等） disable：無効化（コメントアウト等） remove ：削除（ファイル） upgrade：バージョンアップ revert ：変更取り消し
- 29. (´ ; ω ; ｀)
- 31. SourceTree を使いながら覚えます。 コマンド分からない…(´ ; ω ; ｀) ・最初はわからなくても大丈夫。 ・ただ、コマンドを知らないと「こういう時はどうするの？」がわからないので。 ・GUIのSourceTreeの裏側でやっていることは単なるコマンド操作です。 ・先々コマンドラインから使うことになってもコマンドの意味がわかります。 ・だから「使いながら覚える」です。
- 33. SourceTree を使ってみよう 2.新しく始める 「New Repository 」をクリック ・「Clone〜」：gitのリポジトリをローカルにクローン（コピー） ・「Add existing〜」：今あるディレクトリを gitに登録 ・「Create local〜」：local repository を新たに作る ・「Create remote〜」：remote repository を新たに作る
- 34. SourceTree を使ってみよう 2.新しく始める 1.「Clone from URL 」を選択 ・「Source URL」：web上のgitのリポジトリのURL ・「Destination Path 」：コピー先のgitリポジトリへのパス → 新たにディレクトリが作られるので、任意の場所に書き出すように指定。 ・「Name」：リポジトリの名前 = git clone（ブランチやコミットの情報もすべてローカルにコピー）
- 35. SourceTree を使ってみよう 2.新しく始める 2.「Add Existing local repository 」を選択 ・フォルダ選択画面が開く ・gitリポジトリとして登録したいフォルダを選択して「開く」
- 36. SourceTree を使ってみよう 2.新しく始める 3.「Create local repository」を選択 ・「Destination Path 」：新たに作るgitリポジトリへのパス ・「Name」：リポジトリの名前 → この場合も新たにディレクトリが作られる。 ・まずはここから。一人で Git管理してみましょう。
- 37. SourceTree を使ってみよう 2.新しく始める ちなみに、コマンドで言うと「 git init」 ・init=initialize （初期化） ・gitリポジトリとして登録したいフォルダを「初期化」する。
- 38. SourceTree を使ってみよう 3.local repositoryを作る 「Create local repository」を選択 【運用ルール】 ・「Destination Path 」：任意の新しいディレクトリを指定する → 案件名でディレクトリを作成する ・「Name」：任意の名前をつける → [案件名]名前-(html|php|wp)-local ・ディレクトリ名は2byte文字は使わないこと！ （正しく認識されないかも）
- 39. SourceTree を使ってみよう 3.local repositoryを作る カラのリポジトリが作られる その時のディレクトリを見るときは「 Finderで開く」をクリック ← 中身はこんな状態 「.git」ディレクトリがあるだけ 「.git」ディレクトリ内に履歴が記録される
- 42. SourceTree を使ってみよう 5.いよいよファイル管理 1.「index.html」を作成 ・ファイルを新規作成するときは普通に Finderからでいい。 ・特に一番最初はgitに全く管理されていないので気にしない。 → いつものエディタでいつもどおりに。 ・今回はダミーで。
- 46. SourceTree を使ってみよう 5.いよいよファイル管理 4.git addしてステージング ステージングされるとファイルの表示される場所が変わる 。 「？」マークが「＋」マークに！ ステージングされてcommitする準備ができた、ということ。 → この時点で「Indexにステージしたファイル」のチェックを外せば ステージングは解除される （それぞれのチェックを個別に外しても同じ）。
- 49. SourceTree を使ってみよう 5.いよいよファイル管理 6.コミットメッセージを記述する こんな感じで。最初の commitは「first commit」がお約束。 確認して問題なければ「コミット」ボタンをクリックする。
- 50. SourceTree を使ってみよう 5.いよいよファイル管理 7.できた！…あれ？ → 落ち着いてサイドバーの「ブランチ > master」をクリック
- 52. （・∀・） おめでとうございます
- 54. SourceTree を使ってみよう 6.first commitの次にすること 2.ブランチを切る ・作業をするブランチを作る。 → 上部のアイコンの中から「ブランチ」をクリックする。
- 55. SourceTree を使ってみよう 6.first commitの次にすること 2.ブランチを切る プルダウンが出てくるので新規ブランチ名を入力。 【運用ルール】 ・最初に作るブランチ名は『 dev-(html|php|wp)- 名前-案件名 』で。 ・すべての作業は基本的にこのブランチでする 。
- 56. SourceTree を使ってみよう 6.first commitの次にすること 2.ブランチを切る できた！（・∀・） → サイドバーで「いまどこのブランチにいるか」を 必ず把握すること。 ハイライトしているところではなく、太字のところ にいる！ よくあるミス → 違うブランチで作業して commitしてたorz
- 58. SourceTree を使ってみよう 7.SourceTreeの画面の説明 2.「グラフ」 ・いわゆる「ツリー」がこれ。 ・「ワーキングツリー」とは「 いま自分が作業している場所 」。 ・「ワーキングツリー」は二重丸で表示されている。 ・クリックすることでツリー内を自由に行き来できる。 ・ダブルクリックでブランチを切り替え（ =checkout）できる。
- 59. SourceTree を使ってみよう 7.SourceTreeの画面の説明 3.「説明」 ・コミットコメントを表示 ・枠で囲まれているのは「ブランチ名」。 ・「ブランチ名」のところが「 そのブランチのいま現在の状態 」。 ・ここの説明と並んだ位置のグラフが対応している。 ・この部分をクリックして切り替えできるのもグラフと一緒。
- 62. SourceTree を使ってみよう 8.ローカルブランチで作業 1.次にファイルの編集・追加・削除をしたら？ ・基本的に「add」「commit」の繰り返し。 ・commitする前のツリーは画像のような状態になっているはず。 ・上に伸びている「Uncommited changes 」がまだ反映されていない変更分。
- 63. SourceTree を使ってみよう 8.ローカルブランチで作業 2.自分のタイミングでcommitする 【運用ルール】 ・特別な決まりはないが、ひとまとまりの作業が済んだら。 ・ある程度は細かくcommitしておいたほうがあとで戻るのはラク。 ・「Uncommited changes 」をクリックすると詳細部分で変更が確認できる。
- 64. SourceTree を使ってみよう 8.ローカルブランチで作業 3.Uncommited changes をadd + commitした状態 devブランチが進んでいるのがわかる。 【運用ルール】 ・当面、ローカルでの作業中は「 master」ブランチは触らなくていい。 ・リモートリポジトリを使うまではかえってわかりづらいだけなので。
- 66. SourceTree を使ってみよう 9.途中に戻って作業をやり直したい 1. branchに対するcheckout 「branchを切り替えるコマンド」 ・複数のブランチがある場合に選択できる → 作業ディレクトリの中身がまるっと入れ替わる！
- 67. SourceTree を使ってみよう 9.途中に戻って作業をやり直したい 2. commitに対するcheckout 「新たにbranchを切る準備のコマンド」 ・選択したcommitの場所に新たにブランチが作られる → 作業ディレクトリがそのコミットと完全に一致した状態になる ・そこから作業を始めれば全く別の作業ができる ・もちろんあとで元のブランチに戻ることもできる commitをcheckoutしてもリポジトリには全く影響がない
- 68. SourceTree を使ってみよう 9.途中に戻って作業をやり直したい 3. fileに対するcheckout（参考） 「fileの中身を確認するコマンド」 新しいスナップショットに再コミットすることができる → ファイルの変更を上書きできてしまうので使いドコロに注意！ 過去のファイルとのdiffを取るときなどに使う。
- 70. SourceTree を使ってみよう 10.checkoutしてブランチを切る 【解説】（参考） ここから先の作業は「git reset --hard」を含んでいま す。作業を完全に元に戻す便利な方法ですが、リモートリ ポジトリにpushしたあとに、pushする以前のcommitに対 して「git reset --hard」すると全員の履歴に影響が 及んで大混乱が起きます。 この手順は「git pushする前のローカルリポジトリでだ け」有効な手段、と考えてください。
- 71. SourceTree を使ってみよう 10.checkoutしてブランチを切る 1. 今いる場所でブランチを切る 今の状態を保存するためのブランチを作る。 ・「戻りたい場所」をきちんと確認する（今回は例として 1つ戻る）。 ・コミットを細かくしておくとこの時点での選択が楽になる。
- 72. SourceTree を使ってみよう 10.checkoutしてブランチを切る 2. ブランチを切る 「Branch」ボタンをクリック → 「新規ブランチ」。 【運用ルール】 ・一旦保留にするブランチ名は『 temp00-名前-案件名 』で。 ・先々このブランチ（の一部とかファイルの参照とか）を使うかも しれないので、消さずに残しておいたほうが吉。
- 74. 「 dev- 」を元に戻します ( ｰ`дｰ´)ｷﾘｯ
- 75. (´ ; ω ; ｀)
- 76. SourceTree を使ってみよう 10.checkoutしてブランチを切る 3. 「dev-」をcheckoutする デフォルトではブランチを新規作成すると同時に checkoutしている。 サイドバーの「dev-」をダブルクリックすれば checkoutできる。
- 78. SourceTree を使ってみよう 10.checkoutしてブランチを切る 5. ポップアップの内容を確認し、モードを「 Hard」にする。 「Hard」モードは『 完全に削除 』なので取り扱いに要注意。
- 79. SourceTree を使ってみよう 10.checkoutしてブランチを切る 6. 再度怖いアラートが出る (´；ω；｀) 大丈夫。「OK」をクリックする。
- 80. SourceTree を使ってみよう 10.checkoutしてブランチを切る 7. 無事に戻った！( ´ー｀)ﾌｩｰ なんでこんな心臓に悪いこと …。 【運用ルール】 ・作業をするところはあくまでも「 dev-」。 ・そうすればいつでも誰でも作業を引き継げるので。 ・後から見直した時にもすぐ内容が把握できる。
- 82. SourceTree を使ってみよう 11.【Tips】いろいろな『戻る』 0. ここから先の注意点 gitにはあらゆるコマンドが用意されているので、間違った操作をしても ほとんどの場合また元に戻せます（ 戻せないものもあります ）。 【運用ルール】 ・基本的に『 戻す操作 』はしない（履歴が大事！）。 ・共同のプロジェクトだとリポジトリがとんでもないことになる。 ・作業中の最新の「dev-」または「master」を壊してしまった時だけ。 ・通常は新たにブランチを切って、そこから作業を始めればいい。 ・「merge」して不要になったブランチは削除してもお k。
- 83. SourceTree を使ってみよう 11.【Tips】いろいろな『戻る』 1-1. 途中のcommitからブランチを切りたい！ ブランチを切りたいcommitを選択して、上部の「 Checkout」ボタンをクリック。 ・先ほど説明したうちの「 2. commitに対するcheckout」に該当。 ・ブランチがない場所で checkoutすると挙動が違います。
- 84. SourceTree を使ってみよう 11.【Tips】いろいろな『戻る』 1-2. アラートが出るので確認する 新たにブランチを作成するので「 OK」をクリックする。 「detached HEAD」ってなに？ → いずれのブランチにも属していない状態のこと。 ここで「HEAD」が示しているのはブランチの先頭ではなく 「コミット」だということ。
- 85. SourceTree を使ってみよう 11.【Tips】いろいろな『戻る』 1-3. detached HEAD この画像のような状態が「 detached HEAD」。 「HEAD」だけが独立していてブランチに属していない。 → この「detached HEAD」をブランチに含めるのが 「ブランチを切る」ということ。
- 86. SourceTree を使ってみよう 11.【Tips】いろいろな『戻る』 1-4. ブランチを切る 「Branch」ボタンをクリック → 「新規ブランチ」。 ・「現在のブランチ」が（ detached〜）になっていることに注意。 ・「detached〜」の状態のまま放置してはいけない 。 ・他の作業をしてしまうと「 detached〜」の状態だったcommit は削除されてしまう（どこのブランチにも属していないので）。
- 90. SourceTree を使ってみよう 11.【Tips】いろいろな『戻る』 1-8.アラートが出るので「 OK」をクリック。 cherry-pickをすると「temp01-」ブランチが「dev-」ブランチと並ぶ。 「dev-」を戻す操作は先ほどの手順と同じ。 ・先ほどの手順よりも一手間かかるので、落ち着いて。 気をつけるのは「git reset --hard」だけです。
- 92. SourceTree を使ってみよう 11.【Tips】いろいろな『戻る』 3-1.直前に「commit」したコメントを修正したい！ 上部の「Commit」ボタン → 右下の「コミットのオプション」をクリック。 ・プルダウンから「最新のコミットを修正」を選択する。 ・コメントが表示されるので編集して「 OK」。
- 93. SourceTree を使ってみよう 11.【Tips】いろいろな『戻る』 3-2.「commit」しちゃったけど元に戻したい！ 戻し方（git reset）には3種類ある ・soft reset（変更はステージングエリアに戻る） ・mixed reset(no option) （変更はワーキングツリーへ入る） ・hard reset（それまでの変更はすべて削除される）
- 94. SourceTree を使ってみよう 11.【Tips】いろいろな『戻る』 3-2.「commit」しちゃったけど元に戻したい！ ※要注意ポイント このhard resetは「履歴を削除する」コマンドなので、「 git pushする前のロー カルリポジトリでだけ 」行ってください。リモートリポジトリに pushしたあとに、pushす る以前のcommitに対して「git reset --hard 」すると全員の履歴に影響が及 んで大混乱が起きます。 リモートリポジトリで「元に戻したい」場合は、別の「 revert」コマンドを使います。こ の説明は次回に。