Soumettre la recherche
Mettre en ligne
新人Git/Github研修公開用スライド(その1)
•
64 j'aime
•
19,325 vues
pupupopo88
Suivre
新人「GitとGithub」研修のスライドを公開用に調整したもの
Lire moins
Lire la suite
Technologie
Signaler
Partager
Signaler
Partager
1 sur 330
Télécharger maintenant
Télécharger pour lire hors ligne
Recommandé
新人「GitとGithub」研修のスライドを公開用に調整したもの
新人Git/Github研修公開用スライド(その2)
新人Git/Github研修公開用スライド(その2)
pupupopo88
SlideShare上の本資料は現在メンテされていません。 ↓↓↓SpeakerDeck版をご覧ください!(時々アプデしてます)↓↓↓ https://speakerdeck.com/ihcomega56/githazimefalse-bu
Gitはじめの一歩
Gitはじめの一歩
Ayana Yokota
1/29 minami.rb でLTした資料
15分でわかるGit入門
15分でわかるGit入門
to_ueda
第10回姫路IT勉強会
一人でもはじめるGitでバージョン管理
一人でもはじめるGitでバージョン管理
Takafumi Yoshida
社内勉強会用資料です。Gitの使い方の前に。
デザイナのためのGit入門
デザイナのためのGit入門
dsuke Takaoka
※ 本スライドの内容を解説した、電子書籍を販売中です。 <a>http://p.booklog.jp/book/86773</a> 「Git(ギット)」や「バージョン管理」という言葉は聞いたことはあっても、なんだか難しそうなイメージを持っているかも知れません。 特に、プログラマーやエンジニアのツールであって、デザイナー・マークアップエンジニア・ディレクターの方は「自分には無縁」と思っているのではないでしょうか。 しかし、Gitはプロジェクトに関わるすべての方が使えると、コミュニケーションツールとしての役割も果たし、非常にスムーズにプロジェクトを進行させることができます。 このイベントでは「ノンプログラマの方」を対象に、Gitのよく使う部分だけをピックアップしてわかりやすく紹介、今日から使えるテクニックや便利なポイントを紹介していきます。
ノンプログラマでも今日から使える「Git」でバージョン管理
ノンプログラマでも今日から使える「Git」でバージョン管理
H2O Space. Co., Ltd.
Gitってなに? プログラマではないけれど、Git導入するメリットは? いわゆるデザイナーやコーダー向けの、「Gitとは?」「Gitの構造とは?」…のやさしい説明スライドです。 デザイナーやコーダーがGitを使う際には、とっつきにくい「コマンド」をまったく覚えなくてもOK! 便利なGUIツールが沢山出ています。 (私はWindowsなのでGit Extensions派) Gitの言葉や構造を理解するための、社内勉強会で使った資料です。
はじめてのGit forデザイナー&コーダー
はじめてのGit forデザイナー&コーダー
Saeko Yamamoto
↓のv1.1.0版の方が、より見やすく改善したものになってます! http://www.slideshare.net/matsukaz/git-28304397 社内で開催したGit勉強会の資料。 SVNとの比較や、Gitの内部構造と各コマンドの関係、ブランチやリモートリポジトリとの関係を分かりやすく説明したつもり。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・!15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev
いつやるの?Git入門
いつやるの?Git入門
Masakazu Matsushita
Recommandé
新人「GitとGithub」研修のスライドを公開用に調整したもの
新人Git/Github研修公開用スライド(その2)
新人Git/Github研修公開用スライド(その2)
pupupopo88
SlideShare上の本資料は現在メンテされていません。 ↓↓↓SpeakerDeck版をご覧ください!(時々アプデしてます)↓↓↓ https://speakerdeck.com/ihcomega56/githazimefalse-bu
Gitはじめの一歩
Gitはじめの一歩
Ayana Yokota
1/29 minami.rb でLTした資料
15分でわかるGit入門
15分でわかるGit入門
to_ueda
第10回姫路IT勉強会
一人でもはじめるGitでバージョン管理
一人でもはじめるGitでバージョン管理
Takafumi Yoshida
社内勉強会用資料です。Gitの使い方の前に。
デザイナのためのGit入門
デザイナのためのGit入門
dsuke Takaoka
※ 本スライドの内容を解説した、電子書籍を販売中です。 <a>http://p.booklog.jp/book/86773</a> 「Git(ギット)」や「バージョン管理」という言葉は聞いたことはあっても、なんだか難しそうなイメージを持っているかも知れません。 特に、プログラマーやエンジニアのツールであって、デザイナー・マークアップエンジニア・ディレクターの方は「自分には無縁」と思っているのではないでしょうか。 しかし、Gitはプロジェクトに関わるすべての方が使えると、コミュニケーションツールとしての役割も果たし、非常にスムーズにプロジェクトを進行させることができます。 このイベントでは「ノンプログラマの方」を対象に、Gitのよく使う部分だけをピックアップしてわかりやすく紹介、今日から使えるテクニックや便利なポイントを紹介していきます。
ノンプログラマでも今日から使える「Git」でバージョン管理
ノンプログラマでも今日から使える「Git」でバージョン管理
H2O Space. Co., Ltd.
Gitってなに? プログラマではないけれど、Git導入するメリットは? いわゆるデザイナーやコーダー向けの、「Gitとは?」「Gitの構造とは?」…のやさしい説明スライドです。 デザイナーやコーダーがGitを使う際には、とっつきにくい「コマンド」をまったく覚えなくてもOK! 便利なGUIツールが沢山出ています。 (私はWindowsなのでGit Extensions派) Gitの言葉や構造を理解するための、社内勉強会で使った資料です。
はじめてのGit forデザイナー&コーダー
はじめてのGit forデザイナー&コーダー
Saeko Yamamoto
↓のv1.1.0版の方が、より見やすく改善したものになってます! http://www.slideshare.net/matsukaz/git-28304397 社内で開催したGit勉強会の資料。 SVNとの比較や、Gitの内部構造と各コマンドの関係、ブランチやリモートリポジトリとの関係を分かりやすく説明したつもり。 こういう資料に対する投げ銭的なのがどうなるのか気になっていたので、もしよろしければ・・・!15円からできるソーシャルカンパサービスだそうですm(_ _)m http://kampa.me/t/dev
いつやるの?Git入門
いつやるの?Git入門
Masakazu Matsushita
「マージがなんとなく怖い」「リベースするなって怒られて怖い」「エラーが出て怖い」 Git 入門者にありがちな「Git 怖い」を解消するため、Git のお仕事(コミット、ブランチ、マージ、リベース)について解説します。
こわくない Git
こわくない Git
Kota Saito
広島Git 勉強会 201306 の資料。 補足はこちらに http://blog.eiel.info/blog/2013/06/02/hiroshima-git/ 元に戻すを主眼に、危険と少し危険にコマンドを分類してみた。 危険 - 変更が消えてしまい復元できない 少し危険 - コミットへの参照がない状態になる
やりなおせる Git 入門
やりなおせる Git 入門
Tomohiko Himura
SourceTreeで始めよう! Gitへの乗り換え指南 - Atlassian User Group NAGOYA 第3回 ユーザーミーティング http://www.kekyo.net/2015/07/23/5241
SourceTreeで始めよう! Gitへの乗り換え指南
SourceTreeで始めよう! Gitへの乗り換え指南
Kouji Matsui
@PHPerKaigi 2022
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
社内のマニュアルをSphinxで作ってみたら見事に技術的負債になった話。
社内のマニュアルをSphinxで作ってみた
社内のマニュアルをSphinxで作ってみた
Iosif Takakura
REST and gRPC for microservices backend API
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPC
disc99_
バージョン管理のワークフロー
バージョン管理のワークフロー
add20
HTTP/2 入門
HTTP/2 入門
Yahoo!デベロッパーネットワーク
社内勉強会向けに資料を作りましたので公開します。自分も初心者なので間違っているところもあると思いますので、是非教えてください。
社内Git勉強会向け資料
社内Git勉強会向け資料
Hiroki Saiki
Overview about Git/GitHub
Git_GitHub 入門者向けスライド.pdf
Git_GitHub 入門者向けスライド.pdf
Yoshiki Tanaka
20110730_Redmineでのタスク管理を考える勉強会@大阪 第1回 (2011/07/30) - RxTstudy https://sites.google.com/site/rxtstudy/home/20110730 【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索 http://forza.cocolog-nifty.com/blog/2011/07/redminefaq-rxts.html RxTstudy Redmineでのタスク管理を考える勉強会@大阪 - Togetterまとめ http://togetter.com/li/168362
RedmineのFAQとアンチパターン集
RedmineのFAQとアンチパターン集
akipii Oga
社内で技術発表会を行ったときのスライドです。 git-flowの基本的なルール説明と、git-flow運用下での管理テクニックについて説明しています。
Git flowの活用事例
Git flowの活用事例
Hirohito Kato
2017年8月16日に熊本で開催されたプログラミング勉強会「オトナのGit入門」の資料です。
プログラミング勉強会「オトナのGit入門」
プログラミング勉強会「オトナのGit入門」
Yoshinori Yamanouchi
2018/03/01 GitHub Enterpriseユーザ会 での登壇資料です。
GHE導入から社内普及までの軌跡 - エバンジェリストとしての取り組みについて -
GHE導入から社内普及までの軌跡 - エバンジェリストとしての取り組みについて -
ShionITO1
Javaコードが速く実⾏される秘密 - JITコンパイラ⼊⾨ (2020年11⽉7⽇ JJUG CCC 2020 Fall 講演資料) NTTデータ 技術開発本部 先進コンピューティング技術センタ 阪⽥ 浩⼀
Javaコードが速く実⾏される秘密 - JITコンパイラ⼊⾨(JJUG CCC 2020 Fall講演資料)
Javaコードが速く実⾏される秘密 - JITコンパイラ⼊⾨(JJUG CCC 2020 Fall講演資料)
NTT DATA Technology & Innovation
RDRAモデルによる要件定義を紹介 1.AIを使ってRDRAモデルの要素を洗い出す 2.表形式で要件を定義 3.要件の精度を向上させるために定義内容を分析 4.表形式からグラフ形式に変換 トレーサビリティ 凝集度・結合度把握 5.AIを使って要件を要約し俯瞰する
AI時代の要件定義
AI時代の要件定義
Zenji Kanzaki
2019年12月3日開催 『GitHub Enterprise Roadshow』での発表スライドです。
GitHub Enterpriseの導入事例と実践GitHub Actions
GitHub Enterpriseの導入事例と実践GitHub Actions
Shuji Yamada
GCPUG 大阪 BigQueryの課金、節約しませんか
BigQueryの課金、節約しませんか
BigQueryの課金、節約しませんか
Ryuji Tamagawa
pythonでオフィス快適化計画
pythonでオフィス快適化計画
Kazufumi Ohkawa
教育心理学MeetupでのLTスライド 本を読んでいない方もそっか〜じゃぁ読んでみようかな、WSとか練習してみたいな、とか思っていただければ幸い
教育心理学概論を読んで新人研修やってみた-教育心理学との付き合い方-
教育心理学概論を読んで新人研修やってみた-教育心理学との付き合い方-
pupupopo88
Contenu connexe
Tendances
「マージがなんとなく怖い」「リベースするなって怒られて怖い」「エラーが出て怖い」 Git 入門者にありがちな「Git 怖い」を解消するため、Git のお仕事(コミット、ブランチ、マージ、リベース)について解説します。
こわくない Git
こわくない Git
Kota Saito
広島Git 勉強会 201306 の資料。 補足はこちらに http://blog.eiel.info/blog/2013/06/02/hiroshima-git/ 元に戻すを主眼に、危険と少し危険にコマンドを分類してみた。 危険 - 変更が消えてしまい復元できない 少し危険 - コミットへの参照がない状態になる
やりなおせる Git 入門
やりなおせる Git 入門
Tomohiko Himura
SourceTreeで始めよう! Gitへの乗り換え指南 - Atlassian User Group NAGOYA 第3回 ユーザーミーティング http://www.kekyo.net/2015/07/23/5241
SourceTreeで始めよう! Gitへの乗り換え指南
SourceTreeで始めよう! Gitへの乗り換え指南
Kouji Matsui
@PHPerKaigi 2022
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
社内のマニュアルをSphinxで作ってみたら見事に技術的負債になった話。
社内のマニュアルをSphinxで作ってみた
社内のマニュアルをSphinxで作ってみた
Iosif Takakura
REST and gRPC for microservices backend API
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPC
disc99_
バージョン管理のワークフロー
バージョン管理のワークフロー
add20
HTTP/2 入門
HTTP/2 入門
Yahoo!デベロッパーネットワーク
社内勉強会向けに資料を作りましたので公開します。自分も初心者なので間違っているところもあると思いますので、是非教えてください。
社内Git勉強会向け資料
社内Git勉強会向け資料
Hiroki Saiki
Overview about Git/GitHub
Git_GitHub 入門者向けスライド.pdf
Git_GitHub 入門者向けスライド.pdf
Yoshiki Tanaka
20110730_Redmineでのタスク管理を考える勉強会@大阪 第1回 (2011/07/30) - RxTstudy https://sites.google.com/site/rxtstudy/home/20110730 【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索 http://forza.cocolog-nifty.com/blog/2011/07/redminefaq-rxts.html RxTstudy Redmineでのタスク管理を考える勉強会@大阪 - Togetterまとめ http://togetter.com/li/168362
RedmineのFAQとアンチパターン集
RedmineのFAQとアンチパターン集
akipii Oga
社内で技術発表会を行ったときのスライドです。 git-flowの基本的なルール説明と、git-flow運用下での管理テクニックについて説明しています。
Git flowの活用事例
Git flowの活用事例
Hirohito Kato
2017年8月16日に熊本で開催されたプログラミング勉強会「オトナのGit入門」の資料です。
プログラミング勉強会「オトナのGit入門」
プログラミング勉強会「オトナのGit入門」
Yoshinori Yamanouchi
2018/03/01 GitHub Enterpriseユーザ会 での登壇資料です。
GHE導入から社内普及までの軌跡 - エバンジェリストとしての取り組みについて -
GHE導入から社内普及までの軌跡 - エバンジェリストとしての取り組みについて -
ShionITO1
Javaコードが速く実⾏される秘密 - JITコンパイラ⼊⾨ (2020年11⽉7⽇ JJUG CCC 2020 Fall 講演資料) NTTデータ 技術開発本部 先進コンピューティング技術センタ 阪⽥ 浩⼀
Javaコードが速く実⾏される秘密 - JITコンパイラ⼊⾨(JJUG CCC 2020 Fall講演資料)
Javaコードが速く実⾏される秘密 - JITコンパイラ⼊⾨(JJUG CCC 2020 Fall講演資料)
NTT DATA Technology & Innovation
RDRAモデルによる要件定義を紹介 1.AIを使ってRDRAモデルの要素を洗い出す 2.表形式で要件を定義 3.要件の精度を向上させるために定義内容を分析 4.表形式からグラフ形式に変換 トレーサビリティ 凝集度・結合度把握 5.AIを使って要件を要約し俯瞰する
AI時代の要件定義
AI時代の要件定義
Zenji Kanzaki
2019年12月3日開催 『GitHub Enterprise Roadshow』での発表スライドです。
GitHub Enterpriseの導入事例と実践GitHub Actions
GitHub Enterpriseの導入事例と実践GitHub Actions
Shuji Yamada
GCPUG 大阪 BigQueryの課金、節約しませんか
BigQueryの課金、節約しませんか
BigQueryの課金、節約しませんか
Ryuji Tamagawa
Tendances
(20)
こわくない Git
こわくない Git
やりなおせる Git 入門
やりなおせる Git 入門
SourceTreeで始めよう! Gitへの乗り換え指南
SourceTreeで始めよう! Gitへの乗り換え指南
テストコードの DRY と DAMP
テストコードの DRY と DAMP
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
社内のマニュアルをSphinxで作ってみた
社内のマニュアルをSphinxで作ってみた
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPC
バージョン管理のワークフロー
バージョン管理のワークフロー
HTTP/2 入門
HTTP/2 入門
社内Git勉強会向け資料
社内Git勉強会向け資料
Git_GitHub 入門者向けスライド.pdf
Git_GitHub 入門者向けスライド.pdf
RedmineのFAQとアンチパターン集
RedmineのFAQとアンチパターン集
Git flowの活用事例
Git flowの活用事例
プログラミング勉強会「オトナのGit入門」
プログラミング勉強会「オトナのGit入門」
GHE導入から社内普及までの軌跡 - エバンジェリストとしての取り組みについて -
GHE導入から社内普及までの軌跡 - エバンジェリストとしての取り組みについて -
Javaコードが速く実⾏される秘密 - JITコンパイラ⼊⾨(JJUG CCC 2020 Fall講演資料)
Javaコードが速く実⾏される秘密 - JITコンパイラ⼊⾨(JJUG CCC 2020 Fall講演資料)
AI時代の要件定義
AI時代の要件定義
GitHub Enterpriseの導入事例と実践GitHub Actions
GitHub Enterpriseの導入事例と実践GitHub Actions
BigQueryの課金、節約しませんか
BigQueryの課金、節約しませんか
En vedette
pythonでオフィス快適化計画
pythonでオフィス快適化計画
Kazufumi Ohkawa
教育心理学MeetupでのLTスライド 本を読んでいない方もそっか〜じゃぁ読んでみようかな、WSとか練習してみたいな、とか思っていただければ幸い
教育心理学概論を読んで新人研修やってみた-教育心理学との付き合い方-
教育心理学概論を読んで新人研修やってみた-教育心理学との付き合い方-
pupupopo88
Tokyo Middleman Meetup #3 で発表した内容 導入の経緯と実際のアーキテクチャ、運用の流れをかるーくご紹介
Middlemanを使用した静的サイトの運用事例
Middlemanを使用した静的サイトの運用事例
pupupopo88
「XP祭り 2015」でのLTスライド。 総務でやっているアジャイルプラクティスを簡単に紹介したものです。
"総務も!!"アジャイルプラクティス!
"総務も!!"アジャイルプラクティス!
pupupopo88
IT/Web業界の9社が2014年に行った「新人シェア研修」のご紹介資料です。
新人シェア研修について
新人シェア研修について
ITmedia_HR(人事・採用)
新入社員研修資料のサンプル
新入社員研修資料のサンプル
creiajp
研修成果発表資料
研修成果プレゼン資料
研修成果プレゼン資料
Wataru Yamaura
研修企画書のフォーマットになります! これを記入例にして、各研修で研修企画書を毎月アップロードしていってください!
研修企画書11 12term team名-tn名
研修企画書11 12term team名-tn名
aiesecsfc_icx2011
2016 新人研修 基本技術講座 (1)
2016 新人研修 基本技術講座 (1)
2016 新人研修 基本技術講座 (1)
エンジニア勉強会 エスキュービズム
本書は、このITの基礎的な知識と最新のトレンドに関する最低限の常識を整理するための教科書です。MS word形式(本文54ページ)で掲載致しました。必要に応じて改変しご利用ください。 http://libra.netcommerce.co.jp/
【新人研修】ITの基礎と最新の常識
【新人研修】ITの基礎と最新の常識
Masanori Saito
2015年度 GX/MF エンジニア合同新人研修 3日目
JavaScript 研修
JavaScript 研修
Yuki Ishikawa
エフスタ!でのLT資料です。
とある中堅ベンチャーの新人研修戦略 #efsta42
とある中堅ベンチャーの新人研修戦略 #efsta42
Mamiko Tsuda
2015-06-27(土)エフスタ!!TOKYOのLT資料です。研修を充実させるためにやってきたことなどを簡単に紹介したものです。
新入社員の技術研修に関してありがちな問題を解決するためにやったことやるべきこと
新入社員の技術研修に関してありがちな問題を解決するためにやったことやるべきこと
pupupopo88
学内で行われたインターンシップの成果報告会の発表資料です。 発表時間は5分、質疑応答はコメントのみでした。 マズいなという部分は括弧付きで誤魔化しています。 インターンシップ担当の先生に多々ご指導いただき 学科内最優秀発表賞をいただく事が出来ました。 しかしながら自分の中では納得していない点も多く、 プレゼンテーションの奥深さを感じる次第となったので 今後活かしていきたい所であります。 修正前の資料はコチラ→http://www.slideshare.net/T2C_/internship-progressreportbefore
インターンシップ成果報告会 発表資料
インターンシップ成果報告会 発表資料
T2C_
伝わるプレゼンをする方法。2012/03/03 俺の話を聞け
伝わるプレゼンをする方法
伝わるプレゼンをする方法
Hideaki Miyake
プレゼンの基本
プレゼンの基本
Hiroyuki Nagataki
北海道大学 高等教育推進機構 オープンエデュケーションセンター 科学技術コミュニケーション教育研究部門 (CoSTEP) 准教授 石村源生 ishimura[at]costep.hucc.hokudai.ac.jp ※[at]を@に変えて送信
プレゼンテーションの考え方20140628
プレゼンテーションの考え方20140628
Professional University of Information and Management for Innovation (情報経営イノベーション専門職大学)
綺麗なプレゼン資料の作り方、10のテクニック ガイド吹き出しなし
綺麗なプレゼン資料の作り方、10のテクニック
綺麗なプレゼン資料の作り方、10のテクニック
Manabu Uekusa
ーーーーーーーーーーーーーーーーーーーーーーー schoo WEB-campusは「WEBに誕生した、学校の新しいカタチ」。 WEB生放送の授業を無料で配信しています。 ▼こちらから授業に参加すると、先生への質問や、ユーザーとのチャット、資料の拡大表示等が可能です。 https://schoo.jp/class/307/room ーーーーーーーーーーーーーーーーーーーーーーー
魅せるPowerPointビジネスプレゼン【実践編】
魅せるPowerPointビジネスプレゼン【実践編】
schoowebcampus
良いプレゼン 良いスライド
良いプレゼン 良いスライド
京大 マイコンクラブ
En vedette
(20)
pythonでオフィス快適化計画
pythonでオフィス快適化計画
教育心理学概論を読んで新人研修やってみた-教育心理学との付き合い方-
教育心理学概論を読んで新人研修やってみた-教育心理学との付き合い方-
Middlemanを使用した静的サイトの運用事例
Middlemanを使用した静的サイトの運用事例
"総務も!!"アジャイルプラクティス!
"総務も!!"アジャイルプラクティス!
新人シェア研修について
新人シェア研修について
新入社員研修資料のサンプル
新入社員研修資料のサンプル
研修成果プレゼン資料
研修成果プレゼン資料
研修企画書11 12term team名-tn名
研修企画書11 12term team名-tn名
2016 新人研修 基本技術講座 (1)
2016 新人研修 基本技術講座 (1)
【新人研修】ITの基礎と最新の常識
【新人研修】ITの基礎と最新の常識
JavaScript 研修
JavaScript 研修
とある中堅ベンチャーの新人研修戦略 #efsta42
とある中堅ベンチャーの新人研修戦略 #efsta42
新入社員の技術研修に関してありがちな問題を解決するためにやったことやるべきこと
新入社員の技術研修に関してありがちな問題を解決するためにやったことやるべきこと
インターンシップ成果報告会 発表資料
インターンシップ成果報告会 発表資料
伝わるプレゼンをする方法
伝わるプレゼンをする方法
プレゼンの基本
プレゼンの基本
プレゼンテーションの考え方20140628
プレゼンテーションの考え方20140628
綺麗なプレゼン資料の作り方、10のテクニック
綺麗なプレゼン資料の作り方、10のテクニック
魅せるPowerPointビジネスプレゼン【実践編】
魅せるPowerPointビジネスプレゼン【実践編】
良いプレゼン 良いスライド
良いプレゼン 良いスライド
Similaire à 新人Git/Github研修公開用スライド(その1)
【エンジニア向け】Git 初心者講座 by Forkwell https://forkwell.connpass.com/event/47137/
Git 初心者講座 by forkwell
Git 初心者講座 by forkwell
sinsoku listy
15 「テクトモ#6 Goってどんな言語?導入事例や気になるトレンド」登壇資料 Googleが開発したプログラミング言語 "Go"は、今もっとも人気のある言語の1つです。 「そもそも"Go"言語って何なの?」「何が特徴なの?」「導入事例は?」「学ぶにはどうしたらいいの?」 という疑問について、わかりやすく解説します。 https://techtomo.connpass.com/event/105908/
Go言語ってどんな言語? 導入実績や気になるトレンド
Go言語ってどんな言語? 導入実績や気になるトレンド
Atsushi Yasuda
2017/5/17で筑波大学enPiTで実施する演習用のスライド。 enPiTのPBLの事前準備としての説明に特化しているため、 一般的なGitやGithubの説明はありません。
Git github演習
Git github演習
Chiemi Watanabe
2023/3/10 Deep Learning JP http://deeplearning.jp/seminar-2/
【DL輪読会】Visual ChatGPT: Talking, Drawing and Editing with Visual Foundation Mo...
【DL輪読会】Visual ChatGPT: Talking, Drawing and Editing with Visual Foundation Mo...
Deep Learning JP
RealtimeTweakPickerMode
RealtimeTweakPickerMode
RealtimeTweakPickerMode
Yoh Akiyama
Let's learn how to use Cloud Datalab deeply.
Datalab and colaboratory
Datalab and colaboratory
Hayato Yoshikawa
2015/10の社内勉強会資料です。
Go 言語を語ってみるか
Go 言語を語ってみるか
Akihiko Matuura
「1st Knock!」Knock! Knock! 静岡のWeb制作者のための勉強会発表資料
今日からはじめるHTML5 ver.2012
今日からはじめるHTML5 ver.2012
Yasuhito Yabe
Similaire à 新人Git/Github研修公開用スライド(その1)
(8)
Git 初心者講座 by forkwell
Git 初心者講座 by forkwell
Go言語ってどんな言語? 導入実績や気になるトレンド
Go言語ってどんな言語? 導入実績や気になるトレンド
Git github演習
Git github演習
【DL輪読会】Visual ChatGPT: Talking, Drawing and Editing with Visual Foundation Mo...
【DL輪読会】Visual ChatGPT: Talking, Drawing and Editing with Visual Foundation Mo...
RealtimeTweakPickerMode
RealtimeTweakPickerMode
Datalab and colaboratory
Datalab and colaboratory
Go 言語を語ってみるか
Go 言語を語ってみるか
今日からはじめるHTML5 ver.2012
今日からはじめるHTML5 ver.2012
新人Git/Github研修公開用スライド(その1)
1.
Git / Github
研修 2015/6/4,5 株式会社ヴァル研究所 ぷぽ(@pupupopo88) 前半戦! 1 公開用
2.
このスライドについて 新人研修でやった内容を一部公開用に修正したもの 研修の対象(想定) 開発未経験者(数名程度) 配属も開発とは限らない HTML5とCSS3の基本はレクチャー済み イメージを持ってもらうことを優先しているため、 多少表現に無理(まちがい)があります 2
3.
ざっくりなもくじ 複数人でのファイル変更 バージョン管理システム Git・基本操作 歴史を分岐させる(ブランチ) 歴史を統合させる(マージ) 歴史をなかったことにする(リセット) 総合れんしゅう おまけ 3 p. 7 p. 46 p.
52 p.123 p.150 p.199 p.267 p.282
4.
自己紹介 「ぷぽさん」「ぷぽ氏」と呼ばれてたり します 総務です 新卒文系未経験で入社後、2年間エンジ ニア(エンジニアとはいっていない)を やってました。今年で入社4年目です。 Gitを触り始めたのは丁度2年前くらい まだまだぺーぺーです みなさんと一緒に学んでいきたいです 4
5.
本研修の目標 (なんとなく)「バージョン管理システム」がなん なのかイメージできる (なんとなく)「Git」がなんなのかイメージできる (なんとなく)「Github」がなんなのかイメージで きる GitやGithubを使うことを怖がらない 5
6.
なんとなく イメージできればおk 6
7.
はじまりはじまり 7
8.
突然ですが 8
9.
複数人で ひとつのファイルを 扱ったことはありますか 9
10.
たとえば 10
11.
たとえば2 11
12.
チームで開発(お仕事)することが増えてきます 12 これからは
13.
まずはイメージを つかんでいただくために 13
14.
実際のPJを想定して 作業をしてみましょう 14
15.
_人人人人人人人_ > 突然の課題 <  ̄Y^Y^Y^Y^Y^Y ̄ 15
16.
ひとりで作業する 16
17.
- うちわネタ多数により省略 - 17
18.
やったことは 社内用共有サーバにファイル(HTML)を配置 各自、そのファイルに手を入れてもらう ファイルを修正する さらにファイルを修正する (退社という体で)エディタを閉じる (翌日という体で)元に戻してという →うそやん!!! 18
19.
もう一度やります ※ファイルリセット 19
20.
- 再びの省略 - 20
21.
やったことは 先ほどと同様のファイルに手を入れる Aさんから修正依頼 Bさんから修正依頼 (翌日)Aさんから追加修正依頼 Cさんから「Bさんの修正」を元に戻す依頼 (更に翌日)Bさんから再度修正依頼 → …。 21
22.
_人人人人人人人人_ > 理不尽なっ! <  ̄Y^Y^Y^Y^Y^Y ̄ 22
23.
どうでした? ひとりひとり感想をどうぞ 23
24.
どうでした? ひとりひとり感想をどうぞ 「変更を自前で管理する」ってつらいですよね 23
25.
Next 24
26.
複数人で同時作業する 25
27.
やること 社内用共有サーバに置いてあるファイル (HTML)に対して、複数人で変更を加える 作業は個別にメールで指示 26
28.
どんな方法があるかな 自分がやる作業しか見えていないですよね 同じファイルを変更しなければならないですよね 方法はお任せします が、作業に入る前に考えを聞かせてください 3分程度で案出してね! 27
29.
ヒント たとえば 各自変更点を共有、変更すべき点をまとめて誰 かが全部やるとか? たとえば 各自共有サーバにあるファイルをコピー、それ ぞれ作業した後に変更点を合わせるとか? 28
30.
どうでした? ひとりひとり感想をどうぞ 29
31.
どうでした? ひとりひとり感想をどうぞ 「チームで1つのことをする」って大変ですよね 29
32.
困ることってなんだろう いつ変更したか 誰が変更したか どこを変更したか 何のために変更したか やった本人にしかわからない (本人も数日後、数か月後、数年後わからなくなる) ネットが切れると終わる(しかも社内ネットワーク) 30
33.
大変なのは わかったけど 31
34.
これらの問題 どうやったら解決できる? 32
35.
ご意見ください! 33
36.
解決……? コードに全部コメントで書く? コードが肥大化する!見にくい! 別にファイルを用意して記録しておく? プログラムはよく変更されるもの 管理が大変 すぐにわからなくなる 34
37.
これらの問題を 解決するために 35
38.
バージョン管理システム というものが存在します 36
39.
バージョン管理システムとは 安心してファイルの変更ができる 前のバージョンに戻せる、差分が見られる 自前でファイル変更に関する情報を残さなくていい いつ誰が変更したのかわかる 複数人で作業するときラク 各々の作業をマージできる 37
40.
かんたんにいうと 38
41.
こんなかんじ 39
42.
Git 40
43.
バージョン管理システム 41
44.
バージョン管理システム 41
45.
Gitの特徴 手軽にバージョンの切り替えができる 処理が高速 安心度が高い 分散型の管理 複数人で作業するのに適している 賢いマージ 42
46.
Gitを使ってみよう 43
47.
CUI vs GUI 黒い(文字ばっかりの)画面 後々がっつりやるなら絶対こっちがいい 最初は難易度高め 私も普段はこっち ソフトウェア イメージをつかむにはもってこい 今回はこっちを使います 44
48.
45
49.
まずは準備から 作業スペースを確保しましょう Finderからどうぞ documents/git_study/git_practice このディレクトリ以下で作業していきます 46
50.
Gitで管理はじめる 47
51.
Gitで管理はじめる 48
52.
• ん…何か出来ている…! Finderで確認 49
53.
そのディレクトリ以下で行われたファイルを管理 したりします .git ディレクトリ 50
54.
51
55.
リポジトリ 51
56.
管理して欲しくない ファイルがある場合 52
57.
.gitignoreさん .gitignoreというファイルに記述してあるディレ クトリやファイルは、いくらリポジトリ内にあっ ても、バージョン管理の対象になりません .DS_Storeとか、*.xlsとか、/logとか そんなの管理しなくてもいい 53
58.
リポジトリ 54
59.
かき方(例) 55 全部ハブられる
60.
もどります 56
61.
リポジトリにファイル置いてみる index.htmlをつくってください ひとまず中身はカラで大丈夫 57
62.
58
63.
歴史を刻んでいく… gitさんがこんなファイル知らんぞと言ってます ファイルを追加したことを歴史に刻みましょう 59
64.
チェックを入れると 60
65.
上のエリアに移動します 61
66.
インデックスに追加 先ほどの操作をインデックスに追加(add また は ステージング)するといいます この状態では、まだ完全に歴史として刻まれてい ません 62
67.
実際に記録する 63
68.
64
69.
65
70.
コミットメッセージ 66
71.
思い出してください ファイル変更の際、必要とされる情報ってなんで したっけ? 「いつ」「だれが」「どこを」「なぜ」変更した か 「なぜ」を残すことを心がけましょう 「なぜ」は機械には判断できない 67
72.
68
73.
記録できた!(変更点なし) 69
74.
もうちょっとわかりやすく 70
75.
71
76.
思い出してください(再) ファイル変更の際、必要とされる情報 「いつ」 「だれが」 「どこを」 「なぜ」変更したか 72
77.
73
78.
いつ 73
79.
だれが いつ 73
80.
だれが いつ どこを 73
81.
だれが いつなぜ どこを 73
82.
_人人人人人人_ > あら便利 <  ̄Y^Y^Y^Y^Y ̄ 74
83.
コミットメッセージ 「なぜ」を残すことを心がけましょう 「なぜ」は機械には判断できない 長くなる場合 1行目に概要 1行空ける 3行目に詳細を書く 75
84.
もう一度 やってみましょう 76
85.
index.htmlの変更 index.htmlにHTML5のテンプレタグを追加 77
86.
SourceTreeをみてみる 78
87.
にょきっと生えた コミット(記録)していない 変更点があるよ 79
88.
直前の記録からの変更 変更されたファイル 80
89.
直前の記録からの変更 追加された箇所 (+で背景が緑色) 81
90.
add, commitしてください 82
91.
記録できた! 83
92.
もう一度 やってみましょう 84
93.
CSSファイルの追加 デザインも変更したいのでCSSファイルを追加 「サイト全体の文字をセンター寄せにしたい」 css/common.css body {text-align: center;} 85
94.
index.htmlの変更 index.htmlでスタイルシートを読み込む 86
95.
SourceTreeをみてみる 87
96.
直前の記録からの変更 変更されたファイル 追加されたファイル 88
97.
直前の記録からの変更 追加された箇所 (+で背景が緑色) 追加されたファイル 89
98.
add, commitしてください 90
99.
記録できたー! 91
100.
ちょっとまって 92
101.
add 93
102.
add 93
103.
add commit 93
104.
この操作必要? addしてcommitってめんどくないですか? なんで一回前置きが必要なの? 94
105.
結論:あると便利 95
106.
別のシーンで やってみましょう 96
107.
index.htmlを変更する センタリングしたのにタグしか書いてなかった (body以下に何も書いていなかった) <header>タグを追加しよう <h1>タグで見出しも追加しよう あれ、cssのパス指定が間違ってた ×:common.css ○:css/common.css 97
108.
index.htmlの変更 あ、<title>タグに何も書いていなかった そういえばメニューも追加したい リスト形式でメニューを作ろう それならそれぞれページも追加しなきゃ 98
109.
common.cssの変更 メニュー リストだけど先頭の「・」をなくしたい 左側の余白が余計なのでなくしたい 99
110.
100
111.
その結果 101
112.
その結果 102
113.
103
114.
_人人人人人_ > カオス <  ̄Y^Y^Y^Y ̄ 104
115.
一気にファイル変更 しちゃったけど これ一気にコミットするとダメ…だよね? コミットメッセージどうするの? 「いろいろ変更」じゃ伝わらない まずはcssのパスが間違ってたやつをコミットし たい そこだけadd(ステージング)すればいい! 105
116.
選択してステージング ※選択行が連続していないと 一度にaddできないため、 一行ずつaddする 106
117.
指定したところだけaddされている 107
118.
それ以外は残ったまま 108
119.
コミットできた! 109
120.
もしステージングエリアがなかっ たら 記録したくないところまで記録するはめになる 記録したい部分だけ残し、他の変更点を一度破棄 する。それをコミットしてから、さっき破棄した 変更を復元するはめになる わかりにくいしめんどくさい 110
121.
好き勝手できるところ 次の歴史に刻むものを選出 歴史として記録! (ワーキングツリー、ワーキングコピー) (ステージングエリア) 111
122.
add 好き勝手できるところ 次の歴史に刻むものを選出 歴史として記録! (ワーキングツリー、ワーキングコピー) (ステージングエリア) 111
123.
add commit 好き勝手できるところ 次の歴史に刻むものを選出 歴史として記録! (ワーキングツリー、ワーキングコピー) (ステージングエリア) 111
124.
気をつけたい コミットの粒度 一度にコミットしても分からない いろいろ修正 → 何を?なんで? こまめにコミットしすぎても分かりづらい 見出しを追加 → それをセンタリング
→ → それの色を変更 → それの余白を調整 → → それの… ひとつの機能ごとにコミットしましょう 112
125.
練習問題 先ほど変更したものを全部コミットしましょう ポイント どんな単位でコミットすればいい? コミットメッセージはどう書くのがいい? 113
126.
歴史を分岐させる 114
127.
思い出してください バージョン管理システムの特徴 安心してファイルの変更ができる 前のバージョンに戻せる 特にGitは 手軽にバージョンの切り替えができる →どういうこと? 115
128.
枝(ブランチ)分かれ 116
129.
えいっ 枝(ブランチ)分かれ 116
130.
えいっ やぁっ 枝(ブランチ)分かれ 116
131.
えいっ やぁっ _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 枝(ブランチ)分かれ 116
132.
とぉっ えいっ やぁっ _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 枝(ブランチ)分かれ 116
133.
ブランチの種類 今まで操作していたのはmasterブランチ(本流) 基本masterブランチは直接いじらない 何か作業をする時は、その作業ベースでブランチをつ くる バグの修正、新規ページの作成 etc… ブランチの名前は自分で命名する 作業終了後、問題なければmasterに合流させる 117
134.
master(本流) 118
135.
master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 118
136.
ブランチ master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 118
137.
ブランチ master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 118
138.
ブランチ master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ _人人人人_ > 合流 <  ̄Y^Y^Y ̄ 118
139.
たとえば サイトをリニューアルしたい A案とB案があります だいたいどんな感じになるかな 実物見てどっちが良いか決めたいな 119
140.
master(本流) それぞれのブランチで ファイルを変更していく 120
141.
master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ それぞれのブランチで ファイルを変更していく 120
142.
master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ それぞれのブランチで ファイルを変更していく 120
143.
A案用のブランチ master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ それぞれのブランチで ファイルを変更していく 120
144.
A案用のブランチ master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ それぞれのブランチで ファイルを変更していく _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 120
145.
A案用のブランチ master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ それぞれのブランチで ファイルを変更していく _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 120
146.
A案用のブランチ master(本流) B案用のブランチ _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ それぞれのブランチで ファイルを変更していく _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 120
147.
実際にやってみよう ブランチを生やす 121
148.
今回編集するところ バージョン管理システムとは(index.html) 安心してファイルの変更ができる 前のバージョンに戻せる 差分が見られる 自前でファイル変更に関する情報を残さなくていい いつ誰がどこを変更したのかわかる 複数人で作業する時ラク 各々の作業をマージできる 122
149.
ブランチを生やす 枝分かれさせるには名前が必要 それは何の作業をするために分岐させるのか 沢山切ってたら何がどれか分からなくなる 必ず意味のある名前を! 命名規則はプロジェクトなどによって違うので 注意! 123
150.
こちらから 124
151.
125
152.
ブランチつくれた 作成したブランチ 126
153.
127
154.
チェックアウト#とは 指定のコミット(時点)へ移動する操作 あの頃に戻りたい…。 リポジトリをその頃の状態に戻せる 新規ブランチをチェックアウト ブランチを作成して、そのブランチの最新のコミッ トに移動する コミットをすると、チェックアウトしている(今 いる)ブランチで枝がニョキニョキ増えていく 128
155.
ブランチを作成してチェックアウトした後、 コミットしていくの図 master(本流) 129
156.
_人人人人_ > 分岐 <  ̄Y^Y^Y ̄ ブランチを作成してチェックアウトした後、 コミットしていくの図 master(本流) 129
157.
_人人人人_ > 分岐 <  ̄Y^Y^Y ̄ _人人人人人人人人人人人人人人人_ > ブランチAにチェックアウト <  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄ ブランチを作成してチェックアウトした後、 コミットしていくの図 master(本流) 129
158.
_人人人人人人_ > コミット <  ̄Y^Y^Y^Y^Y ̄ _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ _人人人人人人人人人人人人人人人_ > ブランチAにチェックアウト <  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄ ブランチを作成してチェックアウトした後、 コミットしていくの図 master(本流) 129
159.
ブランチA _人人人人人人_ > コミット <  ̄Y^Y^Y^Y^Y ̄ _人人人人人人_ > コミット <  ̄Y^Y^Y^Y^Y ̄ _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ _人人人人人人人人人人人人人人人_ > ブランチAにチェックアウト <  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄ ブランチを作成してチェックアウトした後、 コミットしていくの図 master(本流) 129
160.
チェックアウト 忘れてたの図 130
161.
チェックアウト 忘れてたの図 _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 130
162.
ブランチA チェックアウト 忘れてたの図 _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 130
163.
ブランチA チェックアウト忘れてた チェックアウト 忘れてたの図 _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 130
164.
ブランチA チェックアウト忘れてた チェックアウト 忘れてたの図 _人人人人人人_ > コミット <  ̄Y^Y^Y^Y^Y ̄ _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 130
165.
ブランチA チェックアウト忘れてた チェックアウト 忘れてたの図 _人人人人人人_ > コミット <  ̄Y^Y^Y^Y^Y ̄ master(本流) _人人人人人人_ > コミット <  ̄Y^Y^Y^Y^Y ̄ _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 130
166.
131
167.
master(本流) 現状 132
168.
master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 現状 132
169.
master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ _人人人人人人人人人_ > チェックアウト <  ̄Y^Y^Y^Y^Y^Y^Y ̄ 現状 132
170.
add-about-vcs 次コミットしたらこうなる master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ _人人人人人人人人人_ > チェックアウト <  ̄Y^Y^Y^Y^Y^Y^Y ̄ 現状 132
171.
ファイルを変更する バージョン管理システムとは(index.html) 安心してファイルの変更ができる 前のバージョンに戻せる 差分が見られる 自前でファイル変更に関する情報を残さなくていい いつ誰がどこを変更したのかわかる 複数人で作業する時ラク 各々の作業をマージできる 133
172.
134
173.
コミットできた! 135
174.
その結果 136
175.
なんかイケてない… 137
176.
ページレイアウト どうするか 試行錯誤したい 138
177.
A案用のブランチ master(本流) B案用のブランチ _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ それぞれのブランチで ファイルを変更していく _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 139
178.
_人人人人人_ > これだ <  ̄Y^Y^Y^Y ̄ 140
179.
その前に 一旦変更を本流に取り込みましょう これ 141
180.
!注意! 親(master)ブランチから 子ブランチ(add-about-vcs)を統合させる まず親ブランチにチェックアウトしてから統合 142
181.
143
182.
masterをチェックアウト ダブルクリック or 右クリックから 144
183.
145
184.
146
185.
147
186.
マージできた 148
187.
なんかブランチ 一本になってるけど 149
188.
master(本流) 150
189.
master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 150
190.
ブランチ master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 150
191.
ブランチ master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ 150
192.
ブランチ master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ _人人人人_ > 合流 <  ̄Y^Y^Y ̄ 150
193.
ブランチ master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ _人人人人_ > 合流 <  ̄Y^Y^Y ̄ココと 150
194.
ブランチ master(本流) _人人人人_ > 分岐 <  ̄Y^Y^Y ̄ _人人人人_ > 合流 <  ̄Y^Y^Y ̄ココと ココが同じ内容 になるなら 150
195.
ブランチ 151
196.
ブランチ こうしちゃえ! master(本流) 151
197.
はやおくり! Fast-Forward 152
198.
ちなみに マージと同時に新しくコミットを作りたい場合 こういう 表示にしたい 153
199.
154
200.
マージできた 155
201.
Next 156
202.
実際にやってみよう ページレイアウト変える 157
203.
プランAとプランB プランA このまま全体がセンター寄りのレイアウト プランB 文字は左寄せで中のコンテンツが真ん中寄り どっちがいいかな 158
204.
ブランチを生やす centering-style このまま全体がセンター寄りのレイアウト left-justify-style 文字は左寄せで中のコンテンツが真ん中寄り 159
205.
160
206.
ブランチを切りかえて ファイルを変更していく 161
207.
centering-style 162
208.
body { text-align: center; margin:
10px auto; display: table; } nav { background: #e0e0e0; } nav ul { padding: 0; } nav ul a li { list-style: none; } article { margin-top: 1em; padding: 0 1em; border: 1px solid #e0e0e0; } section ul { text-align: left; } コピペ用 163
209.
164
210.
165
211.
166
212.
167
213.
centering-style 168
214.
left-justify-style プランB 文字は左寄せで中のコンテンツが真ん中寄 り チェックアウトを忘れずに! ブランチ切った時点の 状態に戻った! 169
215.
left-justify-style 170
216.
nav { background: #e0e0e0; } nav
ul { padding: 10px 20px; } nav ul a li { list-style: none; } article { margin-top: 10px; padding: 10px; border: 1px solid #e0e0e0; } コピペ用 171
217.
172
218.
173
219.
174
220.
left-justify-style 175
221.
left-justify-style 176
222.
枝っぽくなった 177
223.
centering-style ブランチにきりかえて index.htmlをみてみる 178
224.
centering-styleだ! 179
225.
_人人人人人_ > すごい <  ̄Y^Y^Y^Y ̄ 180
226.
こんなに簡単に出来たら 安心してファイルの変更ができる ファイル変更によって何か問題が起こっても、 その問題が起きる前の状態にすぐ戻れる 試行錯誤しやすい 181
227.
NEXT 182
228.
masterにマージしよう よし!これでOKとなったら本流に取り込みたい 全部センター寄りの方が統一性あるのでは? 今回はプランAを採用したい centering-styleをマージする! 183
229.
master 184
230.
master 184
231.
centering-style master 184
232.
centering-style _人人人人人_ > マージ <  ̄Y^Y^Y^Y ̄ master 184
233.
やってみよう 185
234.
masterに チェックアウト 186
235.
centering-styleを選択 選択 187
236.
マージできた 188
237.
NEXT 189
238.
ファイルの変更を なかったことにしたい (reset/リセット) 190
239.
世の中には 理不尽なこともあります 191
240.
いや、B案にするのだ 192
241.
_人人人人人人人_ > ファッ!? <  ̄Y^Y^Y^Y^Y^Y ̄ 193
242.
思い出してください 元に戻してって言われても戻せなかった 「元」がなんだったか覚えてない エディタ閉じちゃったらバックも使えない index_yyyymmdd.html index_old.html ファイルが多くてどれが本当か分からない 194
243.
Gitなら簡単に 戻せるんですよ! 195
244.
戻したい時点のコミットを選択 右クリック 選択 196
245.
モードをHardにする 197
246.
198
247.
199
248.
無視して進めましょう 200
249.
元に戻った! 201
250.
で、 202
251.
さっきのモードって何? 203
252.
ひとつひとつ やってみましょう (だってすぐ戻せるんだもん) 204
253.
もう一度マージ 205
254.
もう一度リセット 206
255.
モードをMixedにする 207
256.
あれっ 208
257.
ファイルを変更した状態に 209
258.
確認その1 210
259.
centering-styleブランチで 変更した内容は保持されるが 211
260.
確認その2 212
261.
インデックスをリセットする (addする前の状態にする) 213
262.
もうひとつやってみましょう (だってすぐ戻せるんだもん) 214
263.
その前に 215
264.
変更をなかったことにする 216
265.
変更が破棄された reset(hard)した時と 同じ状態に! 217
266.
centering-styleを 再びマージ 218
267.
モードをsoftにしてリセット 219
268.
ファイルを変更した状態に 220
269.
確認 221
270.
centering-styleブランチで 変更した内容も保持されて 222
271.
ステージングした状態にする (addした後の状態にする) 223
272.
224
273.
つまり 225
274.
リセットのモード Soft ファイルを変更してaddした状態まで戻す mixed ファイルを変更してaddする前の状態まで戻す Hard ファイルを変更する前に戻す 226
275.
リセットのモード Soft ゆる〜いリセット Mixed そこそこゆる〜いリセット Hard つよいリセット 迷ったらSoftに しておけば安全 227
276.
228
277.
229
278.
改めて left-justify-style ブランチをマージ 230
279.
tips 231
280.
マージ時は常に新しい コミットを作る いちいち毎回チェック入れるの面倒 SourceTree > 環境設定から設定 これ 232
281.
マージ時は常に新しい コミットを作る 233
282.
left-justify-styleを選択 最初から 選択されている 234
283.
マージできた 235
284.
思い出してください 元に戻してって言われても戻せなかった 「元」がなんだったか覚えてない エディタ閉じちゃったらバックも使えない index_yyyymmdd.html index_old.html ファイルが多くてどれが本当か分からない 236
285.
思い出してください2 バージョン管理システムの特徴 安心してファイルの変更ができる 前のバージョンに戻せる 特にGitは 手軽にバージョンの切り替えができる 237
286.
_人人人人人人人人人_ > 気軽にやり直せる <  ̄Y^Y^Y^YY^Y^Y^Y ̄ 238
287.
直前のコミットを やり直したい (上書きしたい) 239
288.
headerのスタイル変更 目立たせたい 濃いめの背景(#000000) テキストの色を白にしたい(#FFFFFF) トップページへのリンクも付けたい ブランチ名:change-header-style 240
289.
241
290.
242
291.
243
292.
やっぱり真っ黒って イケてない 243
293.
やっぱり真っ黒って イケてない それだけのために新し いコミット作るのも 243
294.
244
295.
245
296.
246
297.
上書きできた 247
298.
こんな時につかおう コミットした後にtypo(タイピングミス)を 見つけてしまった コミットした後に変換ミスを見つけてしまった わざわざ新しいコミットを作るまでもない時に → 直前のコミットしか上書きできないので注意! (この方法では) 248
299.
ヘッダ変更の続き 249
300.
この辺の 余白いらない 250
301.
251
302.
252
303.
253
304.
変更できたので マージする 254
305.
右クリックからでも マージできる 255
306.
右クリックからでも マージできる 256
307.
右クリックからでも マージできた! 257
308.
総合れんしゅう ※あくまで操作に慣れるためで 課題については特に意味ないです 258
309.
1. リポジトリを作成 「my_profile」というリポジトリを作成 「yourname.md」(自分の名前)というファイルを 作成 一行目に「# 自己紹介」と記述 add、コミットしてください 259
310.
2. 基礎情報を追記 「yourname.md」を編集 ## 基礎情報 +
名前:あなたの名前 + 誕生日:YYYY年M月D日 + 出身: + 血液型: 作業は「add-basic-info」ブランチを作成してから 260
311.
3. add-basic-infoをマージ 「add-basic-info」ブランチをmasterにマージ マージ時には新しいコミットを作成するように 261
312.
4. 自分の好きなものを追記する ブランチは「add-favorite-things」 ## 好きな食べ物 +
寿司 + カニ ## 好きなお酒 + ビール + 日本酒 262
313.
5. add-favorite-thingsを masterにマージ マージ時には新しいコミットを作成するように 263
314.
6. 自分の嫌いなものを追記する ブランチは「add-unfavorite-things」 嫌いな食べ物 嫌いな生き物 嫌いな季節 264
315.
7. 自分の嫌いなものを編集する 「嫌いな食べ物」「嫌いな生き物」「嫌いな季節」 とコミットしたけれど、動物愛護団体に怒られる のは嫌なので「嫌いな生き物」の記述を削除 (だけど「嫌いな季節」はのこしたい) ヒント 「嫌いな食べ物」をコミットした時点までの歴史 を取り消して、「嫌いな季節」の部分だけコミッ トしなおす 265
316.
8. add-unfavorite-thingsを masterにマージ マージ時には新しいコミットを作成するように 266
317.
9.自分の経歴を追加 「yourname.md」を編集 ## 経歴 + 幼稚園:なんちゃら幼稚園 +
小学校:なんちゃら小学校 + 中学校:なんちゃら中学校 作業は「add-my-career」ブランチを作成してか ら 267
318.
10.自分の経歴の詳細を追加 あっ、せっかくなので一言二言追加したい! 新たに「add-detail-my-career」ブランチを作成 してから作業する ## 経歴 + 幼稚園:なんちゃら幼稚園 +
結構活発だった気がする 268
319.
11. add-detail-my-career ブランチをマージ 「add-detail-my-career」ブランチを 「add-my-career」ブランチにマージ 269
320.
add-my-career master add-detail- my-career こんなイメージ 270
321.
12. 再び自分の経歴を追加 高校と大学の項目をそれぞれ追加 今度は詳細も同時に追加していくスタイルで 追加できたらmasterにマージする 新たにこみt(ry 271
322.
こわくないGit 神スライド 本当は怖くない!デザイナーがGitを大好きになっ た5つの理由 絵がかわいい、例がわかりやすい LearnGitBranching 触りながら学べるけど日本語訳わかりづらい 学習のすすめ 272
323.
おまけ 用語集的なもの 273
324.
リポジトリ ファイルを管理するプロジェクトの単位 .gitがあるディレクトリ=gitのリポジトリ 参考スライド 274
325.
add(ステージング) コミットする前に必要な動作 ファイルの変更をした後、コミットしたい部分を 選ぶこと 参考スライド 基礎 行単位でadd commitとの関係 275
326.
commit(コミット) 実際にファイルの変更を記録する動作 commitする前にaddしないと何も記録できない 参考スライド 基礎 addとの関係 276
327.
branch(ブランチ) ある一連のコミットの連なりを、ほかと区別する ために設定するもの リポジトリを新規作成してコミットすると、 masterというブランチが作られる 一般的に、作業ベースでブランチを作ってmaster に統合させる作業フローが多い 参考スライド 277
328.
checkout(チェックアウト) あるコミット(時点)へ移動する操作 リポジトリ内はその時点の状態に変化する 参考スライド 278
329.
merge(マージ) branchどうしを統合させる動作 新たにコミットを作るマージと、 早送りマージがある 参考スライド 基礎 早送りマージ 279
330.
reset(リセット) 変更(コミット)を取り消す操作 Soft, Mixed, Hard
の3つのモードがある 参考スライド 基礎 リセットのモード 280
Télécharger maintenant