Submit Search
Upload
Git講習会
•
1 like
•
460 views
G
galluda
Follow
専門学校で使う「Git講習会」用の資料です。
Read less
Read more
Engineering
Report
Share
Report
Share
1 of 78
Download Now
Download to read offline
Recommended
GitHub勉強会~当日資料~
GitHub勉強会~当日資料~
Shintaro Mizuno
GitHub勉強会~事前準備~
GitHub勉強会~事前準備~
Shintaro Mizuno
こわくない Git
こわくない Git
Kota Saito
新人Git/Github研修公開用スライド(その2)
新人Git/Github研修公開用スライド(その2)
pupupopo88
15分でわかるGit入門
15分でわかるGit入門
to_ueda
Git & GitHub を使いこなしてハッピーになろう! - WordBench 名古屋 & concrete5 名古屋 合同勉強会
Git & GitHub を使いこなしてハッピーになろう! - WordBench 名古屋 & concrete5 名古屋 合同勉強会
Katz Ueno
@s_ssk13さん向けGitHub入門
@s_ssk13さん向けGitHub入門
Takashi Imagire
Gitとちょっと仲良くなるために覚えたことまとめ
Gitとちょっと仲良くなるために覚えたことまとめ
Natsumi Kashiwa
More Related Content
What's hot
医療データ解析者へ向けた Git・GitHub 入門
医療データ解析者へ向けた Git・GitHub 入門
Yui Tomo
Git 勉強会
Git 勉強会
kinme modoki
2018 07-18 git-hub講座
2018 07-18 git-hub講座
貴一 末田
コンセプトから理解するGitコマンド
コンセプトから理解するGitコマンド
ktateish
デザイナのためのGit入門
デザイナのためのGit入門
dsuke Takaoka
Github時代のgitのはなし
Github時代のgitのはなし
Yoichi Toyota
Git
Git
Shuhei Iitsuka
新人Git/Github研修公開用スライド(その1)
新人Git/Github研修公開用スライド(その1)
pupupopo88
Archive: Git 入門(2014/1/10 社内勉強会)
Archive: Git 入門(2014/1/10 社内勉強会)
Yoko TAMADA
社内Git勉強会向け資料
社内Git勉強会向け資料
Hiroki Saiki
Git 入門
Git 入門
y-uti
色んな環境用の たった一つの.gitConfig
色んな環境用の たった一つの.gitConfig
wataru uchiyama
GitHub勉強会
GitHub勉強会
ArusuDev
はじめてのGit #gitkyoto
はじめてのGit #gitkyoto
Hisateru Tanaka
Git (実践入門編)
Git (実践入門編)
Naomichi Yamakita
最近のTUI(Terminal-based User Interface)事情
最近のTUI(Terminal-based User Interface)事情
Kota Kanbe
はじめてのGit
はじめてのGit
Seiichiro Mishiba
わしわし的おすすめ .gitconfig 設定 (と見せかけて実はみんなのおすすめ .gitconfig 設定を教えてもらう魂胆) #広島Git 勉強会
わしわし的おすすめ .gitconfig 設定 (と見せかけて実はみんなのおすすめ .gitconfig 設定を教えてもらう魂胆) #広島Git 勉強会
Yukinori KITADAI
Hubotを使ってbotをつくろう!
Hubotを使ってbotをつくろう!
Daisuke Kikuchi
hubotで快適BOT生活
hubotで快適BOT生活
Kazufumi Otani
What's hot
(20)
医療データ解析者へ向けた Git・GitHub 入門
医療データ解析者へ向けた Git・GitHub 入門
Git 勉強会
Git 勉強会
2018 07-18 git-hub講座
2018 07-18 git-hub講座
コンセプトから理解するGitコマンド
コンセプトから理解するGitコマンド
デザイナのためのGit入門
デザイナのためのGit入門
Github時代のgitのはなし
Github時代のgitのはなし
Git
Git
新人Git/Github研修公開用スライド(その1)
新人Git/Github研修公開用スライド(その1)
Archive: Git 入門(2014/1/10 社内勉強会)
Archive: Git 入門(2014/1/10 社内勉強会)
社内Git勉強会向け資料
社内Git勉強会向け資料
Git 入門
Git 入門
色んな環境用の たった一つの.gitConfig
色んな環境用の たった一つの.gitConfig
GitHub勉強会
GitHub勉強会
はじめてのGit #gitkyoto
はじめてのGit #gitkyoto
Git (実践入門編)
Git (実践入門編)
最近のTUI(Terminal-based User Interface)事情
最近のTUI(Terminal-based User Interface)事情
はじめてのGit
はじめてのGit
わしわし的おすすめ .gitconfig 設定 (と見せかけて実はみんなのおすすめ .gitconfig 設定を教えてもらう魂胆) #広島Git 勉強会
わしわし的おすすめ .gitconfig 設定 (と見せかけて実はみんなのおすすめ .gitconfig 設定を教えてもらう魂胆) #広島Git 勉強会
Hubotを使ってbotをつくろう!
Hubotを使ってbotをつくろう!
hubotで快適BOT生活
hubotで快適BOT生活
Similar to Git講習会
Gitの紹介
Gitの紹介
Shoot Morii
バージョン管理
バージョン管理
Misa Kondo
Git 20100313
Git 20100313
Taku AMANO
20120324 git training
20120324 git training
Takeshi AKIMA
Python for Data Analysis第1回勉強会(+git入門)
Python for Data Analysis第1回勉強会(+git入門)
Makoto Kawano
Gitプレゼンテーション
Gitプレゼンテーション
Masaru Ookawa
Github第4章
Github第4章
Yuto Suzuki
gitを使う準備をしよう - 初級編
gitを使う準備をしよう - 初級編
Sanae Yamashita
Gitを使ってみませんか
Gitを使ってみませんか
Atsuhiro Takiguchi
Git地図
Git地図
yoshiaki iwanaga
Gitの使い方あれこれ
Gitの使い方あれこれ
よしだ あつし
ゆるふわっGit入門
ゆるふわっGit入門
Keisuke Oohata
WindowsでGitを使う際のベストプラクティス
WindowsでGitを使う際のベストプラクティス
Ryo Sumasu
ノンプログラマのGit入門
ノンプログラマのGit入門
Muyuu Fujita
Version Control System Tutorial バージョン管理システムチュートリアル
Version Control System Tutorial バージョン管理システムチュートリアル
Computational Materials Science Initiative
Git勉強会 2016 Gitで卒論を管理しよう回
Git勉強会 2016 Gitで卒論を管理しよう回
kinme modoki
今さら聞けない人のためのGitLabの始め方 Ubuntu編
今さら聞けない人のためのGitLabの始め方 Ubuntu編
VirtualTech Japan Inc./Begi.net Inc.
Githubことはじめ
Githubことはじめ
tikitikipoo
GitHubの入門を読む前に読む入門書
GitHubの入門を読む前に読む入門書
相皓 卞
git addの解説
git addの解説
Kamimura Taichi
Similar to Git講習会
(20)
Gitの紹介
Gitの紹介
バージョン管理
バージョン管理
Git 20100313
Git 20100313
20120324 git training
20120324 git training
Python for Data Analysis第1回勉強会(+git入門)
Python for Data Analysis第1回勉強会(+git入門)
Gitプレゼンテーション
Gitプレゼンテーション
Github第4章
Github第4章
gitを使う準備をしよう - 初級編
gitを使う準備をしよう - 初級編
Gitを使ってみませんか
Gitを使ってみませんか
Git地図
Git地図
Gitの使い方あれこれ
Gitの使い方あれこれ
ゆるふわっGit入門
ゆるふわっGit入門
WindowsでGitを使う際のベストプラクティス
WindowsでGitを使う際のベストプラクティス
ノンプログラマのGit入門
ノンプログラマのGit入門
Version Control System Tutorial バージョン管理システムチュートリアル
Version Control System Tutorial バージョン管理システムチュートリアル
Git勉強会 2016 Gitで卒論を管理しよう回
Git勉強会 2016 Gitで卒論を管理しよう回
今さら聞けない人のためのGitLabの始め方 Ubuntu編
今さら聞けない人のためのGitLabの始め方 Ubuntu編
Githubことはじめ
Githubことはじめ
GitHubの入門を読む前に読む入門書
GitHubの入門を読む前に読む入門書
git addの解説
git addの解説
More from galluda
Httpを振り返ってみる
Httpを振り返ってみる
galluda
Httpの基礎とセキュリティ
Httpの基礎とセキュリティ
galluda
Webデザイナーのためのphp wordpress
Webデザイナーのためのphp wordpress
galluda
プログラミング(プログラムの書き方)基礎
プログラミング(プログラムの書き方)基礎
galluda
「実務系」エンジニアとはなにか? : 中級編
「実務系」エンジニアとはなにか? : 中級編
galluda
プログラム基礎その1
プログラム基礎その1
galluda
「実務系」エンジニアとは?
「実務系」エンジニアとは?
galluda
仕様七変化
仕様七変化
galluda
20090606 わんくま(がる)
20090606 わんくま(がる)
galluda
More from galluda
(9)
Httpを振り返ってみる
Httpを振り返ってみる
Httpの基礎とセキュリティ
Httpの基礎とセキュリティ
Webデザイナーのためのphp wordpress
Webデザイナーのためのphp wordpress
プログラミング(プログラムの書き方)基礎
プログラミング(プログラムの書き方)基礎
「実務系」エンジニアとはなにか? : 中級編
「実務系」エンジニアとはなにか? : 中級編
プログラム基礎その1
プログラム基礎その1
「実務系」エンジニアとは?
「実務系」エンジニアとは?
仕様七変化
仕様七変化
20090606 わんくま(がる)
20090606 わんくま(がる)
Git講習会
1.
Git講習会 古庄 道明
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.
デグレード(degrade)の恐怖 直接的には「grade(等級、階級、品等、グレード)」に「de- (離れる、下がる等を意味する接頭語)」がついた言葉 実例:特にバージョン管理システムを使っていない場合 (コメントによる変更履歴、は使ってみる)
次Pageで、図解
7.
大本の記述1 大本の記述2 大本の記述3 Aさ ん ソースコード管理サーバ:とあるファイル 大本の記述1 大本の記述2 大本の記述3 AさんPC:とあるファイル //大本の記述1 大本の記述1-A 大本の記述2 大本の記述3 AさんPC:とあるファイル
8.
大本の記述1 大本の記述2 大本の記述3 Bさ ん ソースコード管理サーバ:とあるファイル 大本の記述1 大本の記述2 大本の記述3 BさんPC:とあるファイル 大本の記述1 //大本の記述2 大本の記述2-B 大本の記述3 BさんPC:とあるファイル
9.
大本の記述1 大本の記述2 大本の記述3 ソースコード管理サーバ:とあるファイル Aさ ん //大本の記述1 大本の記述1-A 大本の記述2 大本の記述3 AさんPC:とあるファイル ソースコード管理サーバ:とあるファイル //大本の記述1 大本の記述1-A 大本の記述2 大本の記述3
10.
ソースコード管理サーバ:とあるファイル //大本の記述1 大本の記述1-A 大本の記述2 大本の記述3 Bさ ん 大本の記述1 //大本の記述2 大本の記述2-B 大本の記述3 BさんPC:とあるファイル ソースコード管理サーバ:とあるファイル 大本の記述1 //大本の記述2 大本の記述2-B 大本の記述3
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 Code
Control 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.
Git 2005年作成。元々は「Linuxカーネルのソースコード管理に用 いるためにリーナス・トーバルズによって開発された」という逸 話をもつバージョン管理システム(ちなみに、Git開発以前は BitKeeperというバージョン管理システムが使われていた)。 各ユーザのワーキングディレクトリに「全履歴を含んだリポジ トリの完全な複製が作られる」ために「ネットワークにアクセス できないなどの理由で中心リポジトリにアクセスできない環境 でも、履歴の調査や変更の記録といったほとんどの作業を行 うことができる」のが大きな特徴にしてメリット。 現在、バージョン管理ソフトとしてはおそらく「もっともよく使わ れている」。
17.
バージョン管理で使われる用語の簡単な説明 注意 いきなり「全部覚える」のは難しいと思うので、必要に応じて読み返 すようにしてください
リポジトリ 概ね「ファイル一式」。1プロジェクトあたり1リポジトリ、が比較的多 いが「複数プロジェクトで1リポジトリ」「1プロジェクトで複数リポジト リ」も、ケースとしては存在する チェックアウト リポジトリからソースコードを取り出す事。バージョン管理システムに よっては「一人がチェックアウトをしたら、ほかの人はチェックアウト できないようにする」事で「1つのファイルを複数人で同時に修正す る(デグレード)」を抑止する(後述の「ロック方式」参照)。 今回メインで学習するGitにはこの概念は存在しない。
18.
ロック方式 デグレを防ぐために「一人がチェックアウトしたら、ほかの人は チェックアウトできない」ようにしてファイルを守る方法。 シンプルだが、状況等によっては「効率が悪い」事がある。 今回メインで学習するGitにはこの概念は存在しない。
コピー・マージ方式 同一ファイルでも「明らかに異なる行への修正」であれば、コ ンピュータ側である程度把握して自動的に変更分を足していく 方法。 多人数でもある程度まで「同時に同一のファイルを触れる」の で効率的だが、「コンピュータ側で自動で判断できない」状況 になれば最終的には人力に頼る事になるので、過信は禁物。 今回メインで学習するGitはこのパターン。
19.
バージョン番号、コミットID ある1回の「変更」に対して割り振られる番号。「バージョン番 号」の場合は比較的「1や1.1などの整数」から始まってインク リメントされる事が多い。 「コミットID」の場合は「他とぶつからないユニークでランダム (に見える)文字列」である事が多い。 今回メインで学習するGitはコミットIDが用いられている。
タグ 「この時点での変更(バージョン番号、コミットID)」に対して入 れる、しおりのようなもの。 あってもなくてもよいが、「あるとわかりやすい」ケースも多い ので、折に触れてタグを打つ事、も多い。
20.
GitHubについて Gitを使いますが、同時にGitHubも少し使っていきます (授業で使う事が多いので)。 Git
バージョン管理システム GitHub 「Gitを使う事ができて、リモートにHDDがある」Webサービス。 Gitが持つ本来の機能以外に、いくつか独自の機能も持って いる 認証機能 Issues、 Pull Requests、wiki など
21.
GitHubを使う場合のリポジトリ関連図(「こうでなければ いけない」わけではないが、大抵、こういう感じになりや すい) Aさ ん Bさ ん Aさん PC Bさん PC GitHub 色々な人
22.
GitHubを使う事によって 多人数でも開発が出来る
GitHubの場合「ほかの人にソースを見てもらう事ができる/提 供できる」 なお、単純に「Gitのみ」で開発をしたり(それでも「多人数 で開発が出来る」というメリットは享受できる)、GitHubと 似たような機能を持つOSS(GitLabなど)もあるので、興 味があったら色々と調べてみましょう!!
23.
OSSについて少し Open-source software
/ オープンソースソフトウェア ソフトウェアを、学習、変更、そして配布するための権利 を提供するというライセンスに基づいたソフトウェア 端的には、Linuxがそうで、Gitがそうで、様々なOSSを 我々は使っている GitHubを使うと「ソフトウェアを配布する」ための環境が、 (ライセンスによっては)無料で手に入る
24.
小休憩(30)
25.
GitHubアカウントを作成する Gitを学習する一貫として、GitHubを使った実習をします また、授業で使う事なども増えてくると思います
ですので、GitHubアカウントを作成しましょう 画面は2017年9月のものです まず https://github.com/ をブラウザで開きます。以降、手順を説明していきます 「後でまとめてやる」と、途中でつまづきます。 集中して、しっかりと手順を一緒に追いかけてください
38.
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
39.
アンケートへの入力はお好みで。 下に[skip
this step]があるので、skipしてもよし。 登録したメールアドレスを確認する。 Gitからmailが来ているはずなので、メールの中にあるリ ンク(Verify email address)をclickして、メールアドレスの 認証を終了させる。 [Start a project]のボタンを押すとレポジトリの作成画面 になる。 一端作成せず、ここまでで「GitHubのアカウント登録」の 完了。
40.
小休憩(30)
41.
Gitの「きわめて簡単な」使い方 まずはGitを「とても簡単に」少しづつ使っていきます 必要に応じて、パワーポイントを見直して復習をして、反復練 習をするように意識しましょう
42.
準備 レポジトリ用のディレクトリの準備 コマンドプロンプト(cmd.exe)を立ち上げます cd
C: mkdir git_work cd git_work (エクスプローラでやってもよいですが、後でコマンドプロンプト は使います) もし「サブディレクトリまたはファイル git_work は既に存在し ます。」というエラーが出た場合は rmdir /S git_work で削除してから上述を実行してください。 エクスプローラでも同じディレクトリ(C:git_work)を開い ておいてください エクスプローラ設定「隠しファイルの表示」「拡張子の表示」
43.
「新しいレポジトリ」を作成、ファイルを1つ コマンドプロンプトで以下を打ち込みます 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"
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で出てきたオプションは、全部「ハイフン2つ」です
47.
「どこを変更したか」確認をしてからcommit [README.txtを修正] test3
git diff git commit -a -m '3rd commit'
48.
git diff
「最後にcommitした」後、どこに変更があったかを教えてくれ ます 実際にはそれ以外にも「色々な"2点"の比較」が出来ます
49.
休憩
50.
今までは「AさんPC(local)」のみでgitを扱ってきました Aさ ん Aさん PC
51.
次は「GitHub(remote)とAさんPC(local)」でgitを扱って いきましょう Aさ ん Aさん PC GitHub
52.
事前準備 Windowsの場合で、かつ共有PCの場合「認証情報」が 残っている可能性があるので、確認して削除しましょう (以下は、Windows 10の場合)
コントロールパネル →ユーザーアカウント →資格情報の管理 →Windows 資格情報 汎用認証情報に「git:https://github.com」があったら →削除する
53.
レポジトリをGitHubに公開する 先に、ブラウザから「必要な文字列」を探し出しておきま しょう
55.
git remote
add origin https://github.com/XX/test.git git push -u origin master ブラウザをリロードして「GitHubにソースコードが上がっ ている事」の確認
56.
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は「一端、あまり気にしない」
57.
ファイルを修正して、pushする [README.txtを修正] test4
git commit -a -m "4th commit" ブラウザでGitHub(リモート)のレポジトリをみて「まだ反映されて いない」事を確認する git push origin master ブラウザでGitHub(リモート)のレポジトリをみて「反映されてい る」事を確認する
58.
小休憩(45)
59.
「別の人(Bさん)」として当該レポジトリを取得 次は「BさんPC(local)」でgitを扱っていきましょう Aさ ん Bさ ん Aさん PC Bさん PC GitHub
60.
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 "自分のメールアドレス(連 絡先)"
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 「1作業」毎にcommit
なので、こまめなcommitのタイミングでpull rebaseは好みが分かれるので、環境やほかの人と相談 しつつ。大体「がっつり使う」か「まったく使わない」か、の 二極化。現場で確認しましょう branchを使う(できれば定期的にリモートにもbranchを push) ぶつかったら諦めて手動merge。その時に「他人の修正 をつぶしたり壊したりしない」用に気を付けよう
66.
付録: .gitignoreファイルについて 「管理対象にしたくないファイル」を登録できるファイル
例えば、以下のようなファイルを登録しておくと、便利な 事も多いでしょう .DS_Store等の「OSが作っている」ファイル *.oのような「コンパイル用オブジェクト」ファイル ログファイル 「他から持ってきている」ライブラリ群 「空ディレクトリ」の保持には、 .gitkeep でもよいのです が「対象ディレクトリに.gitignoreを置く」方法もあります * !.gitignore
67.
付録:公開鍵について 「毎回、IDとパスワードを入力」するのも手間なので。 GitHubでは「SSHの公開鍵をGitHubに登録し、認証さ せる」事ができます 「公開鍵と秘密鍵(公開鍵暗号方式)」を使う認証は、イン フラの世界では(ある程度以上しっかりしたところであれ ば)比較的一般的なので。 興味があったら、調べてみてください。 (学校のPC環境なら、使えるはずです)
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.
# local
masterの内容をリモートに反映する 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)します
Download Now