Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
2018年新卒エンジニア研修 Git
Search
norinux
May 09, 2018
Technology
0
140
2018年新卒エンジニア研修 Git
norinux
May 09, 2018
Tweet
Share
More Decks by norinux
See All by norinux
NoCode開発で「オウ、ノーー!
norinux
0
900
インターネット基礎講座
norinux
0
110
スタートアップスタジオ流の開発プロセス
norinux
0
55
会社で書いてるコードも「OSSで公開しちゃえ!」ってしたいからそうした話 in OSS開発してる(したい)エンジニア交流会 /gx-oss-guideline-at-techmeetups
norinux
0
410
My Lightning Talk 「副業している(したい) エンジニア交流会 #2」
norinux
0
140
エンジニア流? こだわりのミーティング手法
norinux
1
130
スタートアップスタジオでの検証フェーズと技術
norinux
0
530
2018年新卒エンジニア研修 プログラミング研修【公開版】
norinux
0
63
2018年新卒エンジニア研修 セキュリティ
norinux
0
76
Other Decks in Technology
See All in Technology
EDRの検知の仕組みと検知回避について
chayakonanaika
11
4.8k
Windows の新しい管理者保護モード
murachiakira
0
200
PHPカンファレンス名古屋-テックリードの経験から学んだ設計の教訓
hayatokudou
2
540
Aurora PostgreSQLがCloudWatch Logsに 出力するログの課金を削減してみる #jawsdays2025
non97
1
190
ウォンテッドリーのデータパイプラインを支える ETL のための analytics, rds-exporter / analytics, rds-exporter for ETL to support Wantedly's data pipeline
unblee
0
120
AWSアカウントのセキュリティ自動化、どこまで進める? 最適な設計と実践ポイント
yuobayashi
7
540
データエンジニアリング領域におけるDuckDBのユースケース
chanyou0311
9
2.2k
偏光画像処理ライブラリを作った話
elerac
1
170
データベースの負荷を紐解く/untangle-the-database-load
emiki
2
500
システム・ML活用を広げるdbtのデータモデリング / Expanding System & ML Use with dbt Modeling
i125
1
320
依存パッケージの更新はコツコツが勝つコツ! / phpcon_nagoya2025
blue_goheimochi
3
210
Ruby on Railsで持続可能な開発を行うために取り組んでいること
am1157154
3
140
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
21
2.5k
Statistics for Hackers
jakevdp
797
220k
A designer walks into a library…
pauljervisheath
205
24k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Site-Speed That Sticks
csswizardry
4
400
Thoughts on Productivity
jonyablonski
69
4.5k
Unsuck your backbone
ammeep
669
57k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
Optimising Largest Contentful Paint
csswizardry
34
3.1k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
Transcript
Git 2018 新卒エンジニア研修 R&D 菊池ま
アジェンダ • 研修の目的(3min) • Gitとは(10min) • さあGitをはじめよう!(30min) • Gitの概念(10min) •
さらにGitを使ってみよう(45min) • 管理したくないファイル!?(10min) • 歴史の改ざん・・・?(20min) • GitHubを利用してみよう!(45min) • ブランチの豆知識(10min)
研修の目的
研修の目的 • Gitの利用の仕方を一通り体験し、開発時に利用 できるようにする • モブによる体験をすることにより、各人各所の知 識の差を理解し極力埋めることができる
Gitとは?
ソフトウェアのバージョン管理 バージョン管理システムの最も基本的な機能は、ファイルの作成日時、変更日時、変更 点などの履歴を保管することである。これにより、何度も変更を加えたファイルであって も、過去の状態や変更内容を確認したり、変更前の状態を復元することが容易になる。 更に、多くのバージョン管理システムでは、複数の人間がファイルの編集に関わる状況 を想定している。商業的なソフトウェア開発やオープンソースプロジェクトなどでは、複数 の人間が複数のファイルを各々編集するため、それぞれのファイルの最新の状態が分 からなくなったり、同一ファイルに対する変更が競合するなどの問題が生じやすいが、 バージョン管理システムは、このような問題を解決する仕組みを提供する。ただし、バー ジョン管理システムを個人のファイル管理に使用することも可能であるし、ソフトウェアの
ソースコードだけでなく、設定ファイルや原稿の管理などにも使うことも可能である。 出典:Wikipedia
集中型と分散型 分散型(Git)と集中型(SVN)と比較をしてみましょう。 分散型 集中型 両者の大きな違いはリポジトリを複数持てるかどうかです。Gitであれば開発の形態や規 模に合わせて複数のリポジトリを構成でき、システム構成を柔軟に作り上げることができ ます。 @IT:ガチで5分で分かる分散型バージョン管理システム Git (3/6)
http://www.atmarkit.co.jp/ait/articles/1307/05/news028_3.html より引用
Git Git(ギット)は、プログラムのソースコードなどの変更履歴を記録・追跡するための分散 型バージョン管理システムである。Linuxカーネルのソースコード管理に用いるために リーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクトで採用されて いる。Linuxカーネルのような巨大プロジェクトにも対応できるように、動作速度に重点が 置かれている。現在のメンテナンスは濱野純 (Junio C Hamano) が担当している。
Gitでは、各ユーザのワーキングディレクトリに、全履歴を含んだリポジトリの完全な複製 が作られる。したがって、ネットワークにアクセスできないなどの理由で中心リポジトリに アクセスできない環境でも、履歴の調査や変更の記録といったほとんどの作業を行うこ とができる。これが「分散型」と呼ばれる理由である。 Wikipedia:Git https://ja.wikipedia.org/wiki/Git より引用
さあGitをはじめよう!
基本操作 1. Gitで管理するディレクトリを作る 2. Gitで管理する 3. テキストファイルを作成(何か書き込む) 4. ファイルの変更をGitに伝える 5.
変更した内容を記録する 6. ファイルの内容を変更する 1 7. 変更したファイルの変更をGitに伝える 8. 変更した内容を記録する 9. ファイルの内容を変更する 2 10. 変更したファイルの変更をGitに伝える 11. 変更した内容を記録する 12. 変化があることを知る 13. --onelineオプションを使ってみる 14. ファイルを削除する 15. 最新の一つ前の状態に復元する 16. 最新の状態に復元する
みんなの環境を確認してみよう 1. 全員の環境を確認してみよう。 a. バージョン b. 名前とメールアドレス 2. 名前とメールアドレスが設定されていないかったら設定しよう
Gitの概念
大切な3つの領域 Gitには「作業フォルダ」「インデックス」「リポジトリ」の3つの領域がある。それぞれの領 域がどのように変化するのか正確に想像できると捗ります。 • 作業フォルダ ◦ OSが管理するファイルシステムのデータ保存場所で実際にターミナルなどから操作する。 • インデックス ◦
`git add` したときにGit形式のフォーマットで変更されたファイル情報を一時的に保存しておく場所。 • リポジトリ ◦ Gitが変更の歴史を蓄えている場所。コミットすると、Gitはそお時点のインデックスの状態を歴史の1 ページとしてリポジトリに追加する。 [導入メモ] GitHubを使うために、SVNユーザーがGitを調べた https://havelog.ayumusato.com/develop/others/e185-github-practice.html より引用
大切な1つの目印 Gitには「HEAD」という目印があり、HEADは最新の歴史の1ページ。最新のコミットIDを追 跡している。コミットIDとはコミットを管理するための40桁のコード番号。 1. HEADのコミットIDを取得する 2. ログと差異がないことを確認する
さらにGitを使ってみよう
さらに操作してみる 1. ファイル名を指定しないでコミットする 2. addとcommitを同時に行う 3. 新しいファイルを作成しコミットをする(-mオプションを利用しない) 4. コミットを中止する 5.
インデックスの余分な変更をなかったことにする 6. 2つめのファイルを削除する 7. ファイルを変更する 8. 変更したファイルを最新のコミットに戻す 9. ヘルプを利用してみる 10. 最新のコミットメッセージを編集する 11. ファイルを変更する 12. 同じような編集なのでコミットログを増やさないでコミットしたい 13. ファイル名を変更してコミットする 14. 元のファイル名に戻す
管理したくないファイル!?
特殊なファイル Gitの管理下におきたくないファイルは、管理から除外する必要があります。例えばMac でfinderでファイルを操作したときに生成される.DS_Storeなど。 除外する方法は3つ 1. project/.gitignore a. プロジェクトを共有するメンバー全員が無視するべきファイルを設定できる。メンバー全員に関わる ものはここに登録する。 2.
project/.git/info/excude a. 自分の環境のみに影響があるファイルはこちらに設定する 3. git config --global core.excludesfile $HOME/.gitexcludeと設定して $HOME/.gitexcludeに登録する a. ログイン中のユーザー全てで無視するファイルとして登録する
歴史の改ざん・・・!?
改ざんには注意して! 1. いくつか前のコミットを打ち消す 2. いくつか前のコミットを削除したい 過去の歴史の変更が許されるかどうかは、基準が必要ですよね。基準がなく各自が勝 手に変更してしまうと歴史がめちゃくちゃになってしまいます。 次のように覚えておき、あとはチームで相談しましょう • 他人が作ったコミットを含む歴史の変更はNG
• いったん公開したコミットを含む歴史の変更はNG • つまり、未公開の自分が作ったコミットしかない歴史の変更はOK • 所謂、git push前!
GitHubを利用してみよう!
GitHubとは? GitHubは、その名の通り、「Git」の「ハブ:拠点・中心・集まり」です。 GitHubは、Gitの仕組みを利用して、世界中の人々が自分の作品(プログラムコードやデ ザインデータなど)を保存、公開することができるようにしたウェブサービスの名称です。 GitHubはGitHub社という会社によって運営されており、個人・企業問わず無料で利用す ることができます。 GitHubに作成されたリポジトリ(保存庫のようなもの)は、基本的にすべて公開されます が、有料サービスを利用すると、指定したユーザーからしかアクセスができないプライ ベートなレポジトリを作ったりすることができます。
GitHubとの連携と基本的な操作 1. GitHubでレポジトリを作成 2. ローカルのレポジトリとリモートのレポジトリを連携させる 3. GitHubからコードを取得する 4. 他のメンバーがファイルを変更する 5.
他のメンバーの変更を取り込む 6. 競合状態を作り出し、その解消をする
歴史の分岐 Gitでは歴史の流れをいくつも分岐できます。その歴史の流れをブランチと呼びます。特 に指定しないかぎり、最初のコミットはmasterブランチにコミットされます。 1. 現在のブランチを確認してみる 2. 新しいブランチを作成する 3. 作成したブランチに移動する 4.
ファイルを更新し、コミットする 5. 歴史を確認する 6. masterブランチに戻る 7. 歴史を確認する 8. 他のメンバーがファイルを変更する 9. ファイルの変更と取り込む
歴史の合流 1. 先ほど作成したブランチに移動する 2. masterブランチで取り込んだ変更を現在のブランチに取り込む 3. 現在のブランチでファイルをさらに変更してコミットする 4. 新しいブランチの変更をmasterブランチに合流させる
プルリクエスト 1. あらたにブランチを作成してファイルを更新する 2. ブランチをリモートブランチにpushする 3. プルリクエストを作成する 4. プルリクエストをapprouvedしマージする
ブランチの豆知識
ブランチの豆知識 ブランチとは、開発の本流から分岐し、本流の開発を邪魔することなく作業を続ける機 能のことです。このブランチの管理形式(ルール)のことをブランチモデルと呼び代表的 なモデルに下記の2つがあります。このほかにもチーム内で形成されたモデルなどがあ りますが、ルールに縛られて開発の足かせになっては本末転倒ですので、しっかり検討 し運用していく必要があります。 git-flow GitHub Flow
git-flow Git flowでは、それぞれ役割が振られているmaster, release, develop, feature, hot-fixの 5つのブランチを使い分けて、開発を進めていきます。 • feature
◦ 開発をおこなうためのブランチで、個々の機能 の実装やバグの解決をおこなう • develop ◦ 開発をおこなうためのブランチ • release ◦ リリース前に準備、微調整をおこなうブランチ • master ◦ リリースしたデータを置いておくブランチ • hot-fix ◦ リリースされているデータに、緊急の修正対応 をするためのブランチ LIG:Gitを最大限に活用できる 「Git flow」で、効率よく開発を進めよう! https://liginc.co.jp/248864 より引用
GitHub Flow • masterブランチのものは何であれデプロイ可能である • 新しい何かに取り組む際は、説明的な名前のブランチをmasterから作成する(例: new-oauth2-scopes) • 作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも定 期的に作業内容をpushする
• フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、 プル リクエスト を作成する • 他の誰かがレビューをして機能にOKを出してくれたら、あなたはコードをmasterへ マージすることができる • マージをしてmasterへpushしたら、直ちにデプロイをする