SlideShare a Scribd company logo
1 of 78
Download to read offline
Git講習会
古庄 道明
趣旨
 Gitについて、基本を学習していきます
 Git、およびWebサービスGitHubは、学校での学習にお
いても、社会に出てからのお仕事でも、使う頻度の高い
ツールになります
 一端は「授業の前提知識として」のGitの知識を学習して
いきましょう
バージョン管理システムとは?
 「変更履歴」がないと困る
 「誰が」「いつ」「どのように」修正したかの経緯が必要な時が
ある
 「コメントによる」変更履歴
 読みにくい(特に量が増えると後半、極端に可読性が落ちる)、
全体を通しての差分がわかりにくい
 例 →
// 20170325 古庄 修正start
//$hoge = hoge();
// 20170901 鵜沢 修正start
//$hoge = hoge(1);
$hoge = hoge(2);
// 20170901 鵜沢 修正end
// 20170325 古庄 修正end
 「ファイル/ディレクトリのバックアップによる」変更履歴
 ファイルが増える、差分が解らない、命名を間違えると「どれ
が最新かわからない(例:新しい.xls、より新しい.xls、最新.xls、
更新した最新.xls、最新より新しい.xls、新しい最新.xls)」
 「日付(+ナンバリング)」にすればマシだが、差分は相変わら
ずある程度不明
 「細かい巻き戻し」はできない事が多い(か、極端にファイルや
ディレクトリが増えるか)
 バージョン管理による変更履歴
 バージョン管理システムにもよるが基本「差分が見やすい」よ
うに出来ているので、わかりやすい
 細かい巻き戻しなども可能
 バージョン管理システムがないと「なぜ」困る?メリット
は?
 過去の状態や変更内容を確認
 変更前の状態を復元することが容易
 同一ファイルに対する変更が競合するなどの問題を防ぐ(防ぎ
方は色々)
 バージョン管理は「プログラムが多い」が、設定ファイル
や原稿など、様々なものもバージョン管理できるし、便利
でメリットがある
 「テキストファイル」が多く、バイナリファイル(画像、動画など)
を適切に差分管理できるものはあまりない
デグレード(degrade)の恐怖
 直接的には「grade(等級、階級、品等、グレード)」に「de-
(離れる、下がる等を意味する接頭語)」がついた言葉
 実例:特にバージョン管理システムを使っていない場合
(コメントによる変更履歴、は使ってみる)
 次Pageで、図解
大本の記述1
大本の記述2
大本の記述3
Aさ
ん
ソースコード管理サーバ:とあるファイル
大本の記述1
大本の記述2
大本の記述3
AさんPC:とあるファイル
//大本の記述1
大本の記述1-A
大本の記述2
大本の記述3
AさんPC:とあるファイル
大本の記述1
大本の記述2
大本の記述3
Bさ
ん
ソースコード管理サーバ:とあるファイル
大本の記述1
大本の記述2
大本の記述3
BさんPC:とあるファイル
大本の記述1
//大本の記述2
大本の記述2-B
大本の記述3
BさんPC:とあるファイル
大本の記述1
大本の記述2
大本の記述3
ソースコード管理サーバ:とあるファイル
Aさ
ん
//大本の記述1
大本の記述1-A
大本の記述2
大本の記述3
AさんPC:とあるファイル
ソースコード管理サーバ:とあるファイル
//大本の記述1
大本の記述1-A
大本の記述2
大本の記述3
ソースコード管理サーバ:とあるファイル
//大本の記述1
大本の記述1-A
大本の記述2
大本の記述3
Bさ
ん
大本の記述1
//大本の記述2
大本の記述2-B
大本の記述3
BさんPC:とあるファイル
ソースコード管理サーバ:とあるファイル
大本の記述1
//大本の記述2
大本の記述2-B
大本の記述3
 本当は望まれているはず、のソースコード
 「Aさんの修正」と「Bさんの修正」が双方とも適切に反映され
ている
 実際のサーバのソースコード
//大本の記述1
大本の記述1-A
//大本の記述2
大本の記述2-B
大本の記述3
大本の記述1
//大本の記述2
大本の記述2-B
大本の記述3
 質問
 「Aさんが修正した」修正→
 どこに消えた???
現在のサーバのソース↓
 これがデグレードです
 絶対厳禁!!
//大本の記述1
大本の記述1-A
ソースコード管理サーバ:とあるファイル
大本の記述1
//大本の記述2
大本の記述2-B
大本の記述3
 デグレードを防ぐためにはどうすればよいか?
 いくつか方法がありますが(後述)、そのために「バージョ
ン管理システム」と呼ばれるツールがあります
 今日、メインで学ぶGitは、バージョン管理システムの一
つ、になります
バージョン管理システムの簡単な歴史
 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でいくつかある難点を補うために作られた。会社等によっては
今でも現役。
 VSS(Visual SourceSafe / Microsoft Visual
SourceSafe)
 2005年作成。Microsoft Visual Studioによるアプリケーション
開発において使用することに主眼をおいたバージョン管理シ
ステム。
現在はサポートが終了しており、TFS(Team Foundation
Server)が後続になっている
 Mercurial
 2005年作成。Gitと一時期、覇を競っていた時期がある。現状
でもGitとMercurialは「互いの機能を取り入れつつ開発が進
んでいる」。ただし、Gitよりはマイナー。
 Git
 2005年作成。元々は「Linuxカーネルのソースコード管理に用
いるためにリーナス・トーバルズによって開発された」という逸
話をもつバージョン管理システム(ちなみに、Git開発以前は
BitKeeperというバージョン管理システムが使われていた)。
各ユーザのワーキングディレクトリに「全履歴を含んだリポジ
トリの完全な複製が作られる」ために「ネットワークにアクセス
できないなどの理由で中心リポジトリにアクセスできない環境
でも、履歴の調査や変更の記録といったほとんどの作業を行
うことができる」のが大きな特徴にしてメリット。
現在、バージョン管理ソフトとしてはおそらく「もっともよく使わ
れている」。
バージョン管理で使われる用語の簡単な説明
 注意
 いきなり「全部覚える」のは難しいと思うので、必要に応じて読み返
すようにしてください
 リポジトリ
 概ね「ファイル一式」。1プロジェクトあたり1リポジトリ、が比較的多
いが「複数プロジェクトで1リポジトリ」「1プロジェクトで複数リポジト
リ」も、ケースとしては存在する
 チェックアウト
 リポジトリからソースコードを取り出す事。バージョン管理システムに
よっては「一人がチェックアウトをしたら、ほかの人はチェックアウト
できないようにする」事で「1つのファイルを複数人で同時に修正す
る(デグレード)」を抑止する(後述の「ロック方式」参照)。
 今回メインで学習するGitにはこの概念は存在しない。
 ロック方式
 デグレを防ぐために「一人がチェックアウトしたら、ほかの人は
チェックアウトできない」ようにしてファイルを守る方法。
シンプルだが、状況等によっては「効率が悪い」事がある。
今回メインで学習するGitにはこの概念は存在しない。
 コピー・マージ方式
 同一ファイルでも「明らかに異なる行への修正」であれば、コ
ンピュータ側である程度把握して自動的に変更分を足していく
方法。
多人数でもある程度まで「同時に同一のファイルを触れる」の
で効率的だが、「コンピュータ側で自動で判断できない」状況
になれば最終的には人力に頼る事になるので、過信は禁物。
今回メインで学習するGitはこのパターン。
 バージョン番号、コミットID
 ある1回の「変更」に対して割り振られる番号。「バージョン番
号」の場合は比較的「1や1.1などの整数」から始まってインク
リメントされる事が多い。
「コミットID」の場合は「他とぶつからないユニークでランダム
(に見える)文字列」である事が多い。
今回メインで学習するGitはコミットIDが用いられている。
 タグ
 「この時点での変更(バージョン番号、コミットID)」に対して入
れる、しおりのようなもの。
あってもなくてもよいが、「あるとわかりやすい」ケースも多い
ので、折に触れてタグを打つ事、も多い。
GitHubについて
 Gitを使いますが、同時にGitHubも少し使っていきます
(授業で使う事が多いので)。
 Git
 バージョン管理システム
 GitHub
 「Gitを使う事ができて、リモートにHDDがある」Webサービス。
 Gitが持つ本来の機能以外に、いくつか独自の機能も持って
いる
 認証機能
 Issues、 Pull Requests、wiki など
 GitHubを使う場合のリポジトリ関連図(「こうでなければ
いけない」わけではないが、大抵、こういう感じになりや
すい)
Aさ
ん Bさ
ん
Aさん
PC
Bさん
PC
GitHub
色々な人
 GitHubを使う事によって
 多人数でも開発が出来る
 GitHubの場合「ほかの人にソースを見てもらう事ができる/提
供できる」
 なお、単純に「Gitのみ」で開発をしたり(それでも「多人数
で開発が出来る」というメリットは享受できる)、GitHubと
似たような機能を持つOSS(GitLabなど)もあるので、興
味があったら色々と調べてみましょう!!
OSSについて少し
 Open-source software / オープンソースソフトウェア
 ソフトウェアを、学習、変更、そして配布するための権利
を提供するというライセンスに基づいたソフトウェア
 端的には、Linuxがそうで、Gitがそうで、様々なOSSを
我々は使っている
 GitHubを使うと「ソフトウェアを配布する」ための環境が、
(ライセンスによっては)無料で手に入る
小休憩(30)
GitHubアカウントを作成する
 Gitを学習する一貫として、GitHubを使った実習をします
 また、授業で使う事なども増えてくると思います
 ですので、GitHubアカウントを作成しましょう
 画面は2017年9月のものです
 まず
https://github.com/
をブラウザで開きます。以降、手順を説明していきます
 「後でまとめてやる」と、途中でつまづきます。
集中して、しっかりと手順を一緒に追いかけてください
Git講習会
Git講習会
Git講習会
Git講習会
Git講習会
Git講習会
Git講習会
Git講習会
Git講習会
Git講習会
Git講習会
Git講習会
 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
 アンケートへの入力はお好みで。
 下に[skip this step]があるので、skipしてもよし。
 登録したメールアドレスを確認する。
 Gitからmailが来ているはずなので、メールの中にあるリ
ンク(Verify email address)をclickして、メールアドレスの
認証を終了させる。
 [Start a project]のボタンを押すとレポジトリの作成画面
になる。
 一端作成せず、ここまでで「GitHubのアカウント登録」の
完了。
小休憩(30)
Gitの「きわめて簡単な」使い方
 まずはGitを「とても簡単に」少しづつ使っていきます
 必要に応じて、パワーポイントを見直して復習をして、反復練
習をするように意識しましょう
準備
 レポジトリ用のディレクトリの準備
 コマンドプロンプト(cmd.exe)を立ち上げます
cd C:
mkdir git_work
cd git_work
(エクスプローラでやってもよいですが、後でコマンドプロンプト
は使います)
 もし「サブディレクトリまたはファイル git_work は既に存在し
ます。」というエラーが出た場合は
rmdir /S git_work
で削除してから上述を実行してください。
 エクスプローラでも同じディレクトリ(C:git_work)を開い
ておいてください
 エクスプローラ設定「隠しファイルの表示」「拡張子の表示」
「新しいレポジトリ」を作成、ファイルを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"
 git init
 「新しいレポジトリ」を作成します
 git add
 指定したファイルを「gitの管理対象」にします
 git config
 色々な設定をします。今回は「自分の名前」と「連絡先」を登録
しました(後で出てきます)
 git commit
 変更をgitに登録します
ファイルの中身を修正して、commitする
 [README.txtを修正] test2
 git commit -a -m 'second commit'
 git log
 git log --oneline
 git log --stat
 git log --graph --oneline
 git log
 gitの変更履歴を表示します。様々なオプションがあります
 前Pageで出てきたオプションは、全部「ハイフン2つ」です
「どこを変更したか」確認をしてからcommit
 [README.txtを修正] test3
 git diff
 git commit -a -m '3rd commit'
 git diff
 「最後にcommitした」後、どこに変更があったかを教えてくれ
ます
 実際にはそれ以外にも「色々な"2点"の比較」が出来ます
休憩
 今までは「AさんPC(local)」のみでgitを扱ってきました
Aさ
ん
Aさん
PC
 次は「GitHub(remote)とAさんPC(local)」でgitを扱って
いきましょう
Aさ
ん
Aさん
PC
GitHub
事前準備
 Windowsの場合で、かつ共有PCの場合「認証情報」が
残っている可能性があるので、確認して削除しましょう
(以下は、Windows 10の場合)
 コントロールパネル
→ユーザーアカウント
→資格情報の管理
→Windows 資格情報
 汎用認証情報に「git:https://github.com」があったら
 →削除する
レポジトリをGitHubに公開する
 先に、ブラウザから「必要な文字列」を探し出しておきま
しょう
Git講習会
 git remote add origin https://github.com/XX/test.git
 git push -u origin master
 ブラウザをリロードして「GitHubにソースコードが上がっ
ている事」の確認
 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は「一端、あまり気にしない」
ファイルを修正して、pushする
 [README.txtを修正] test4
 git commit -a -m "4th commit"
 ブラウザでGitHub(リモート)のレポジトリをみて「まだ反映されて
いない」事を確認する
 git push origin master
 ブラウザでGitHub(リモート)のレポジトリをみて「反映されてい
る」事を確認する
小休憩(45)
「別の人(Bさん)」として当該レポジトリを取得
 次は「BさんPC(local)」でgitを扱っていきましょう
Aさ
ん
Bさ
ん
Aさん
PC
Bさん
PC
GitHub
 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 "自分のメールアドレス(連
絡先)"
(Bさんとして)ファイルを修正
 [README.txtを修正] test5
 git commit -a -m “5th commit"
 git push origin master
 ブラウザでGitHub(リモート)のレポジトリをみて「反映されてい
る」事を確認する
「Bさんが修正したファイル」を、Aさん(元の
人)が受け取る
 cd C:git_work
 git log
 [README.txt]を確認、まだ「test3」のままである事を確
認する
 git pull
 git log
 [README.txt]を確認、先ほどの「Bさんの修正」が反映
されている事を確認する
 git pull
 "git pull [リモートリポジトリ] [リモートのブランチ名]"が、正
式
 git pull https://github.com/XX/test.git master
 git pull origin master
 git pull
一端まとめ
 Git等のバージョン管理ツールは、このようにして「変更
履歴」を管理します
 まずは「一人で」プロジェクトのソースコードをGit管理し
て、ゆっくりと慣らしていくとよいでしょう
 慣れてきたら複数人数で。その場合はできれば「ブラン
チを使った開発」をした方がよりよいので、このPPTで後
述してある内容を、自分なりに学習してみましょう
 最後に整理(ディレクトリの削除)
 C:git_workとC:git_work2を、ディレクトリごと削除しましょう
 アカウント情報を削除しましょう
付録:多人数で開発するときのコツ
 作業を細かく分けてこまめにcommit
 「1作業」毎にcommit
 なので、こまめなcommitのタイミングでpull
 rebaseは好みが分かれるので、環境やほかの人と相談
しつつ。大体「がっつり使う」か「まったく使わない」か、の
二極化。現場で確認しましょう
 branchを使う(できれば定期的にリモートにもbranchを
push)
 ぶつかったら諦めて手動merge。その時に「他人の修正
をつぶしたり壊したりしない」用に気を付けよう
付録: .gitignoreファイルについて
 「管理対象にしたくないファイル」を登録できるファイル
 例えば、以下のようなファイルを登録しておくと、便利な
事も多いでしょう
 .DS_Store等の「OSが作っている」ファイル
 *.oのような「コンパイル用オブジェクト」ファイル
 ログファイル
 「他から持ってきている」ライブラリ群
 「空ディレクトリ」の保持には、 .gitkeep でもよいのです
が「対象ディレクトリに.gitignoreを置く」方法もあります
 *
!.gitignore
付録:公開鍵について
 「毎回、IDとパスワードを入力」するのも手間なので。
GitHubでは「SSHの公開鍵をGitHubに登録し、認証さ
せる」事ができます
 「公開鍵と秘密鍵(公開鍵暗号方式)」を使う認証は、イン
フラの世界では(ある程度以上しっかりしたところであれ
ば)比較的一般的なので。
興味があったら、調べてみてください。
(学校のPC環境なら、使えるはずです)
付録:ブランチについて学ぶ(操作例)
 「一つの例」程度ですが、参考にしつつ、色々と自力で調
べたりしてみましょう
 # 先に「手元のレポジトリを最新にしておく」
 git pull
 # 現在見ているブランチがmaster(またはそれ以外の適
切なブランチ:git flow準拠ならdevelop)であることを一
度確認しておく
 git branch
 # 作業用ブランチを切って移動する
 # git branch ブランチ名
 # git checkout ブランチ名
 git checkout -b ブランチ名
 # 移動できたことを確認
 git branch
 # 修正等作業:作業完了してmergeできるところまでもっ
てこれた
 git commit -a
ブランチ:「リモートにアップしてpull
request等をする」流れの場合
 # リモートにアップする
 git push origin ブランチ名
 # レビュー等をしてもらう
 (mergeはおそらく「レビューをしてくれた人」がしてくれる)
 # merge後、リモートのブランチを削除する(ブランチ名の前
に:を付けると「削除」の意味)(削除してくれている、かも)
 git push origin :ブランチ名
 # localのブランチを削除する
 git branch -d ブランチ名
 git branch
 終了
ブランチ:「自分でmergeする」流れの場合
 # 「mergeしてOK」になったら
 # master(またはそれ以外の適切なブランチ:git flow準
拠ならdevelop)に移動する:コマンド例はmasterである
と仮定
 git checkout master
 git branch
 # レポジトリを最新の状態にしてから、mergeする
 git pull
 git merge ブランチ名
 # local masterの内容をリモートに反映する
 git push origin master
 # localのブランチを削除する
 git branch -d ブランチ名
 git branch
 終了
付録:様々な開発方法の一例/ GitHub flow
 使用するブランチ
 master: 「デプロイ可能」なブランチ
 topicブランチ: 作業用のブランチ群。命名は決まっていない
 下準備
 masterブランチを用意します
 新しい機能の開発や修正、緊急のバグフィックス対応
 masterから新しいブランチを作成する
 git checkout -b ブランチ名
 新しいブランチ上で追加や修正の作業を行う
 リモートのブランチに、定期的にpushをしておく事が推奨されている
 Pull Request、merge を行う
 Pull Request → masterへmerge
 masterに入ったものは、いつdeployされてもよい、とみなす
 定期的、或いは即時、といったdeployタイミングが多いと思います
付録:様々な開発方法の一例/ Git flow
 使用するブランチ
 master:リリースするためのブランチ。リリース後、タグを切る
 develop: 開発ブランチ。開発する時の元ネタ
 featuresブランチ群: 実際に作業をしているブランチ群
 hotfixesブランチ群:リリース後の「クリティカルなバグ」などに
対応するためのブランチ群
 releases ブランチ群: リリースの準備用のブランチ群
 下準備
 masterブランチを用意します
 masterブランチからdevelopブランチを作成します
 新しい機能の開発や修正
 developから新しいfeatureブランチを作成する
 "feature/ブランチ名"という命名が多いです
 feature上で追加や修正の作業を行う
 以下の作業をします
 local上で、featureブランチをdevelopにmergeします
 developブランチをremoteにpushします
 push後、localのfeatureブランチは削除します
 リリース(deploy)準備
 developブランチからreleaseブランチを作成
 "release/リリース名"という命名が多いです
 必要であれば、 releaseブランチに修正を加えます
 リリースの準備が完了したら、以下の作業を行います
 releaseブランチをmasterにmergeして、pushします
 masterブランチにリリース用のタグをつけます(こちらもpush)
 releaseブランチの内容をdevelopブランチにmergeして、pushしま
す
 releaseブランチを削除します
 masterブランチの内容をリリース(deploy)します
 緊急のバグフィックス対応
 masterブランチからhotfixeブランチを作成
 "hotfixe/ホットフィックス名"という命名が多いです
 修正が終わったら、以下の作業をします
 hotfixeブランチをmasterにmergeします
 masterブランチに「緊急対応した」旨のタグをつけます
 hotfixeブランチをdevelopにmergeします
 hotfixeブランチを削除します
 masterブランチの内容をリリース(deploy)します

More Related Content

What's hot

医療データ解析者へ向けた Git・GitHub 入門
医療データ解析者へ向けた Git・GitHub 入門医療データ解析者へ向けた Git・GitHub 入門
医療データ解析者へ向けた Git・GitHub 入門Yui Tomo
 
2018 07-18 git-hub講座
2018 07-18 git-hub講座2018 07-18 git-hub講座
2018 07-18 git-hub講座貴一 末田
 
コンセプトから理解するGitコマンド
コンセプトから理解するGitコマンドコンセプトから理解するGitコマンド
コンセプトから理解するGitコマンドktateish
 
デザイナのためのGit入門
デザイナのためのGit入門デザイナのためのGit入門
デザイナのためのGit入門dsuke Takaoka
 
Github時代のgitのはなし
Github時代のgitのはなしGithub時代のgitのはなし
Github時代のgitのはなしYoichi Toyota
 
新人Git/Github研修公開用スライド(その1)
新人Git/Github研修公開用スライド(その1)新人Git/Github研修公開用スライド(その1)
新人Git/Github研修公開用スライド(その1)pupupopo88
 
Archive: Git 入門(2014/1/10 社内勉強会)
Archive: Git 入門(2014/1/10 社内勉強会)Archive: Git 入門(2014/1/10 社内勉強会)
Archive: Git 入門(2014/1/10 社内勉強会)Yoko TAMADA
 
社内Git勉強会向け資料
社内Git勉強会向け資料社内Git勉強会向け資料
社内Git勉強会向け資料Hiroki Saiki
 
Git 入門
Git 入門Git 入門
Git 入門y-uti
 
色んな環境用の たった一つの.gitConfig
色んな環境用の たった一つの.gitConfig色んな環境用の たった一つの.gitConfig
色んな環境用の たった一つの.gitConfigwataru uchiyama
 
GitHub勉強会
GitHub勉強会GitHub勉強会
GitHub勉強会ArusuDev
 
はじめてのGit #gitkyoto
はじめてのGit #gitkyotoはじめてのGit #gitkyoto
はじめてのGit #gitkyotoHisateru Tanaka
 
最近のTUI(Terminal-based User Interface)事情
最近のTUI(Terminal-based User Interface)事情最近のTUI(Terminal-based User Interface)事情
最近のTUI(Terminal-based User Interface)事情Kota Kanbe
 
わしわし的おすすめ .gitconfig 設定 (と見せかけて実はみんなのおすすめ .gitconfig 設定を教えてもらう魂胆) #広島Git 勉強会
わしわし的おすすめ  .gitconfig 設定 (と見せかけて実はみんなのおすすめ .gitconfig 設定を教えてもらう魂胆) #広島Git 勉強会わしわし的おすすめ  .gitconfig 設定 (と見せかけて実はみんなのおすすめ .gitconfig 設定を教えてもらう魂胆) #広島Git 勉強会
わしわし的おすすめ .gitconfig 設定 (と見せかけて実はみんなのおすすめ .gitconfig 設定を教えてもらう魂胆) #広島Git 勉強会Yukinori KITADAI
 
Hubotを使ってbotをつくろう!
Hubotを使ってbotをつくろう!Hubotを使ってbotをつくろう!
Hubotを使ってbotをつくろう!Daisuke Kikuchi
 
hubotで快適BOT生活
hubotで快適BOT生活 hubotで快適BOT生活
hubotで快適BOT生活 Kazufumi Otani
 

What's hot (20)

医療データ解析者へ向けた Git・GitHub 入門
医療データ解析者へ向けた Git・GitHub 入門医療データ解析者へ向けた Git・GitHub 入門
医療データ解析者へ向けた Git・GitHub 入門
 
Git 勉強会
Git 勉強会Git 勉強会
Git 勉強会
 
2018 07-18 git-hub講座
2018 07-18 git-hub講座2018 07-18 git-hub講座
2018 07-18 git-hub講座
 
コンセプトから理解するGitコマンド
コンセプトから理解するGitコマンドコンセプトから理解するGitコマンド
コンセプトから理解するGitコマンド
 
デザイナのためのGit入門
デザイナのためのGit入門デザイナのためのGit入門
デザイナのためのGit入門
 
Github時代のgitのはなし
Github時代のgitのはなしGithub時代のgitのはなし
Github時代のgitのはなし
 
Git
GitGit
Git
 
新人Git/Github研修公開用スライド(その1)
新人Git/Github研修公開用スライド(その1)新人Git/Github研修公開用スライド(その1)
新人Git/Github研修公開用スライド(その1)
 
Archive: Git 入門(2014/1/10 社内勉強会)
Archive: Git 入門(2014/1/10 社内勉強会)Archive: Git 入門(2014/1/10 社内勉強会)
Archive: Git 入門(2014/1/10 社内勉強会)
 
社内Git勉強会向け資料
社内Git勉強会向け資料社内Git勉強会向け資料
社内Git勉強会向け資料
 
Git 入門
Git 入門Git 入門
Git 入門
 
色んな環境用の たった一つの.gitConfig
色んな環境用の たった一つの.gitConfig色んな環境用の たった一つの.gitConfig
色んな環境用の たった一つの.gitConfig
 
GitHub勉強会
GitHub勉強会GitHub勉強会
GitHub勉強会
 
はじめてのGit #gitkyoto
はじめてのGit #gitkyotoはじめてのGit #gitkyoto
はじめてのGit #gitkyoto
 
Git (実践入門編)
Git (実践入門編)Git (実践入門編)
Git (実践入門編)
 
最近のTUI(Terminal-based User Interface)事情
最近のTUI(Terminal-based User Interface)事情最近のTUI(Terminal-based User Interface)事情
最近のTUI(Terminal-based User Interface)事情
 
はじめてのGit
はじめてのGitはじめてのGit
はじめてのGit
 
わしわし的おすすめ .gitconfig 設定 (と見せかけて実はみんなのおすすめ .gitconfig 設定を教えてもらう魂胆) #広島Git 勉強会
わしわし的おすすめ  .gitconfig 設定 (と見せかけて実はみんなのおすすめ .gitconfig 設定を教えてもらう魂胆) #広島Git 勉強会わしわし的おすすめ  .gitconfig 設定 (と見せかけて実はみんなのおすすめ .gitconfig 設定を教えてもらう魂胆) #広島Git 勉強会
わしわし的おすすめ .gitconfig 設定 (と見せかけて実はみんなのおすすめ .gitconfig 設定を教えてもらう魂胆) #広島Git 勉強会
 
Hubotを使ってbotをつくろう!
Hubotを使ってbotをつくろう!Hubotを使ってbotをつくろう!
Hubotを使ってbotをつくろう!
 
hubotで快適BOT生活
hubotで快適BOT生活 hubotで快適BOT生活
hubotで快適BOT生活
 

Similar to Git講習会

バージョン管理
バージョン管理バージョン管理
バージョン管理Misa Kondo
 
20120324 git training
20120324 git training20120324 git training
20120324 git trainingTakeshi AKIMA
 
Python for Data Analysis第1回勉強会(+git入門)
Python for Data Analysis第1回勉強会(+git入門)Python for Data Analysis第1回勉強会(+git入門)
Python for Data Analysis第1回勉強会(+git入門)Makoto Kawano
 
Gitプレゼンテーション
GitプレゼンテーションGitプレゼンテーション
GitプレゼンテーションMasaru Ookawa
 
gitを使う準備をしよう - 初級編
gitを使う準備をしよう - 初級編gitを使う準備をしよう - 初級編
gitを使う準備をしよう - 初級編Sanae Yamashita
 
Gitを使ってみませんか
Gitを使ってみませんかGitを使ってみませんか
Gitを使ってみませんかAtsuhiro Takiguchi
 
ゆるふわっGit入門
ゆるふわっGit入門ゆるふわっGit入門
ゆるふわっGit入門Keisuke Oohata
 
WindowsでGitを使う際のベストプラクティス
WindowsでGitを使う際のベストプラクティスWindowsでGitを使う際のベストプラクティス
WindowsでGitを使う際のベストプラクティスRyo Sumasu
 
ノンプログラマのGit入門
ノンプログラマのGit入門ノンプログラマのGit入門
ノンプログラマのGit入門Muyuu Fujita
 
Version Control System Tutorial バージョン管理システムチュートリアル
Version Control System Tutorial バージョン管理システムチュートリアルVersion Control System Tutorial バージョン管理システムチュートリアル
Version Control System Tutorial バージョン管理システムチュートリアルComputational Materials Science Initiative
 
Git勉強会 2016 Gitで卒論を管理しよう回
Git勉強会 2016 Gitで卒論を管理しよう回Git勉強会 2016 Gitで卒論を管理しよう回
Git勉強会 2016 Gitで卒論を管理しよう回kinme modoki
 
Githubことはじめ
GithubことはじめGithubことはじめ
Githubことはじめtikitikipoo
 
GitHubの入門を読む前に読む入門書
GitHubの入門を読む前に読む入門書GitHubの入門を読む前に読む入門書
GitHubの入門を読む前に読む入門書相皓 卞
 

Similar to Git講習会 (20)

Gitの紹介
Gitの紹介Gitの紹介
Gitの紹介
 
バージョン管理
バージョン管理バージョン管理
バージョン管理
 
Git 20100313
Git 20100313Git 20100313
Git 20100313
 
20120324 git training
20120324 git training20120324 git training
20120324 git training
 
Python for Data Analysis第1回勉強会(+git入門)
Python for Data Analysis第1回勉強会(+git入門)Python for Data Analysis第1回勉強会(+git入門)
Python for Data Analysis第1回勉強会(+git入門)
 
Gitプレゼンテーション
GitプレゼンテーションGitプレゼンテーション
Gitプレゼンテーション
 
Github第4章
Github第4章Github第4章
Github第4章
 
gitを使う準備をしよう - 初級編
gitを使う準備をしよう - 初級編gitを使う準備をしよう - 初級編
gitを使う準備をしよう - 初級編
 
Gitを使ってみませんか
Gitを使ってみませんかGitを使ってみませんか
Gitを使ってみませんか
 
Git地図
Git地図Git地図
Git地図
 
Gitの使い方あれこれ
Gitの使い方あれこれGitの使い方あれこれ
Gitの使い方あれこれ
 
ゆるふわっGit入門
ゆるふわっGit入門ゆるふわっGit入門
ゆるふわっGit入門
 
WindowsでGitを使う際のベストプラクティス
WindowsでGitを使う際のベストプラクティスWindowsでGitを使う際のベストプラクティス
WindowsでGitを使う際のベストプラクティス
 
ノンプログラマのGit入門
ノンプログラマのGit入門ノンプログラマのGit入門
ノンプログラマのGit入門
 
Version Control System Tutorial バージョン管理システムチュートリアル
Version Control System Tutorial バージョン管理システムチュートリアルVersion Control System Tutorial バージョン管理システムチュートリアル
Version Control System Tutorial バージョン管理システムチュートリアル
 
Git勉強会 2016 Gitで卒論を管理しよう回
Git勉強会 2016 Gitで卒論を管理しよう回Git勉強会 2016 Gitで卒論を管理しよう回
Git勉強会 2016 Gitで卒論を管理しよう回
 
今さら聞けない人のためのGitLabの始め方 Ubuntu編
今さら聞けない人のためのGitLabの始め方 Ubuntu編今さら聞けない人のためのGitLabの始め方 Ubuntu編
今さら聞けない人のためのGitLabの始め方 Ubuntu編
 
Githubことはじめ
GithubことはじめGithubことはじめ
Githubことはじめ
 
GitHubの入門を読む前に読む入門書
GitHubの入門を読む前に読む入門書GitHubの入門を読む前に読む入門書
GitHubの入門を読む前に読む入門書
 
git addの解説
git addの解説git addの解説
git addの解説
 

More from galluda

Httpを振り返ってみる
Httpを振り返ってみるHttpを振り返ってみる
Httpを振り返ってみるgalluda
 
Httpの基礎とセキュリティ
Httpの基礎とセキュリティHttpの基礎とセキュリティ
Httpの基礎とセキュリティgalluda
 
Webデザイナーのためのphp wordpress
Webデザイナーのためのphp wordpressWebデザイナーのためのphp wordpress
Webデザイナーのためのphp wordpressgalluda
 
プログラミング(プログラムの書き方)基礎
プログラミング(プログラムの書き方)基礎プログラミング(プログラムの書き方)基礎
プログラミング(プログラムの書き方)基礎galluda
 
「実務系」エンジニアとはなにか? : 中級編
「実務系」エンジニアとはなにか? : 中級編「実務系」エンジニアとはなにか? : 中級編
「実務系」エンジニアとはなにか? : 中級編galluda
 
プログラム基礎その1
プログラム基礎その1プログラム基礎その1
プログラム基礎その1galluda
 
「実務系」エンジニアとは?
「実務系」エンジニアとは?「実務系」エンジニアとは?
「実務系」エンジニアとは?galluda
 
仕様七変化
仕様七変化仕様七変化
仕様七変化galluda
 
20090606 わんくま(がる)
20090606 わんくま(がる)20090606 わんくま(がる)
20090606 わんくま(がる)galluda
 

More from galluda (9)

Httpを振り返ってみる
Httpを振り返ってみるHttpを振り返ってみる
Httpを振り返ってみる
 
Httpの基礎とセキュリティ
Httpの基礎とセキュリティHttpの基礎とセキュリティ
Httpの基礎とセキュリティ
 
Webデザイナーのためのphp wordpress
Webデザイナーのためのphp wordpressWebデザイナーのためのphp wordpress
Webデザイナーのためのphp wordpress
 
プログラミング(プログラムの書き方)基礎
プログラミング(プログラムの書き方)基礎プログラミング(プログラムの書き方)基礎
プログラミング(プログラムの書き方)基礎
 
「実務系」エンジニアとはなにか? : 中級編
「実務系」エンジニアとはなにか? : 中級編「実務系」エンジニアとはなにか? : 中級編
「実務系」エンジニアとはなにか? : 中級編
 
プログラム基礎その1
プログラム基礎その1プログラム基礎その1
プログラム基礎その1
 
「実務系」エンジニアとは?
「実務系」エンジニアとは?「実務系」エンジニアとは?
「実務系」エンジニアとは?
 
仕様七変化
仕様七変化仕様七変化
仕様七変化
 
20090606 わんくま(がる)
20090606 わんくま(がる)20090606 わんくま(がる)
20090606 わんくま(がる)
 

Git講習会