Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Cookpad Summer Internship 2019 Day 1 Git

Cookpad Summer Internship 2019 Day 1 Git

AKAMATSU Yuki

August 19, 2019
Tweet

More Decks by AKAMATSU Yuki

Other Decks in Programming

Transcript

  1. Git • 分散型のバージョン管理システム ◦ 他の分散型ではMercurialなど • 対して中央集権型のバージョン管理システムもある ◦ Subversionなど •

    Linuxの作者であるLinus TorvaldsがLinuxの開発のために作った • GitHubの存在もあり、ほぼデファクトと言ってもいい状態
  2. リポジトリの作成とファイルの追加 • リポジトリの作成 ◦ mkdir -p ~/works/git-handson ◦ cd ~/works/git-handson

    ◦ git init • ファイルを追加 ◦ echo “# README” > README.md ◦ git add README.md ◦ git commit -m “Add README.md”
  3. 3つのエリア • Working Directory ◦ ディスク上に配置されているファイル 郡がある場所 • Staging Area(.git/index)

    ◦ 次のコミットに含まれる情報が蓄えら れている場所 • Repository(.git/objects) ◦ リポジトリのデータベース ◦ メタデータやオブジェクトなどが格納さ れている
  4. fast forward • 雑に表現するとmerge時にmergeコミットを作るか、作らないか • --no-ff の場合、「必ず」mergeコミットを作る ◦ git log

    を叩いて、mergeコミットができることを確かめよう • --no-ffをつけない場合、Gitがfast forwardできるか判断する ◦ git reset --hard HEAD^ ◦ git merge new-feature ◦ git logを叩いて、mergeコミットができていないことを確かめよう
  5. ff or no-ff • 個人的にはno-ffの方がよく使う ◦ GitHubのPull Requestのmergeもno-ff • mergeコミットが存在していると、その機能の差し戻し(revert)がラク

    • ローカルでの開発でfeatureブランチから更に派生させたブランチをfeatureブラ ンチに手元でmergeする時に使う
  6. rebase • git checkout feature-branch • git rebase master •

    ブランチの派生元を変更するイメージ ◦ masterの変更をブランチに反映させる ときなどに使う • 親コミットが変わるため、コミットのリビジョン が変わることに注意
  7. rebase vs merge • masterの変更を反映させるならmergeする方法もある • rebase ◦ ツリーがまっすぐキレイになる ◦

    fast forwardでmergeできるようになる ◦ リビジョンが変わるため、リモートにforce pushするしかなくなる • merge ◦ コンフリクト解消がrebaseよりラク ◦ mergeコミットが多いと、履歴が順に読みづらくなる • コンフリクトが少ない & 人とブランチを共有していない状態ならrebase ◦ とは言え、結構どちらでもいいと思っています(個人の意見)
  8. GitHub • 開発に多数の人間が関わる場合、リポジトリの管理や変更の取り込みの管理 などが大変 • GitHubを使うことで管理の手間を減らす • GitHub = ソースコードホスティングと表現されることもあるが、どちらかというと

    開発のやり取りをする場 • オマケ: クックパッドではGitHub Enterpriseを使用 ◦ GitHubとは若干の違いがあったりします(新しい機能がまだ使えないとか)
  9. Pull Requestを送ってみよう • https://ghe.ckpd.co/yuki-akamatsu/2019-summer-intern-git をfork • cd ~/works • git

    clone https://ghe.ckpd.co/[your-name]/2019-summer-intern-git • cd 2019-summer-intern-git • git branch add-my-readme • git checkout add-my-readme • vim [your-name].md ◦ 今回のインターンの意気込みを書こう • git add [your-name].md • git commit -m “Add [your-name].md” • git push origin add-my-readme • GHEからPull Requestを送ろう
  10. コミットメッセージ • 「fix」というメッセージのコミットが一杯並んでいてもなにもわからない • コミットメッセージのタイトルには概要を簡潔に書く ◦ 「Use foo method instead

    of bar method that deprecated」 • コミットメッセージの本文には「なぜ」を書くことを意識する ◦ 実際にどうやっているかはコードを読めばわかる ◦ 「なぜ」はコードを読んでもわからない ◦ タイトルで説明が済んでいれば本文はなくても良い
  11. Pull Request • Pull Requestもコミット同様に大切 • Pull Requestも大きいより小さい方が良い ◦ レビュアーの負担が減る

    ◦ フォーマットの変更、リファクタリングなどは別に先に出す • Pull Requestのdescriptionを丁寧に ◦ Pull Requestの目的をちゃんと伝える ◦ Pull Requestを見る人が背景の事情を知っているとは限らない ◦ 画面の変更が入る場合、before / after のスクリーンショットを貼るなどす る