Windows10でGitを導入しようと思ったら色々と躓いたため備忘録として残します。 環境 Windows10 1.Gitのインストール 下のリンクを開きGit for Windowsをダウンロードします。 ダウンロードしたexeファイルを開きインストーラを起動してください。 ライセンス内容をしっかり読み「Next」をクリックしてください。 インストール先のディレクトリを指定します。 通常は変更しなくても大丈夫です。 インストールするコンポーネントを選択します。 Additional Icons → デスクトップにアイコンを作成 Windows Explorer Integration → エクスプローラーのコンテキストメニューにGit関連のものを追加 Git LFS (Large File Support) → Git LFSをインストール（Git LFSは動画ファイルやグラフィックデータなどの大容量バイナリファイルをGitのリポジトリで効率的に扱うための拡張機能） Associate .git* configuration files with the default text editor → Git関係のファイルをGitの標準エディターで関連付け Associate .sh files to be run with Bash → 拡張子が.shのファイルをGit Bashで関連付け Use a TrueType font in all console windows → 全てのコンソールにTrueTypeフォントを使用（日本語が文字化けしたりするのでチェックしない方がいい） Check daily for Git for Windows updates → Git for Windowsに更新が来てないか毎日確認する スタートメニューに追加するか設定します。 追加したくない場合「Don't create a Start Menu folder」にチェックを入れてください。 Gitの標準エディターを選択します。 Use the Nano editor by default → Nanoを使用 Use Vim (the ubiquitous text editor) as Git's default editor → Vimを使用 Use Notepad++ as Git's default editor → Notepad++を使用 Use Visual Studio Code as Git's default editor → VSCodeを使用 Use Visual Studio Code Insiders as Git's default editor → VSCode Insidersを使用 Use Sublime Text as Git's default editor → Sublime Textを使用 Use Atom as Git's default editor → Atomを使用 Use VSCodium as Git's default editor → VSCodiumを使用 Use Notepad as Git's default editor → メモ帳を使用 Use Wordpad as Git's default editor → ワードパッドを使用 Select Other editor as Git’s default Editor → その他のエディターを選択する エディターはNanoとVimを除いてGitをインストールする前から予めインストールしていないと先に進めません。（NanoとVimはGitのインストール時に付属される） また、注意書きとしてVimは互換性などの歴史的背景からGit for Windowsが選ばれているため基本的にキーバインドが直感的で分かりやすい最新のGUIエディターに切り替えることを強く推奨しますと書かれています。 git initで使用されるデフォルトのブランチ名を選択します。 Let Git decide → 今まで通りのmasterが使用される Overrride the default branch name for new repositories → その他の指定した名前が使用される（mainなど） 環境変数の設定をします。 Use Git from Git Bash only → PATHを通さない Git from the command line and also from 3rd-party software → Gitのコマンドだけコマンドプロンプトなどでも使用できるようにPATHを通す Use Git and included Unix tools from the Windows Command Prompt → Unix系のコマンドが全てコマンドプロンプトなどで使用できるようにPATHを通す（findやsortといったUnix系にもWindowsにもあるコマンドはUnix系の方に上書きされる） SSLライブラリの選択をします。 Use the OpenSSL library → OpenSSLを使用 Use the native Windows Secure Channel library → Windows標準の証明書ストアを使用 改行コードの設定をします。 Checkout Windows-style, commit Unix-style line endings → チェックアウト時に改行コードがCR-LFに、コミット時にLFに変換される Checkout as-is, commit Unix-style line endings → チェックアウト時には改行コードは変換されず、コミット時にLFに変換される Checkout as-is, commit as-is → 改行コードは変換されない ターミナルの設定をします。 Use MinTTY(the default terminal of MSYS2) → MinTTYを使用 Use Windows' default console window → Windows標準のコンソールを使用 git pull時の動作を設定します。 Default(fast-forward or merge) Rebase Only ever fast-forard 資格情報マネージャーの設定をします。 Git Credential Manager Core → 新しいバージョンのCredential Manager Git Credential Manager → 従来のバージョンのCredential Manager（非推奨） None → 資格情報マネージャーを使用しない その他のオプションの設定をします。 Enable file system caching → キャッシュを有効化 Enable symbolic links → シンボリックリンクを有効化 Enable experimental support for pseudo consoles. → NodeやPythonなどが実行できるようになる（試験的な機能で既知のバグが存在する） 以上の手順が終了するとGit Bashなどがインストールされ使用できるようになります。 2.Gitの初期設定 早速インストールしたGit Bashを起動してみましょう。 Git Bashが起動したらコマンドを使ってユーザー名とメアドを登録してください。 Git Bash git config --global user.name "ユーザー名" git config --global user.email "メールアドレス" ユーザー名とメールアドレスはGitを使用するときに使用する自分のユーザー名とメールアドレスに書き換えて上記のコードを実行してください。 Git Bash git config user.name git config user.email ちゃんと設定できていれば上記のコードで先程登録したユーザー名とメールアドレスが表示されます。 3.GitHubでサインアップ 下のリンクからサインアップをしてください。 最終的に下の画像のような画面に到達したらサインアップ完了です。 4.GitHubでリポジトリを作成 「New」をクリックしてリモートリポジトリを作成します。 リポジトリ名を入力して「Private」を選択してから「Create repository」をクリックしてください。 5.HTTPS接続でpush リモートリポジトリを作成したあとに表示されるURLをコピーしてください。 そうしたらGit Bashを起動して以下のコマンドを実行します。 Git Bash git clone さっきコピーしたURL おそらく上の画像のような画面が出てくるので「Sign in with your browser」をクリックしてGitHubにサインインしてください。（個人アクセストークンと使用する方法もあるが今回は割愛） git cloneが完了したらREADME.mdを作成します。 Git Bash touch README.md その後README.mdの変更をステージして… Git Bash git add README.md コミットして… Git Bash git commit -m "first commit" プッシュします。 Git Bash git push -u origin master リモートリポジトリにREADME.mdを追加できました。 6.SSH接続でpush 速いのはHTTPS接続だしGitHubの推奨もHTTPS接続ですが基本的にはSSH接続の方がセキュアと言われているしできるようにしても損はないと思います。 まずSSH Keysを作っていきましょう。 以下のテキストを貼り付けます。メールアドレスは自分のGitHubのメールアドレスに書き換えて実行してください。 Git Bash ssh-keygen -t ed25519 -C "メールアドレス" 下の様なメッセージが出てきます。 ここでSSH Keysを保存するディレクトリを指定できます。 デフォルトのままでいい場合このままEnterキーを押してください。 Git Bash Enter a file in which to save the key (/c/Users/you/.ssh/id_ed25519): そうすると更に下の様なメッセージが出てきます。 ここでパスフレーズを設定できます。 一応空にすることもできますが安全なパスフレーズを入力することをおすすめします。 パスフレーズの作成方法（一例） 1.EFF Large Wordlistにアクセスする。 2.PowerShellで以下のコマンドを実行。 PowerShell (1..5 | ForEach-Object{ Get-Random -Minimum 1 -Maximum 6 }) -Join "" 3.返ってきた数字と隣接したEFF Large Wordlistにある単語をメモしておく。 4.2～3の手順を5回ほど繰り返す。 5.そのメモしておいた単語をくっつけてパスフレーズとして登録。 Git Bash Enter passphrase (empty for no passphrase): 下の様なメッセージが出てきたら再度先程入力したパスフレーズを入力してください。 Git Bash Enter same passphrase again: SSH Keysを作成し終えたら公開鍵の中身をコピーしましょう。 Git Bash clip < ~/.ssh/id_ed25519.pub コピーし終えたらGitHubに作ったSSH Keysを登録しましょう。 GitHubの設定のSSHの欄にアクセスして「New SSH key」をクリックします。 「Title」には適当な鍵の名前を「Key」には先程コピーした公開鍵を入力します。 登録し終えたらSSHが正しくGitHubで登録されたかを確認しましょう。 Git Bash ssh -T git@github.com 下のような警告が表示されたりするのでRSA key fingerprint isから先の部分がGitHub の RSA パブリックキーのフィンガープリントに一致していたらyesと入力する。 Git Bash The authenticity of host 'github.com (IP ADDRESS)' can't be established. RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8. Are you sure you want to continue connecting (yes/no)? パスフレーズを設定していた場合更にパスフレーズも入力しなければなりません。 Git Bash Enter passphrase for key '/c/Users/you/.ssh/id_ed25519': 成功すると Git Bash Hi username! You've successfully authenticated, but GitHub does not provide shell access. と出てきます。 そしたらステップ4で作成したリモートリポジトリに再度アクセスして 「Code」をクリックしてSSHを選択して表示されるURLをコピーしてください。 Git Bash git remote set-url origin さっきコピーしたURL README.mdに「Hello World」と書き込みます。 Git Bash echo Hello World > README.md その後README.mdの変更をステージしてコミットしてプッシュします。 Git Bash git add README.md git commit -m "Update README.md" git push SSH接続でリモートリポジトリのREADME.mdを更新できました。 7.ssh-agentを使用 HTTPS接続の場合設定せずとも自動でパスワードを覚えてくれる（Git Credential Manager Coreのおかげ）のですが、SSHの場合覚えてくれません。 そこでssh-agentを使用することでSSH接続時に毎回パスワード（正確にはパスフレーズ）が聞かれるのを回避することができます。 まずssh-agentを有効化します。 下のコマンドを管理者権限で実行しましょう。 PowerShell（管理者権限） Set-Service -Name ssh-agent -StartupType Automatic -Status Running 次に秘密鍵の登録をしましょう。 こちらもPowerShellから行ってください。（Git Bashで行うとGit Bash用のSSHが使われるので注意） PowerShell ssh-add .\.ssh\id_ed25519 下の様なメッセージが出てきたら設定したパスフレーズを入力してください。 PowerShell Enter passphrase for C:\Users\you\.ssh\id_ed25519: 最後にGitが使用するSSHをWindows標準のに変えましょう。 Git Bash git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe" ついでにGit BashのSSHもWindows標準のものに変えましょう。（上のままでもPowerShellでssh関連のコマンドを使用したりGit Bashでgit push行ったりする分には問題にならないのですが一応Git Bashでssh関連のコマンドを使いたいときもあるかもしれないので念の為載せておきます） Git Bash echo alias ssh=C:/Windows/System32/OpenSSH/ssh.exe >> .bash_profile これでSSH接続でもパスフレーズの入力が省略できるようになります。 そしてこれで導入手順が全て終了しました。 お疲れ様でした。

　git flow とは 　git flow は、チームで Git を使う際に役立つ、運用ルールをまとめたツールです。Git は分散型バージョン管理システムで、複数名でプロジェクト・ファイルを共有できる特徴があります。開発スピードの向上やミスの低減などメリットがある一方で、開発スタート時に運用ルールを定めておかないと、プロジェクトがまとまらない、というデメリットがあります。そんな Git の課題を git flow は解決してくれます。ちなみに git flow は、2009年にオランダ人ソフトウェア・エンジニアの ヴィンセントさんが発案した Git の運用ルールになります。 　git flow の内容 　master 　本番に反映するファイルで、基本的にこちらにはコミットしません 　develop 　開発を行うブランチになります。この2つの柱（ブランチ）は消滅することなくプロジェクトと共に存続します。 　feature branches 　追加機能などはこちらで作業されます。develop から分岐し、 develop にマージする。 　release branches 　プロダクトリリースの準備。 機能の追加やマイナーなバグフィックスとは独立させることで、 リリース時に含めるコードを綺麗な状態に保つ（機能追加中で未使用のコードなどを含まないようにする）ことができる。 develop ブランチにリリース予定の機能やバグフィックスがほぼ反映した状態で develop から分岐する。 リリース準備が整ったら, master にマージし、タグをつける。次に develop にマージする。 　hotfixes branches 　リリース後のクリティカルなバグフィックスなど、 現在のプロダクトのバージョンに対する変更用。 master から分岐し、 master にマージし、タグをつける。次に develop にマージする。 　開発フローの例 　ローカルリポジトリにクローンを作成する。 　共有リポジトリを利用して開発を進める場合、クローン(clone)して作業ディレクトリをローカルに作成します。このクローンはサーバが保持しているデータをほぼすべてローカルにコピーします。これはプロジェクトのすべてのファイルのすべての履歴が手元にコピーされることを意味しています。 　作業ディレクトリを作成するコマンドは下記を実行します。 　------※clone以下はGitHubのhttps等のURLを入れて下さい。------ 　git clone https://github.com/.git 　そしてクローンしたプロジェクトに移動します。 　cd プロジェクト名 　Git-flowの初期化（developブランチの作成）を行います。 　下記のコマンドを実行すると、ローカルリポジトリの初期化ができます。実行すると、ブランチの名前などを聞かれますが全てEnterで！ 　git flow init 　実行後、branchの状態を確認しましょう。 　git branch 　実行結果は下記の様になっています。 　* develop 　master 　リモートブランチにdevelopブランチがないので下記コマンドを実行して下さい。 　git push origin develop 　機能実装を開始する 　Step1 　featureブランチを作成 　developブランチからフィーチャーブランチを作成し、機能実装作業を開始します。コミットはフィーチャーブランチに対して行います。 　まず、feature/top を作成します。 　git branch feature/top 　feature/top にブランチを切り替えましょう。 　git checkout feature/top 　上記コマンドで作成されたブランチは、個人のローカル上に作成しています。その為、GitHubには反映されていません。反映させるには、下記コマンドを実行してpushを行う必要があります。 　git push origin feature/top 　Step2　Pullを行う 　作業者は、リモートリポジトリの最新データを使用する必要があります。（コンフリクトが起きるため）下記のコマンドでモートリポジトリの最新データをPullしましょう。 　git pull origin develop 　Step3　Pushを行う 　ファイルをインデックスに追加する（コミットの対象にする） . にすることで全てのファイルを指定します。test.phpなどとすることで特定のファイルを指定できます。 　git add . 　インデックスに追加した変更をリポジトリに記録する。 　git commit -m "変更点を記入" 　featureブランチにpushします。 　git push origin feature/top 　機能実装を完了する 　featureブランチでの作業が完了したら、featureブランチをdevelopブランチにmergeします。merge完了後にfeatureブランチを削除します。 　Step1　GitHub上で、Pull Requestを作成する 　GitHub上に作成したリポジトリページを開き、Pull requestsボタンを押すと、Pull Request作成ページに移動できます。 　Pull request作成ページでは、リクエストを送信する相手に、どういう変更を加えたのかを説明する内容を記入します。記入できたら、「Create pull request」ボタンを押して、Pull Requestを送信します。 　これでPull Requestが送信されました。送信後のページでは、今作成したPull RequestがOpen状態になって表示されていると思います。 　Step2　GitHub上で、Pull Requestをマージする 　Pull Requestの変更点が問題なければ、「Merge pull request」→「Confirm Merge」ボタンを押すだけです。 　マージが完了した後は、ブランチを削除しましょう。 　参考文献 ・　https://qiita.com/KosukeSone/items/514dd24828b485c69a05#8-github%E4%B8%8A%E3%81%A7pull-request%E3%82%92%E3%83%9E%E3%83%BC%E3%82%B8%E3%81%99%E3%82%8B ・　https://www.atmarkit.co.jp/ait/articles/1708/01/news015.html ・　https://blog.codecamp.jp/git_flow_whatis

※備忘録です。 コンフリクト解消にかなり手こずってしまったため、手順を記録しておきます。 ◆実現したいこと ・プルリクエストをコンフリクトなく実行できるようにしたい ◆現状 ・プルリクエストを実行すると、コンフリクトを解消してくださいと怒られてしまう。 ◆原因 ・正しいブランチに正しい順序でプルリクエストできていなかった。 ・間違った状態でコマンドを実行しすぎてしまい、gitの状態がぐちゃぐちゃになってしまった。 ◆解決方針 ・Gitをぐちゃぐちゃになる前に戻す ・コンフリクトを手動で修正する ◆解決手順 ・現状のブランチの状況を確認する $ git branch ・gitの状態をある特定の場所まで戻す $ git reset --hard URL ※URLには、戻したいgitバージョンのURLを貼る。URLはgithubから確認できる ・特定の場所まで戻れたら、いらなくなったコミットを削除する $ git revert URL ※git logでもURLを確認できる ----- ここまでで、ぐちゃぐちゃになってしまったものを、整えることができた。 ----- ここからは、コンフリクトの解消へ進む ・本流へ移動 $ git checkout [main] ※[]の中には、使っている名称を入力する ・ローカルリポジトリにブランチをマージする $ git pull ・新しく本流からブランチを切り出す $ git checkout -b [feature/test-solve-conflict]　 ※[]の中には、自分で決めたブランチ名を入力する ※新しく本流からブランチを切り出す理由は、問題をシンプルにしたかったから。本流のリポジトリでは、チーム開発の進み具合によっては更新が進み、コンフリクトが積み重なってしまう可能性がある。それを避けるため、コミットする前に最新版をgit pullして、古いブランチをそのまま使うのではなく、新しいブランチを切り出して使う。 ・コミットを書き換える $ git merge --squash [feature/test] ※[]の中には、もともと使っていたブランチを入力する。 -----　ここでコンフリクトを手動解消 ・改めてプルリクエストを行う $ git add * $ git commit $ git push origin feature/test-solve-conflict コンフリクトを正しく手動修正できていれば、コンフリクトすることなくプルリクエストができるはず。 以上

第一弾はこちらです。 分かったつもりで分かっていなかったGit、GitHub① 前回に引き続き、分かったつもりで分かっていなかった内容をまとめます！ 間違い等あればご指摘お願い致します！ conflicts(コンフリクト) コンフリクトは衝突という意味で、別々のブランチで同じファイルの同じ行をそれぞれ変更され差異が発生した状態でマージしようとすると起こります。 違うファイルの変更なら起こらないし、同じファイルでも行が違えば起こらないです。 コンフリクトって怖いイメージありますけど、実はそんなに難しくなく修正できるのです。 もしコンフリクトが起きるとGitHub上でエラーが出ます。 で、コードを見てみるとコンフリクトしている部分を以下のように<<<や>>>で教えてくれます。 <div class="playlist"> <ul> <li>ナノセカンド</li> <li>ハルジオン</li> <<<<<<<<<< <li>KINJITO</li> <li>MONDO PIECE</li> ========== <li>在るべき形</li> <li>THE OVER</li> >>>>>>>>>> </ul> </div> <<<<<から>>>>>までがコンフリクトしている箇所です。 GitHub上のエディタでそのまま直せます。 正しい状態に直してマージすればOKです。 その際、<<<<<や>>>>>は不要なので消すことを忘れずに。 ブランチの作成や移動 いろいろなコマンドがありますよね。 ブランチの一覧表示 私は心配性なので今いるブランチを頻繁に確認してしまう...。 // *が今いるブランチ $ git branch * develop sample1 sample2 // -aをつけるとリモート追跡ブランチも見れる $ git branch -a * develop sample1 sample2 remotes/origin/HEAD -> origin/main remotes/origin/main ブランチの作成 今いるブランチから派生して作成されます。 例えば今いるブランチがdevelopで以下のコマンドを実行したらdevelopから派生したsample1ブランチができるということです。 $ git branch sample1 ブランチの移動 $ git checkout sample1 ブランチの作成と移動を一緒に行う $ git checkout -b sample1 ブランチの削除 マージ済みなら以下のコマンドです。 $ git branch -d sample1 マージされる前のブランチを削除したい場合は以下のコマンドです。 $ git branch -D sample1 revert(リバート) 過去のコミットを取り消したい時に使うものなのですが消すのではなく打ち消す内容をコミットするのが特徴です。 分かりづらいですよね。 例えば以下のような追加をしたコミットがあるとします。 <div class="title"> <h2>ハンバーグ</h2> //以下を追加 <p>ひき肉</p> </div> で、これを取り消す。 コマンドは以下です。 //消したいコミットを確認。確認したらqを押して抜ける。 $ git log //該当のIDをコピーし以下のコマンド $ git revert <打ち消したいコミットID> そうすると以下のように追加する前に戻ります。 <div class="title"> <h2>ハンバーグ</h2> </div> revertは追加したコミットと反対の内容でコミットをしているだけなので、打ち消しても以前の追加したコミット履歴は消えません。 完全に消すのはresetというものがありますが履歴も残らないのであまり使わない方がいいようです。 revertはそのrevertをさらにrevertできるので打ち消しても元に戻せます。 便利ですねー。 rebase(リベース) 先輩が言ってました。 「rebaseは歴史の元を改変することだよ」と。 名前の通り、根本を植え替えるということでしょう。 以下は先輩が分かりやすく説明してくれた例です。 上記のように日本史ブランチから日本史Aブランチ、日本史Bブランチが作成されています。 これはつまり、縄文時代から始まった日本史と奈良時代から始まった日本史があるということです。 大変ですね。 マージすると、その二つの世界線があった上で一つの世界に合体するという感じですが、 リベースはブランチの付け根を付け替えることができるので、元々一つの世界だったようにすることができます。 こんな感じで日本史Bブランチの根本を付け替えることができます。 ログが見やすくなったりするのですが、リモートリポジトリでやってしまうと誰かのコミットに影響を与えてしまうので基本的にはローカルでやるのが正しいみたいですね。 (プロジェクトによってルールはあると思いますが) 私としては基本的にはマージで対応できればその方が安全だなと思ってます。 以下、リベースのコマンドです。 //先ほどの例のように日本史Aブランチに日本史Bブランチをつなげる場合 $ git rebase 日本史A また、リベースはオプションをつけることでコミットを一つにまとめたりできるようです。 例えば以下の例えのように古墳時代と飛鳥時代を一つにまとめたいとします。 その場合のコマンドは以下です。 //以下のコマンドでまとめる一つ前である弥生時代のコミットIDを調べる $ git log //以下のコマンドでviが開く $ git rebase -i <弥生時代のコミットID> //開いたviは以下のイメージ pick d9a1f0a 古墳時代 pick 400f34a 飛鳥時代 //pickをsquashに変更する pick d9a1f0a 古墳時代 squash 400f34a 飛鳥時代 上記の流れで一つにまとめることができます。 コミットを細かく分けすぎて見にくい時とかに使うといいですね！ 以上です。

git の勉強を行ったので、その備忘録 GITとは：バージョン管理システム ・バージョン管理の流れ 　　ファイルを作ったり修正したりある程度のまとまりになったら、履歴データベースに保存する。 　　１．作業ディレクトリ 　　２．ステージングエリア 　　３．リポジトリ(ローカル、リモート） コマンド一覧 git config -l ：設定の一覧を見る git config -help(git help config)：設定のマニュアルを確認する git init：gitで使うことを宣言する。 git add：ステージングエリアに保存する。 git commit： リポジトリに保存する。 git log：履歴を表示する git log -p：変更された場所も確認できる。 git log --stat：どのファイルが何箇所変わったかを確認できる。 git status：現在の状態を確認する git checkout -- ：ステージングエリアに保存したのを取り消す。 git diff：どこをどのように編集したかを確認する。 　　※ステージングエリアにあげてしまうと確認不可 git diff --cached：ステージングエリアにあげてしまった時にどこをどのように編集したかを確認する。 git rm <ファイル名>：ステージングエリアやコミットしたあとにファイルを消す git mv <ファイル名>：ステージングエリアやコミットしたあとにファイルを移動する git commit --amend：直前のコミットを変更してくれる git reset --hard HEAD：コミット前に実施すると、作業ディレクトリもステージングエリアも一気に直前のコミットに戻す git reset --hard HEAD　：作業ディレクトリもステージングエリアも指定したコミットIDのコミットへ戻す。 git reset --hard ORIG_HEAD：取り消し前のコミットへ戻す 　　※ORIG_HEAD：前回取り消された情報が１つだけ格納されている git branch：ブランチ情報が見れる git branch <ブランチ名>：ブランチを作成できる git checkout <ブランチ名>：ブランチ名のブランチへ切り替える git merge <ブランチ名>：今いるブランチに、指定したブランチをマージさせる。 git branch -d <ブランチ名>：ブランチを削除する。 コンフリクトの解決方法：コンフリクトしている箇所で、どちらかを選んで修正する。 git tag (tag name)：直近のコミットにタグを付ける。 git tag (tag name)(commit id)：指定したcommit idにタグをつける。 git tag -d (tag name)：指定したタグ名を削除する。 git config --global alias.co checkout：エイリアスを使用し、checkoutをcoで使えるようにする。(※他のコマンドでも可能) git init --bare：共有リポジトリを作成する。 git remote add origin (repos location)：別のリポジトリを登録する。 git push origin master：共有リポジトリに対して、MASTERの内容を突っ込む。 git clone　<共有リポジトリ先> <フォルダ名>：共有リポジトリの中身を<フォルダ名>の中にコピーする。 git pull origin master：共有リポジトリの内容を、持ってきてマージしてくれる。 共有時のコンフリクトの解決方法：Mergeの時のコンフリクトと同様に、コンフリクトしている箇所でどちらかを選んで修正する。