SlideShare ist ein Scribd-Unternehmen logo
1 von 186
Downloaden Sie, um offline zu lesen
こわくない



Presented by Kota Saito @ksaito
こんな人が対象者
一応ブラン チ作ってコミットしてるけど
実は、マー ジとかよくわかってない……

   エラーが出た時に対処できない……

 rebase しちゃダ
             メって何でな   の?
Git よくわかんない!

  怖い!!
\怖くないよ/
#1 コミットとブランチ

#2 二種類のマージ

#3 リベースの功罪
コミットとブランチ
そもそも、コミットって
なんだっけ……?
コミットに入ってる情報
 リビジョン (SHA-1 ハッシュ)
 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db

 Author (コミットを作成した人)
 例: オープンソースプロジェクトにパッチを送った人

 Committer (コミットを適用した人)
 例: 受け取ったパッチを取り込んだ人

 ファイルのスナップショット (tree)
 コミットで変更されたファイルを含むツリー(説明は省略)

 1つ前のコミットのリビジョン
 例: 4717e3cf182610e9e82940ac45abb0d422a76d77
コミットに入ってる情報
 リビジョン (SHA-1 ハッシュ)
 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db

 Author (コミットを作成した人)
 例: オープンソースプロジェクトにパッチを送った人

 Committer (コミットを適用した人)
                  これ重要!!
 例: 受け取ったパッチを取り込んだ人

 ファイルのスナップショット (tree)
 コミットで変更されたファイルを含むツリー(説明は省略)

 1つ前のコミットのリビジョン
 例: 4717e3cf182610e9e82940ac45abb0d422a76d77
コミット   A   があれば
コミット   A   があれば


その前の   B   をたどれる
A

B

C
こわくない Git
最新のコミット




    たどれる!!



最古のコミット
この概念=
コミットグラフ


 \テストに出るぞ/
で、ブランチって
なんだっけ……?
new
      例えば master に
      コミットが4回されたあとの
      こんなコミットグラフ


old
new   =   master   イマココ!!




old
new

      さらに master にもう1回
      コミットがされると…



old
new!   =   master   イマココ!!




old
つまり

      =

ブランチは最新コミットの別名!!
ブランチ名の代わりに
リビジョンを指定したり
git checkout -b foo master


                     =
git checkout -b foo 4717e3cf1826
リビジョンの代わりに
ブランチ名を指定したり
 git show 4717e3cf1826
           =
 git show master
できる!!
あれ? 枝分かれする
ブランチの話は?


てか、masterって
ブランチだったのか
git branch topic master
git branch    topic   master



master   から   topic   を作る
例えば master に
new   コミットが3回されたあとの
      こんなコミットグラフ


old
new   =   master   イマココ!!




old
git branch      topic   master

             してみると……

new      =   master




old
!?
new   =   master   =   topic




old
つまり

   =     =

   ブランチを作る=
コミットのさらなる別名を作る
枝分かれしてなくね?
スルーですか?
この状態から            topic     に
      コミットしてみると……

new    =   master   =     topic




old
new!       =        topic   伸びた!!

       =   master




old
master       にコミットしてみると…

new!                =       topic


               =   master




old
new!   =   master


           =        topic



                    枝分かれ!!


old
Point
初めてコミットした時点で
枝分かれになります。
コミットとブランチ
・コミットには「1つ前のコミット」が
 含まれるので、最古までたどっていける
 → コミットグラフ

・ブランチは、そのブランチでの
 最新のコミットの別名に過ぎない

・枝分かれは、それぞれのブランチで
 コミットされて初めて発生する
二種類のマージ
Question
gitのマージには
 2種類ある事
知ってましたか?
Fast-Forward
       and
Non Fast-Forward
Fast-Forward = 早送り
?
例えばこんなコミットグラフ

    =        topic




=   master
topic ブランチに
3回コミットした

    3   =        topic

 2

    1

=       master
git merge topic

    3   =        topic

2

    1
                         マージ!!
=       master
git merge topic

    3   =        topic

2

    1
                         マージ!!
                         グラフはどうなる?
=       master
3   =   topic   =   master

2

1


                    !?
3   =        topic

2

    1

=       master
                         ←これが
3   =   topic   =   master

2       ここに↑
1       移動しただけ
Why?
topic    =   master   +   1   +   2   +   3




master
topic    =       master   +   1   +   2   +   3

                                  マージ!!
master   +   1    +   2   +   3   =       ?
topic    =       master   +   1   +   2   +   3




master   +   1    +   2   +   3   =       topic
topic   =   master     +   1   +   2   +   3




マージ後の                master    =       topic
中の人「どうせ同じ内容になるなら
いちいちマージしなくてよくね?」
中の人「マージ後に topic と同じ内容になるなら
  topic のところまで進めちゃおうぜww」


         3   =        topic   =   master

      2

         1                    進める

     =       master
これが Fast-Forward
Fast-Forward

マージのかわりに早送り。
\ドヤァ…/
Non Fast-Forward
さっきのコミットグラフから
    にコミットすると…
master



    =        topic




=   master
=   master


    =        topic


               枝分かれ!!
マージ後の   master   ≠   topic
中の人「早送りできない><」
中の人「ちゃんとマージするかー」
git merge topic
=       master


    3   =        topic

    2

    1
                         マージ!!
〜中の人計算中〜

「えーと master の内容と
 topic のコミットを比較して…」
         「衝突してたら教えてあげなきゃ…」
master   +   1   +   2   +   3




中の人「全部まぜちゃえー」
master   +   1   +   2   +   3   =   M




中の人「マージ結果ができたよ!」
=       master


    3   =        topic

    2
                         M
    1
                    中の人「そぉい!!」
M   =       master           <スポッ




        3   =        topic

        2

        1
M   =       master           ←マージの結果
                              作られたコミット


        3   =        topic

        2

        1
M   =       master           ←マージの結果
                              作られたコミット
                       マージコミット
        3   =        topic

        2

        1

                     \テストに出るぞ/
Non Fast-Forward
Non Fast-Forward

早送りじゃないマージ。
\ドヤヤヤァ…/
ちなみに
git merge topic
Fast-Forward                      Non Fast-Forward

早送りできればする、無理なら普通のマージ


git merge --no-ff topic
               Non Fast-Forward

常に普通のマージ


git merge --ff-only topic
        Fast-Forward

常に早送りする(できなければエラーとする)
ところが
議論がある
常に git merge --no-ff すべきだ!


 訳: 早送りマージすんな!
\えっ/
Why?
3   =   topic   =   master

2

1
        早送りした後の状態から
             を消すと…
          topic
3   =   master

2

1
                 ん?
3   =   master

2

1
                 あれ?
=   master




     直接コミットしたのと
     変わらない!!
\    の霊圧が消えた…!?/
  topic


  =   master
Fast-Forward の弊害①

「ブランチをマージした」という事実が
 歴史(コミットグラフ)に残らない
=   master




     おっと、間違って
     マージしちゃった (>ω・)
=   master




     えーと、マージを
     元に戻すにはっと…
git revert <commit>
<commit> (リビジョン) のコミットを
取り消すためのコミットを作る


git reset --hard <commit>
<commit> (リビジョン) 時点の状態まで
完全に巻き戻す
=   master




    おkおk
    コミットを指定すればいいのか
=   master




    で、どれが topic の
    コミットだっけ……
Fast-Forward の弊害②

  「ブランチのマージ」を
    取り消しづらい
Point
マージの種類を意識して
マージしましょう!
二種類のマージ
・Fast-Forward = 早送り
 ・コミットグラフ的に結果が同じなら
  同じコミットまで進めてしまうこと
 ・「マージした」という記録が残らない
 ・マージを取り消しづらい

・Non Fast-Forward = 普通のマージ
 ・Git ががんばって計算するマージ
リベースの功罪
git 初心者が陥りがちな罠

    第1位
     (個人的に)
リベーーーーーース

git rebase
ブランチ を master に追従するときに
使ってま す!! マージはなんか怖いし…


   rebase すると、コミットログが
   キレイになって見やすいよね!!


 merge よりも
           rebase の方が
 マージコミット
           もなくて楽でし
                      ょ?
Question
そもそも rebase が
 なにをするのか
理解していますか?
2   =       master


1

        2   =        topic


        1
                              topic
                      この状態から     で
                      git rebase master すると…
topic

   2      2
   1      1

まず、コミットの変更内容を
それぞれパッチにする
2   =       master     =     topic


1                             移動
        2   =        topic


        1        次に topic を master と
                 同じコミットに移動させる
                 (元々の topic ブランチでの
                  変更は含まなくなる)
ここまで来たら、作っておいた
    パッチを1つずつ順に適用して
    コミットしていく


2   =   master   =    topic


1

                       1  2
                     (  と  は省略)
差分を適用してコミット              1



2   =   master   =   topic


1
A   ←    1 から作られたコミット

2   =   master   =   topic


1
A   =    topic


2   =   master


1
2


    A   =    topic


2   =   master


1
B   ←    2 から作られたコミット

    A   =    topic


2   =   master


1
B   =    topic


    A

2   =   master


1
重要
   2        B

   1
       ≠    A

rebase で作られたコミットは
元のコミットと同じ内容だけど
別のコミットになります!!
重要
   2        B

   1
       ≠    A
                本当?
rebase で作られたコミットは
元のコミットと同じ内容だけど
別のコミットになります!!
コミットに入ってる情報
 リビジョン (SHA-1 ハッシュ)
 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db

 Author (コミットを作成した人)
 例: オープンソースプロジェクトにパッチを送った人

 Committer (コミットを適用した人)
 例: 受け取ったパッチを取り込んだ人

 ファイルのスナップショット (tree)
 コミットで変更されたファイルを含むツリー(説明は省略)

 1つ前のコミットのリビジョン
 例: 4717e3cf182610e9e82940ac45abb0d422a76d77
コミットに入ってる情報
 リビジョン (SHA-1 ハッシュ)
 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db

 Author (コミットを作成した人)
 例: オープンソースプロジェクトにパッチを送った人

 Committer (コミットを適用した人)
 例: 受け取ったパッチを取り込んだ人

 ファイルのスナップショット (tree)
 コミットで変更されたファイルを含むツリー(説明は省略)

 1つ前のコミットのリビジョン
 例: 4717e3cf182610e9e82940ac45abb0d422a76d77
2    B

   1    A

        2


1つ前のコミットが違う!!
2      B

  1      A

         2

1つ前のコミットが変わると
 リビジョンも変わります
  (だから別物になる)
Point
rebaseで作られるコミットは
 元のコミットとは別物
別物でも、同じ変更が
されるから問題ない気が
git push origin topic
git push origin           topic



  topic   を origin (サーバー) に同期
local              origin

2   =   topic

                push
1
local       origin

2   =   topic   2   =   topic

1               1
local        origin
3   =    topic


2       commit   2   =   topic

1                1
local              origin
3   =   topic

                push
2                      2   =   topic

1                      1
origin「お、pushがきたぞ?
どれどれ、内容を見てみよう」
origin「新しいコミットは1つだけか」


          3



「さて、こいつの前のコミットは…」
3

         2

origin「お、2番なら知ってるぞ!」
local       origin
3   =   topic


2               2   =   topic

1               1
local       origin
3   =   topic   3   =    topic


2               2       よし、2番の
                        後ろに追加
1               1
local       origin
3   =   topic   3   =   topic


2               2

1               1
push after rebase
local       origin

2   =   topic   2   =   topic

1               1

0               0
local        origin

B   =    topic   2   =   topic

A       rebase   1

0                0
local              origin

B   =   topic          2   =   topic

                push
A                      1

0                      0
origin「お、pushがきたぞ?
どれどれ、内容を見てみよう」
origin「新しいコミットは2つか」

         B

         A


「さて、こいつの前のコミットは…」
B

       A

       0

origin「あれ? 0番か…」
B      2

     A      1

     0      0

origin「もう0番には次のコミットが
あるし、1とAはリビジョンも違う!!」
local       origin
                      ダメダメ!!
                    受け付けないよ!!
B   =   topic   2   =   topic

A               1

0               0
Point
push されているブランチを
   rebase すると
  push できなくなる
Point

よって、共有のブランチでは
rebase してはいけない !!
push -f ダメ! 絶対!!

  push -f で強制的に上書き push できますが
他の人が pull する時にマージする必要があったり
コミットログがおかしな事になるのでやめましょう
ブ ランチを master に追従するときに
使ってます !! マージはなんか怖いし…
\怖くないよ/
こわくない Git
M   git merge master
M
M   git merge master



M
M



M
M       git merge topic


    M



    M
M


    M

          と  で衝突する修正を

    M   しない限り、マージ時には
        一切コンフリクトしません!
Point

git のマージは
相当かしこい
rebase すると、コミットログが
キレイになって見やすいよね!!
M


    M


        この一連の流れを
    M   もし rebase でやっていると
確かに一直線でキレイ
お気づきだろうか…
ヒソヒソ…
(なあ、もしかして
 俺たち忘れられてないか?)
        M   M   M
マージの記録は残らない
えっ

M   M    M
Point
rebase でコミットグラフは
 一直線にキレイになるが
その陰で失われる情報がある
Point
  そもそも git で
入り組んだグラフになっても
そんなに気にすることはない
merge よりも
          rebase の方が
マージコミット
          もなくて楽でし
                     ょ?
ここから git rebase master すると…



                    ←a.txtの1行目を修正

a.txtの1行目を修正→
                    ←a.txtの1行目を修正
コミットがそれぞれパッチになって…



                2

a.txtの1行目を修正→
                1
1つ目のパッチを適用


     a.txtの1行目を修正するパッチ1つ目↓

                         1
a.txtの1行目を修正→
コンフリクト!


     a.txtの1行目を修正するパッチ1つ目↓

                         1
a.txtの1行目を修正→
コンフリクトを解消



                ←a.txtの1行目を修正

a.txtの1行目を修正→
2つ目のパッチを適用

     a.txtの1行目を修正するパッチ2つ目↓

                         2

                   ←a.txtの1行目を修正

a.txtの1行目を修正→
コンフリクト!


     a.txtの1行目を修正するパッチ2つ目↓

                          2

                    ←a.txtの1行目を修正

a.txtの1行目を修正→
コンフリクトを解消



                ←a.txtの1行目を修正


                ←a.txtの1行目を修正

a.txtの1行目を修正→
Point
   rebase だと
コミットそれぞれについて
コンフリクトの解消が必要
ちなみに git merge master だと…




                    ←a.txtの1行目を修正

a.txtの1行目を修正→
                    ←a.txtの1行目を修正
コンフリクトを解消


                M


                    ←a.txtの1行目を修正

a.txtの1行目を修正→
                    ←a.txtの1行目を修正
Point
   merge だと
コミットがいくつあろうと
コンフリクト解消は1回だけ
Point
   したがって
rebase よりもむしろ
merge の方が楽です
リベースの功罪
           Good
・コミットグラフがキレイになる
 → マージ後のログがキレイになるので
   master にマージする直前にやるのは
   OK とする事がある
 → GitHub などのオープンソースプロジェクトに
   プルリクエストを送る場合は
   rebase してから送るのがマナーとされている
リベースの功罪
          Bad
・push されたブランチをリベースすると
 push できなくなる

・「マージした」という事実は失われる

・マージに比べるとコンフリクト解消が面倒
すこしは git の
 理解の手助けに
なれたでしょうか?
\怖くないよ/
\ズッ友だょ……!!/
Have a Nice Git!
References
Pro Git book
http://git-scm.com/book/ja/

git merge or rebase, ff or no-ff - Togetter
http://togetter.com/li/407277

A successful Git branching model
http://nvie.com/posts/a-successful-git-
branching-model/

Más contenido relacionado

Was ist angesagt?

シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかAtsushi Nakada
 
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture世界一わかりやすいClean Architecture
世界一わかりやすいClean ArchitectureAtsushi Nakamura
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Akihiro Suda
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法についてYuji Otani
 
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルドBuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルドAkihiro Suda
 
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Etsuji Nakai
 
Pythonによる黒魔術入門
Pythonによる黒魔術入門Pythonによる黒魔術入門
Pythonによる黒魔術入門大樹 小倉
 
目grep入門 +解説
目grep入門 +解説目grep入門 +解説
目grep入門 +解説murachue
 
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?naoki koyama
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪Takuto Wada
 
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugフロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugItsuki Kuroda
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話Kumazaki Hiroki
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれKumazaki Hiroki
 
GoによるWebアプリ開発のキホン
GoによるWebアプリ開発のキホンGoによるWebアプリ開発のキホン
GoによるWebアプリ開発のキホンAkihiko Horiuchi
 
15分でわかるGit入門
15分でわかるGit入門15分でわかるGit入門
15分でわかるGit入門to_ueda
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)mosa siru
 
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣Masahiro Nishimi
 

Was ist angesagt? (20)

シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
 
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法について
 
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルドBuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
 
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門
 
Pythonによる黒魔術入門
Pythonによる黒魔術入門Pythonによる黒魔術入門
Pythonによる黒魔術入門
 
目grep入門 +解説
目grep入門 +解説目grep入門 +解説
目grep入門 +解説
 
Oss貢献超入門
Oss貢献超入門Oss貢献超入門
Oss貢献超入門
 
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪
 
TLS, HTTP/2演習
TLS, HTTP/2演習TLS, HTTP/2演習
TLS, HTTP/2演習
 
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugフロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
 
Docker Compose 徹底解説
Docker Compose 徹底解説Docker Compose 徹底解説
Docker Compose 徹底解説
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれ
 
GoによるWebアプリ開発のキホン
GoによるWebアプリ開発のキホンGoによるWebアプリ開発のキホン
GoによるWebアプリ開発のキホン
 
15分でわかるGit入門
15分でわかるGit入門15分でわかるGit入門
15分でわかるGit入門
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
 
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
 

Andere mochten auch

デザイナのためのGit入門
デザイナのためのGit入門デザイナのためのGit入門
デザイナのためのGit入門dsuke Takaoka
 
はじめようGit
はじめようGitはじめようGit
はじめようGittechscore
 
はじめてのGit forデザイナー&コーダー
はじめてのGit forデザイナー&コーダーはじめてのGit forデザイナー&コーダー
はじめてのGit forデザイナー&コーダーSaeko Yamamoto
 
Gitのよく使うコマンド
Gitのよく使うコマンドGitのよく使うコマンド
Gitのよく使うコマンドYUKI Kaoru
 
Java初心者がJava8のラムダ式をやってみた
Java初心者がJava8のラムダ式をやってみたJava初心者がJava8のラムダ式をやってみた
Java初心者がJava8のラムダ式をやってみたAya Ebata
 
社内Java8勉強会 ラムダ式とストリームAPI
社内Java8勉強会 ラムダ式とストリームAPI社内Java8勉強会 ラムダ式とストリームAPI
社内Java8勉強会 ラムダ式とストリームAPIAkihiro Ikezoe
 
一人でもはじめるGitでバージョン管理
一人でもはじめるGitでバージョン管理一人でもはじめるGitでバージョン管理
一人でもはじめるGitでバージョン管理Takafumi Yoshida
 
やりなおせる Git 入門
やりなおせる Git 入門やりなおせる Git 入門
やりなおせる Git 入門Tomohiko Himura
 
もしWordPressユーザーがGitを使ったら 〜WordPressテーマを共同編集しよう〜
もしWordPressユーザーがGitを使ったら 〜WordPressテーマを共同編集しよう〜もしWordPressユーザーがGitを使ったら 〜WordPressテーマを共同編集しよう〜
もしWordPressユーザーがGitを使ったら 〜WordPressテーマを共同編集しよう〜Takashi Uemura
 
Gitはじめの一歩
Gitはじめの一歩Gitはじめの一歩
Gitはじめの一歩Ayana Yokota
 
ノンプログラマでも今日から使える「Git」でバージョン管理
ノンプログラマでも今日から使える「Git」でバージョン管理ノンプログラマでも今日から使える「Git」でバージョン管理
ノンプログラマでも今日から使える「Git」でバージョン管理H2O Space. Co., Ltd.
 
Spring Bootの本当の理解ポイント #jjug
Spring Bootの本当の理解ポイント #jjugSpring Bootの本当の理解ポイント #jjug
Spring Bootの本当の理解ポイント #jjugMasatoshi Tada
 
今年の卒論はGithubで決まり!
今年の卒論はGithubで決まり!今年の卒論はGithubで決まり!
今年の卒論はGithubで決まり!From Atom
 
バージョン管理のワークフロー
バージョン管理のワークフローバージョン管理のワークフロー
バージョン管理のワークフローadd20
 
インフラエンジニアのこれまでとこれから
インフラエンジニアのこれまでとこれからインフラエンジニアのこれまでとこれから
インフラエンジニアのこれまでとこれからKumano Ryo
 
AbemaTV モバイルアプリの開発体制と開発プロセスの話
AbemaTV モバイルアプリの開発体制と開発プロセスの話AbemaTV モバイルアプリの開発体制と開発プロセスの話
AbemaTV モバイルアプリの開発体制と開発プロセスの話Yuji Hato
 
ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会
ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会
ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会Takayuki Shimizukawa
 
Git 入門
Git 入門Git 入門
Git 入門y-uti
 

Andere mochten auch (20)

デザイナのためのGit入門
デザイナのためのGit入門デザイナのためのGit入門
デザイナのためのGit入門
 
はじめようGit
はじめようGitはじめようGit
はじめようGit
 
はじめてのGit forデザイナー&コーダー
はじめてのGit forデザイナー&コーダーはじめてのGit forデザイナー&コーダー
はじめてのGit forデザイナー&コーダー
 
Gitのよく使うコマンド
Gitのよく使うコマンドGitのよく使うコマンド
Gitのよく使うコマンド
 
Java初心者がJava8のラムダ式をやってみた
Java初心者がJava8のラムダ式をやってみたJava初心者がJava8のラムダ式をやってみた
Java初心者がJava8のラムダ式をやってみた
 
社内Java8勉強会 ラムダ式とストリームAPI
社内Java8勉強会 ラムダ式とストリームAPI社内Java8勉強会 ラムダ式とストリームAPI
社内Java8勉強会 ラムダ式とストリームAPI
 
Lombok ハンズオン
Lombok ハンズオンLombok ハンズオン
Lombok ハンズオン
 
一人でもはじめるGitでバージョン管理
一人でもはじめるGitでバージョン管理一人でもはじめるGitでバージョン管理
一人でもはじめるGitでバージョン管理
 
やりなおせる Git 入門
やりなおせる Git 入門やりなおせる Git 入門
やりなおせる Git 入門
 
もしWordPressユーザーがGitを使ったら 〜WordPressテーマを共同編集しよう〜
もしWordPressユーザーがGitを使ったら 〜WordPressテーマを共同編集しよう〜もしWordPressユーザーがGitを使ったら 〜WordPressテーマを共同編集しよう〜
もしWordPressユーザーがGitを使ったら 〜WordPressテーマを共同編集しよう〜
 
Gitはじめの一歩
Gitはじめの一歩Gitはじめの一歩
Gitはじめの一歩
 
ノンプログラマでも今日から使える「Git」でバージョン管理
ノンプログラマでも今日から使える「Git」でバージョン管理ノンプログラマでも今日から使える「Git」でバージョン管理
ノンプログラマでも今日から使える「Git」でバージョン管理
 
Spring Bootの本当の理解ポイント #jjug
Spring Bootの本当の理解ポイント #jjugSpring Bootの本当の理解ポイント #jjug
Spring Bootの本当の理解ポイント #jjug
 
今年の卒論はGithubで決まり!
今年の卒論はGithubで決まり!今年の卒論はGithubで決まり!
今年の卒論はGithubで決まり!
 
バージョン管理のワークフロー
バージョン管理のワークフローバージョン管理のワークフロー
バージョン管理のワークフロー
 
Git紹介
Git紹介Git紹介
Git紹介
 
インフラエンジニアのこれまでとこれから
インフラエンジニアのこれまでとこれからインフラエンジニアのこれまでとこれから
インフラエンジニアのこれまでとこれから
 
AbemaTV モバイルアプリの開発体制と開発プロセスの話
AbemaTV モバイルアプリの開発体制と開発プロセスの話AbemaTV モバイルアプリの開発体制と開発プロセスの話
AbemaTV モバイルアプリの開発体制と開発プロセスの話
 
ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会
ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会
ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会
 
Git 入門
Git 入門Git 入門
Git 入門
 

Último

バイオリンの運弓動作計測による初心者と経験者の差異分析
バイオリンの運弓動作計測による初心者と経験者の差異分析バイオリンの運弓動作計測による初心者と経験者の差異分析
バイオリンの運弓動作計測による初心者と経験者の差異分析sugiuralab
 
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。iPride Co., Ltd.
 
チームで開発するための環境を整える
チームで開発するための環境を整えるチームで開発するための環境を整える
チームで開発するための環境を整えるonozaty
 
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdf
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdfIGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdf
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdfIGDA Japan SIG-Audio
 
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版Takayuki Nakayama
 
SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」
SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」
SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」IGDA Japan SIG-Audio
 
これからはじめるAnsible - Ansible Night Tokyo 2024
これからはじめるAnsible - Ansible Night Tokyo 2024これからはじめるAnsible - Ansible Night Tokyo 2024
これからはじめるAnsible - Ansible Night Tokyo 2024Hideki Saito
 
AWS Lambdaと AWS API Gatewayを使ったREST API作り
AWS Lambdaと AWS API Gatewayを使ったREST API作りAWS Lambdaと AWS API Gatewayを使ったREST API作り
AWS Lambdaと AWS API Gatewayを使ったREST API作りiPride Co., Ltd.
 
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~honeshabri
 
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜Naomi Yamasaki
 
The 86th National Convention of IPSJ (Student Encouragement Award))
The 86th National Convention of IPSJ (Student Encouragement Award))The 86th National Convention of IPSJ (Student Encouragement Award))
The 86th National Convention of IPSJ (Student Encouragement Award))yoshidakids7
 
00001_test_automation_portfolio_20240313
00001_test_automation_portfolio_2024031300001_test_automation_portfolio_20240313
00001_test_automation_portfolio_20240313ssuserf8ea02
 

Último (12)

バイオリンの運弓動作計測による初心者と経験者の差異分析
バイオリンの運弓動作計測による初心者と経験者の差異分析バイオリンの運弓動作計測による初心者と経験者の差異分析
バイオリンの運弓動作計測による初心者と経験者の差異分析
 
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。
 
チームで開発するための環境を整える
チームで開発するための環境を整えるチームで開発するための環境を整える
チームで開発するための環境を整える
 
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdf
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdfIGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdf
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdf
 
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版
 
SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」
SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」
SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」
 
これからはじめるAnsible - Ansible Night Tokyo 2024
これからはじめるAnsible - Ansible Night Tokyo 2024これからはじめるAnsible - Ansible Night Tokyo 2024
これからはじめるAnsible - Ansible Night Tokyo 2024
 
AWS Lambdaと AWS API Gatewayを使ったREST API作り
AWS Lambdaと AWS API Gatewayを使ったREST API作りAWS Lambdaと AWS API Gatewayを使ったREST API作り
AWS Lambdaと AWS API Gatewayを使ったREST API作り
 
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~
 
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜
 
The 86th National Convention of IPSJ (Student Encouragement Award))
The 86th National Convention of IPSJ (Student Encouragement Award))The 86th National Convention of IPSJ (Student Encouragement Award))
The 86th National Convention of IPSJ (Student Encouragement Award))
 
00001_test_automation_portfolio_20240313
00001_test_automation_portfolio_2024031300001_test_automation_portfolio_20240313
00001_test_automation_portfolio_20240313
 

こわくない Git