■目次
Gitの基本基本メモブランチ操作メモフォークとプルリクエストSourcetreeでgitを操作する(基本)Sourcetreeでgitを操作する(応用)VSCodeでgitを操作するコマンドでgitを操作するコマンドで作業&コミット&プッシュするコマンドで差分を取得するコマンドで操作を取り消すブラウザ上でマージするプッシュせずに差分を共有するブランチを保護する大容量のバイナリファイルを扱うリポジトリを複製(引っ越し)するリポジトリを譲渡するGitLab独自ブランチモデルの考察トラブル
■Gitの基本
マンガでわかるGitの記事一覧 | リクナビNEXTジャーナル https://next.rikunabi.com/journal/tag/webdesign-manga/ 公式ドキュメント https://git-scm.com/book/ja/v1/ 逆引きGit http://www.backlog.jp/git-guide/reference/ Git入門(SourceTree の使い方) - セルティスラボ https://celtislab.net/archives/20140527/git-sourcetree/ SourceTree(3.0.15)をインストールしてみた - Qiita https://qiita.com/tetsu831018/items/bb6ecf15ca5f67e5879a 【永久保存版】Gitのあらゆるトラブルが解決する神ノウハウ集を翻訳した - LABOT 機械学習ブログ https://blog.labot.jp/entry/2019/07/01/183204 入門書を終えた人に捧げる、社会人のためのGit中級編 - Qiita https://qiita.com/yamamoto7/items/fe15a1e7e360b4015fae
■基本メモ
Git初心者への説明用メモ Gitの基本 - Qiita https://qiita.com/refirio/items/938ebf399029d9c62b3f ■バージョン管理システムとは ・作業内容を記録していくことができる ・過去の作業内容を簡単に把握できたり、特定の日時の状態に戻したりができる フォルダを丸ごとコピーし、日付を付けて置いておく…というのもバージョン管理の一つ ただしその方法だと、細かな変更内容を把握するのは難しい Gitでバージョン管理することにより、いつでも過去の状態を参照できるようになる ■Gitの特徴 以下の特徴を持つバージョン管理システム ・分散型 ... 一度サーバからソースコードを取得すればオフラインで作業でき、任意のタイミングでサーバに反映できる ・高速 ... SVNなど他のバージョン管理システムよりも、高速に動作する ・賢いマージ ... 他のバージョン管理システムよりも、作業内容を賢くまとめてくれる ■リポジトリ ソースコードは「リポジトリ」と呼ばれる場所で管理する リポジトリは基本的に、ホスティングサービス上で作成するといい ■ホスティングサービス リポジトリを管理してくれる場所 一人で作業する場合は無くてもいいが、バックアップのためにも使用することを推奨。複数人で作業する場合は必須 有名どころだと、以下のようなものがある ・GitHub 一番メジャーだと思われる。オープンソースで公開する場合に最適。非公開リポジトリを作りたい場合は有料 …だったが、2020年4月15日現在、非公開リポジトリもチーム利用も無料になった https://github.com/ https://github.com/pricing https://www.publickey1.jp/blog/20/githubactionscicd.html ・Bitbucket 無料で非公開リポジトリを作れる。1リポジトリに5ユーザ以上参加させたい場合は有料 https://bitbucket.org/ https://bitbucket.org/product/pricing ■Git操作 ・コマンドで操作する ・Sourcetreeなどグラフィカルなソフトウェアで操作する の2つがある。WindowsやMacで使うなら、グラフィカルなソフトウェアを使うといい ■クローン リポジトリの内容をローカルにコピーすること Gitではサーバ上だけでなくローカルにもリポジトリの複製を持ち、定期的に同期させる ■コミットとプッシュとプル ・コミット ... ローカルのリポジトリに作業を記録する ・プッシュ ... コミット内容をサーバのリポジトリに記録する ・プル ... サーバのリポジトリの内容をローカルのリポジトリに反映する(他の人の変更内容を取り込む) ■ファイルの状態 ・作業ディレクトリ ... 作業中のファイル ・ステージングエリア ... 次にコミットされるファイル ・Gitディレクトリ ... コミットされたファイル の3つがある 作業ディレクトリにあるファイルをステージングエリアに移動させ、 それに対してコメントとともにGitディレクトリに移動させる(=コミット) ステージングエリアがあることにより、一部のファイルのみコミット対象にすることができる ここまでできれば、最低限だがGitを使うことができる ■ブランチとマージ ブランチを作れば、いくつもの作業を同時に進めることができる 作業が完了したら、もとの場所にマージ(統合)することができる 複数人で作業するときに、特に力を発揮する ■コンフリクト マージの際、作業内容が競合したことをいう ・マージ元の作業が正しいとみなす('相手の変更'を使って解決) ・マージ先の作業が正しいとみなす('自分の変更'を使って解決) ・手動で調整し、コミットしなおす(解決済みにする) という対応がある Sourcetreeの場合、競合しているファイルを右クリックし、「競合を解決」から解決方法を選択できる なお、競合している箇所は以下のように書き換えられる 手動で調整する場合、「<<<<<<< HEAD」などの情報は不要なので削除する <<<<<<< HEAD <p>5月6日開催</p> ======= <p>5月5日開催</p> >>>>>>> update-news ■ブランチモデル gitでは自由にブランチを作成できるが、何のルールも無く作成すると混乱のもとになる 有名どころのルールとして以下がある ・GitHub Flow ... 小規模開発向け masterブランチから開発用ブランチを作成し、作業が完了したらmasterブランチに戻す ・Git Flow ... 中規模〜大規模開発向け master、develop、feature、release、hotfix という5種類のブランチを使い分ける 【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう:こっそり始めるGit/GitHub超入門(終) - @IT https://www.atmarkit.co.jp/ait/articles/1708/01/news015.html git flowとgithub flowとは?その違いは? - Qiita https://qiita.com/mint__/items/bfc58589b5b1e0a1856a Git Flow をベースに、独自のブランチモデルで運用しているところもある ■コミットの粒度とメッセージ あとで見直しやすいように、ということを意識してコミットするといい 「コミットの際に課題番号も書く」など、独自のルールが設けられることも多い ■.gitignore バージョン管理対象外にするファイルを指定できる Thumbs.db や .DS_Store は管理対象外にしておく その他環境依存の設定ファイルや、巨大すぎる動画ファイルやライブラリも省いておくと管理しやすくなる ■課題管理・Wiki 大抵のホスティングサービスには用意されている うまく使うと便利。この部分は、BacklogやRedmineなど他のサービスやツールを使うこともある
■ブランチ操作メモ
理解を深めるために、Gitに慣れてきたら知っておくといい master ... 最初にコミットすると作成される、デフォルトのブランチ名。 「master ブランチは本番環境(成果物)と同一」という運用をされることが多い origin/xxx ... リモートサーバにある内容をそのまま保持しているブランチ。読み取り専用 origin/HEAD ... リモートサーバのデフォルトブランチ。基本的に origin/master と同一 fetch ... 例えば master に対して操作した場合、origin/master の内容をリモートサーバの最新状態に更新する Sourcetreeの場合、初期設定では定期的に自動で fetch が行われる merge ... ブランチを統合する pull ... 例えば master に対して操作した場合、origin/master の内容をリモートサーバの最新状態に更新する さらに origin/master の内容を master に merge する fetch して内容に問題がなければ pull する…とすれば慎重な運用になる
■フォークとプルリクエスト
公開リポジトリで不特定多数に公開するなら、知っておくといい Sourcetreeを例に記載 GitHubを使うなら最低限知っておきたい、プルリクエストの送り方とレビュー、マージの基本 (1/2):こっそり始めるGit/GitHub超入門(10) - @IT http://www.atmarkit.co.jp/ait/articles/1702/27/news022.html 【GitHub】Pull Requestの手順 - Qiita https://qiita.com/Commander-Aipa/items/d61d21988a36a4d0e58b SourceTree で GitHub の Fork レポジトリを追加&同期する方法 - Qiita https://qiita.com/katzueno/items/967c14044982fb6dec65 ■プルリクエストの送信 自身のアカウントでGitHubにログインした状態で https://github.com/refirio/test にアクセスし、ページ右上の「Fork」をクリックする 数秒待つと https://github.com/(自身のアカウント)/test にForkされた (複数のリポジトリを持っている場合、フォーク先を確認される) Sourcetreeでローカルにクローンする クローン後、「develop」ブランチにチェックアウト 「develop」ブランチから「feature/test」ブランチを作成して作業&コミット 「feature/test」ブランチを「develop」ブランチにマージしてプッシュ (もしくは直接「develop」ブランチで作業してプッシュ) 自身のGitHub上に「Compare & pull request」ボタンが表示されるのでクリック プルリクエスト入力画面になるので、必要に応じて内容を入力し「Create pull request」ボタンをクリック (マージ先とマージ元の両方が「develop」になっていることを確認する。「master」などになっていたら変更する) プルリクエスト送信完了 ■プルリクエストの受信 https://github.com/refirio/test/pulls にアクセスし、プルリクエストが届いていることを確認する 「Merge pull request」ボタンをクリック 必要に応じてコメントを編集し、「Confirm merge」ボタンをクリック (ここで編集したコメントは、マージのコミットのコメントとして反映される) マージ完了 ■プルリクエストを送信する実例 ※freoを例にして実際に手順を解説 自身のアカウントでGitHubにログインした状態で https://github.com/refirio/freo にアクセスし、ページ右上の「Fork」をクリックする 数秒待つと https://github.com/(自身のアカウント)/freo にForkされた (複数のリポジトリを持っている場合、フォーク先を確認される) Sourcetreeでローカルにクローンする クローン後、「develop」ブランチにチェックアウト 「develop」ブランチから「feature/test」ブランチを作成して作業&コミット(作業に応じた名前のブランチを作成する) 「feature/test」ブランチを「develop」ブランチにマージしてプッシュ (もしくは直接「develop」ブランチで作業してプッシュ) 自身のGitHub上に「Compare & pull request」ボタンが表示されるのでクリック プルリクエスト入力画面になるので、必要に応じて内容を入力し「Create pull request」ボタンをクリック (マージ先とマージ元の両方が「develop」になっていることを確認する。「master」などになっていたら変更する マージ先ユーザが「refirio/freo」になっていることも確認する) プルリクエスト送信完了 ■フォーク元の更新を取り込む実例 ※freoを例にして実際に手順を解説 親リポジトリのURLをメモしておく。今回は以下のURLになる https://github.com/refirio/freo.git Sourcetreeで「設定」をクリックする 「リモート」タブで「追加」をクリックする リモート名: freo(何でもいい) URL/パス: https://github.com/refirio/freo.git と設定して「OK」をクリックする もとの画面に戻るので、さらに「OK」をクリックする これでリポジトリが追加できた Sourcetreeでmasterブランチに切り替える(masterブランチに更新を取り込む場合) ツールバーの「プル」をクリックする 次のリモートからプル: freo(先程登録したリモート名) プルするリモートブランチ: master(何も表示されなければ、いったん「更新」をクリックする) 「OK」をクリックすると、更新を取り込むことができる ツールバーの「プッシュ」をクリックし、取り込んだ更新を自身のリモートリポジトリにプッシュしておく これでフォーク元の更新を取り込むことができた 必要に応じて、developブランチにも更新を取り込んだり、自身のfeatureブランチにマージしたりする
■Sourcetreeでgitを操作する(基本)
BitbucketとBitbucketを使う場合の実例を記載 ■Bitbucketでリポジトリを作成 ※本格的に使うなら、リポジトリを作る前に「チーム」や「プロジェクト」を作るといい Bitbucketにアクセスしてログイン 左の「+」ボタンを押してから「リポジトリ」を選択 リポジトリ名: 英数字で入力。URLに使われるので、案件を判別できるものを英数字で入力するといい アクセスレベル: リポジトリに誰でもアクセスできるようにするか否か。仕事用なら原則として非公開にする READMEを含めますか?: 「No」のままでいい。「Yes」にすると README.md というテキストファイルがリポジトリ内に自動作成され、リポジトリの説明を書くことができる バージョン管理システム: 「Git」のままでいい 入力したら「リポジトリの作成」をクリック リポジトリが作成され、「バケツに何かを入れましょう」という画面になる git clone https://refirio@bitbucket.org/refirio/test1.git のようにURLが表示されているが、SourcetreeにCLONEするときなどはこれを使用する ■SourcetreeでCLONE 上部にある「+」をクリック メニューから「CLONE」をクリック 元のパス/URL: 上記URLを入力 保存先のパス: 保存したい場所を入力。「元のパス/URL」を入力すると自動入力されるが、必要に応じて調整する。内容はカラにしておく 名前: 案件を判別できる名前。Sourcetreeでの表示に使われるだけなので日本語可 「クローン」ボタンを押すとクローンされる 実際にファイルを配置して、コミットやプッシュを試す ■リポジトリに他の作業者を追加 Bitbucketにアクセスしてログイン 対象のリポジトリにアクセスして「設定 → ユーザーとグループのアクセス権」を選択 Bitbucketのユーザ名を入力して、「読み取り」を「書き込み」に変更して(プッシュを受け付ける場合)、「追加」をクリックする 過去に一度もやりとりしたことの無いユーザは候補に表示されないので、その場合はそのユーザのメールアドレスを入力する 対象のメールアドレスに、リポジトリへの招待メールが送信されるので確認する
■Sourcetreeでgitを操作する(応用)
Sourcetreeを例に、特別な操作の実例を記載 ■過去のコミットに戻る 戻りたいコミットをダブルクリックする 「作業コピー切り替えの確認」が表示されるので「OK」をクリックする(過去の状態に戻る) ■過去のコミットから作業を続ける 「過去のコミットに戻る」の操作で過去の状態に戻る その状態でツールバーの「ブランチ」をクリックし、作業ブランチを作成する 作業を行いコミットする ■過去のコミットを無かったことにする(プッシュしていない場合のみ有効) 戻りたいコミットを右クリックし、「現在のブランチをこのコミットまでリセット」をクリックする モードは以下のとおり Soft ... 変更したファイルはIndexにステージされた状態でコミットがリセットされる Mixied ... 変更したファイルはIndexにステージされない状態でコミットがリセットされる Hard ... 作業が完全に無かった状態でコミットがリセットされる ■過去のコミットを打ち消す(プッシュしている場合、過去のコミットと反対の内容のコミットを作成する) 打ち消したいコミットを右クリックし、「このコミットを打ち消し」をクリックする 確認が表示されるので「Yes」をクリックする ■masterにマージしてプッシュした内容を無かったことにする(推奨手順) masterブランチの名前を master_20180721 などに変更する master_20180721 ブランチの戻りたいコミットをダブルクリックする その状態でツールバーの「ブランチ」をクリックし、masterブランチを作成する 以下のコマンドでmasterブランチを強制的にプッシュする git push -f origin HEAD:master ■masterにマージしてプッシュした内容を無かったことにする(非推奨手順) ※作業が別ブランチにバックアップされず、完全に削除される 特別な理由が無ければ「masterにマージしてプッシュした内容を無かったことにする(推奨手順)」の手順を推奨 「過去のコミットを無かったことにする」の手順で、Hardでリセットする 以下のコマンドで強制的にプッシュする git push -f origin HEAD:master ■masterにマージしてプッシュした内容を無かったことにした内容を他の環境に取り込む masterブランチの名前を master_20180721 などに変更する 「リモート」にあるmasterブランチにチェックアウトする もしくは以下のコマンドで、サーバ上の状態と強制的に一致させる git reset --hard origin/master ■直近のコミットメッセージを修正する コミット画面を開く 「オプションのコミット」を「最後のコミットを上書き」を選択する 確認が表示されるので「OK」をクリックする ■未コミットのファイルを作業を一時退避する ツールバーから「スタッシュ」を選択する 任意の名前を付けて「OK」をクリックすると、サイドバーの「スタッシュ」に変更内容が格納される 元に戻したいときは、スタッシュを右クリックして「適用」を行う 新規のファイルはスタッシュの対象外になる 対象に含めたい場合、コマンドラインでは「-u」オプションを付ける Sourcetreeの場合、いったんIndexにステージした状態でスタッシュを実行する git stash で、作業中の変更をいったん横に退けておく | Tips Note by TAM https://www.tam-tam.co.jp/tipsnote/program/post10600.html ■別のブランチから特定時点のコミットを取り込みたい ブランチを右クリックしてマージ…ではなく、任意のコミットを右クリックしてマージする ■別のブランチから特定のコミットを取り込みたい コミットを積み重ねたいブランチにチェックアウトしておく 取り込みたいコミットを右クリックし、「チェリーピック」をクリックする 確認が表示されるので「Yes」をクリックすると、即座にコミットが実行される ■コミットに目印を付ける タグを設定したいコミットを右クリックし、「タグ」をクリックする 任意の名前を付けて「タグを追加」をクリックすると、サイドバーの「タグ」にタグが表示される タグをクリックすると、その時点のコミットが表示される 「すべてのタグをプッシュ」にチェックを入れた状態でプッシュすると、リモートのリポジトリにもタグが反映される GitHubの場合、各画面でブランチを選択する際にタグが表示される 「release」から、その時点の圧縮ファイルをダウンロードすることもできる Bitbucketの場合、各画面でブランチを選択する際にタグが表示される 「ダウンロード」から、その時点の圧縮ファイルをダウンロードすることもできる ■グローバル無視リスト ※以下の手順で反映できると思われるが、反映されなかった すでにGit管理されているファイルだからか C:\Users\xxx\.gitignore_global を作成して以下のように無視したいファイルを記述 app/Plugin/VeriTrans4G/Resource/tgMdkPHP/tgMdk/3GPSMDK.properties app/Plugin/VeriTrans4G/Resource/tgMdkPHP/tgMdk/log4php.properties Sourcetreeでツールバーから「オプション → Git → グローバル無視リスト」で上記ファイルを選択 「OK」をクリック ■改行コードの対応 Windows環境のSourcetreeで普通にCLONEすると、改行コードはWindows用のものに変換される ただしDocker環境でComposerを使う場合など、Linuxの改行コードのままでないと正しく処理できないことがある 以下を参考に、Linuxの改行コードでファイルを扱う方法を記載する Git for Windowsでautocrlfの設定を間違えちゃった時の対応 - Qiita https://qiita.com/e_tyubo/items/ac555ab9d278ac366679 WindowsでGitを使うときは改行コードの自動変換を無効にしてほしい | アズシエルブログ https://www.azciel.co.jp/blog/2018/08/24/windows-git-autocrlf/ Homestead環境でPHPUnitを実行しようとすると、`/usr/bin/env: ‘sh\r’: No such file or directory`というエラーが出た - Qiita https://qiita.com/taro-hida/items/057ebc4ecb27ba376162 Gitの設定は、リポジトリ固有の設定があればその内容が、無ければグローバル設定が、それも無ければシステム設定が使用される システム設定 C:/Users/Refirio/AppData/Local/Atlassian/SourceTree/git_local/etc/gitconfig グローバル設定 C:/Users/Refirio/.gitconfig リポジトリ設定(リポジトリが C:\Users\Refirio\Docker\test の場合) C:\Users\Refirio\Docker\test\html\.git\config 以下のようにすると、現状の改行コード設定と、どこのファイルで設定されているかを確認できる (「core.autocrlf」が改行コード変換の設定) $ git config --show-origin core.autocrlf file:C:/Users/Refirio/AppData/Local/Atlassian/SourceTree/git_local/etc/gitconfig true 上記の gitconfig ファイルを確認すると、以下のようになっている
[core] symlinks = false autocrlf = true fscache = true
確かに true となっている グローバル設定が存在する場合、以下のように表示される $ git config --show-origin core.autocrlf file:C:/Users/Refirio/.gitconfig true リポジトリ固有の設定がある場合、以下のように表示される $ git config --show-origin core.autocrlf file:.git/config false 以下のようにすると、設定を変更できる $ git config --show-origin core.autocrlf file:C:/Users/Refirio/.gitconfig true $ git config --global core.autocrlf false $ git config --show-origin core.autocrlf file:C:/Users/Refirio/.gitconfig false false に変わることが確認できる。このとき、 C:\Users\Refirio\.gitconfig のファイルも書き換わっている また、以下などのファイルを直接編集して設定を変更することもできる C:\Users\Refirio\Docker\test\html\.git\config
[core] repositoryformatversion = 0 filemode = false bare = false logallrefupdates = true symlinks = false ignorecase = true autocrlf = false … 追加
$ git config --show-origin core.autocrlf file:.git/config false ファイルによる指定となり、false になったことが確認できた ただし、これだと初回CLONEのときに反映されないことになる 一例だが、以下の手順で対応してみる C:\Users\Refirio\.gitconfig で以下のように変更(改行コードを自動変換しない)
[core] excludesfile = autocrlf = false
$ git config --show-origin core.autocrlf file:C:/Users/Refirio/.gitconfig false この false の状態でCLONEする つまり、Linuxの改行コードでファイルが配置される CLONEが完了したら、いったん設定を確認する $ cd /c/Users/Refirio/Docker/test/html $ git config --show-origin core.autocrlf 確認できたら、 C:\Users\Refirio\.gitconfig の autocrlf 設定はもとに戻して C:\Users\Refirio\Docker\test\html\.git\config に autocrlf 設定を追加する これで、特定リポジトリでのみ改行コードの自動変換を無効にできる もちろん、すべてのプロジェクトで常に改行コードの自動変換を無効にするなら、大元の設定で自動変換を無効にしておくだけでいい ■複数のアカウントで操作する GitHubとBitbucketのアカウントを同時に使うのは問題ないが、 GitHubのアカウントAとGitHubのアカウントBを使い分けようと思うと一筋縄ではいかないので注意 以下は未検証だが、参考になりそうなメモ sourcetreeで複数のgitアカウント管理 - Qiita https://qiita.com/A-Kira/items/0f5334919e330a95f198 GitHubを複数のアカウントで利用するためのメモ - Qiita https://qiita.com/BlueEventHorizon/items/f9d81e3659ebce9e1ffc GitHub+SourceTreeで複数アカウント設定 - myMemoBlog by 256hax https://blog.tanebox.com/archives/6/
■VSCodeでgitを操作する
Git入門(VSCode Git の使い方) - セルティスラボ https://celtislab.net/archives/20180418/git-vscode/
■コマンドでgitを操作する
バージョンを確認する git --version クローン git clone git@bitbucket.org:xxx/yyy.git /var/www/html 現在のブランチ名を表示 git branch もしくは git branch --contains もしくは git branch --contains=HEAD もしくは以下なら、他のブランチは除外して表示される git rev-parse --abbrev-ref HEAD ブランチを切り替え(切り替えられなければ、先にプルを行う) git checkout develop git checkout feature/zzz 上記で切り替えられなければ、以下のようにする(developブランチに切り替える場合) git checkout -b develop origin/develop git - fetchしたremoteブランチのトラッキングブランチがcheckout時に自動で生成されない - スタック・オーバーフロー https://ja.stackoverflow.com/questions/18047/fetch%E3%81%97%E3%81%9Fremote%E3%83%96%E3%83%A9%E3%83%B... プル git pull 他人の作業ブランチを取り込み git pull git checkout feature/zzz プッシュ(初回) git push --set-upstream origin feature/zzz プッシュ(2回目以降) git push 更新したファイルを表示 git status -bs 履歴を表示 git log git log --oneline --graph --decorate -10 プログラマはGit、デザイナーはFTPでアップロードする場合の例 http://qiita.com/irxground/items/80dc6432e7d9d2b8b2a9 git 管理をやめる https://qiita.com/b4b4r07/items/cac4abd9ae66537e2833 既存のディレクトリに git clone するには http://neos21.hatenablog.com/entry/2016/02/07/000000 既存ディレクトリにGitリモートリポジトリを適用 https://qiita.com/llhrkll/items/9b252348898d14ff90bf ※コミットがあるのでBitbucketでは無理かも SourceTreeの使い方 | 初心者が習得するべき基本操作(diff, stash, tag, revert, cherry-pick) - ICS MEDIA https://ics.media/entry/1365 シェルスクリプトで現在のブランチ名を取得する(git rev-parse) - ペンギン村 Tech Blog http://blog.penginmura.tech/entry/2018/01/12/093400 「git pull」した時に出る、commitエディタを表示しないようにする : 元うなぎ屋 http://snickerjp.blogspot.com/2015/04/git-pull-no-edit.html バージョン管理ツールのGitでよく使用するコマンドを1ページにまとめた便利なチートシート -GitSheet | コリス https://coliss.com/articles/build-websites/operation/work/frequently-used-commands-in-git.html Gitでやりたいこと、ここで見つかる - Qiita https://qiita.com/shimotaroo/items/b73d896ace10894fd290
■コマンドで作業&コミット&プッシュする
■作業ブランチを作成 現在のブランチを確認 $ git branch * develop master 作業ブランチとして feature/test を作成 $ git branch feature/test ブランチを切り替え $ git checkout feature/test Switched to branch 'feature/test' ブランチの切り替えを確認 $ git branch develop * feature/test master ■作業内容をコミット 作業内容の差分を確認 $ git status -bs ## feature/test M index.html 作業内容の差分の詳細を確認 $ git diff -- index.html diff --git a/index.html b/index.html index 795b8df..68ba275 100644 --- a/index.html +++ b/index.html @@ -7,7 +7,7 @@ </head> <body> <h1>Test</h1> - <p>テストページです。</p> + <p>これはテストページです。</p> <ul> <li><a href="page1.html">テストページ1</a></li> <li><a href="page2.html">テストページ2</a></li> $ git status On branch feature/test Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: index.html 作業内容をステージに追加 $ git add index.html ステージに追加した内容を取り消す場合 $ git checkout HEAD -- index.html もしくは以下 $ git reset index.html $ git status On branch feature/test Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: index.html $ git status -bs ## feature/test M index.html $ git commit -m "文言を修正" [feature/test 6049160] 文言を修正 1 file changed, 1 insertion(+), 1 deletion(-) $ git log --oneline --graph --decorate -5 * 6049160 (HEAD -> feature/test) 文言を修正 * a920e34 (origin/master, origin/develop, origin/HEAD, master, develop) 文言を修正 * 4a16324 (tag: v1.0, tag: title) Merge branch 'develop' |\ | * c27017c Merge branch 'title' into develop | |\ | | * dbd4095 addressを追加 ■作業内容をコミット(参考) ステージに追加したファイルが複数の場合、以下のように表示される $ git status On branch feature/test Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: page1.html modified: page2.html Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: page3.html $ git status -bs ## feature/test M page1.html M page2.html M page3.html ■作業内容をプッシュ $ git push origin feature/test … ユーザ名とパスワードを求められる Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 12 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 317 bytes | 317.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (2/2), completed with 2 local objects. remote: remote: Create a pull request for 'feature/test' on GitHub by visiting: remote: https://github.com/yamano-terraport/test/pull/new/feature/test remote: To https://github.com/yamano-terraport/test.git * [new branch] feature/test -> feature/test ■作業内容をマージしてプッシュ $ git checkout develop Switched to branch 'develop' Your branch is up to date with 'origin/develop'. $ git merge feature/test Updating a920e34..6049160 Fast-forward index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git push origin develop Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 To https://github.com/yamano-terraport/test.git a920e34..6049160 develop -> develop
■コマンドで差分を取得する
■ブランチの差分 ※必要に応じて「git status」も使用する 「git status」については後述している ブランチの差分を比較(詳細に表示される) $ git diff master..develop ブランチの差分を比較(ファイルごとの変更量のみ表示される) $ git diff master..develop --stat ブランチの差分を比較(ファイルごとの変更有無のみ表示される) $ git diff master..develop --name-status ブランチの差分コミットを比較 $ git log master..develop --no-merges コミットの差分を比較 $ git diff ecd33874941c4d80ae8e292d73823779343ae3d7..e98941613496190c55e5ab56d8bab2f22e49a8c2 --stat $ git diff ecd33874941c4d80ae8e292d73823779343ae3d7..e98941613496190c55e5ab56d8bab2f22e49a8c2 --name-status $ git diff ecd33874941c4d80ae8e292d73823779343ae3d7..e98941613496190c55e5ab56d8bab2f22e49a8c2 --no-merges Gitで差分ファイルを抽出+zipファイル化する方法 | 株式会社グランフェアズ https://www.granfairs.com/blog/staff/git-archivediff 忘れやすい人のための git diff チートシート - Qiita https://qiita.com/shibukk/items/8c9362a5bd399b9c56be [Git]ブランチ間の差分をコミット単位で知る・見る - Qiita https://qiita.com/ikenji/items/fecd39966bbf463da3f4 ※上記のように「..」とピリオドを2つ続けて指定する ピリオドが無くても表示されるが、結果に影響しているようなので詳細は要確認 以下が参考になりそう git diffコマンドで比較する時のダブルドット(..)とトリプルドット(...)の違いとは? | Yakst https://yakst.com/ja/posts/4116 ■ファイルの差分 「git diff」だと新規に作成されたファイルは差分扱いされない 「git status」でも確認しておくと無難 作業の状態を確認(ブランチ名を表示) $ git status -bs 作業の状態を確認(ブランチ名を表示しない) $ git status --short 差分のあるファイルを確認 $ git diff --name-only 差分の詳細を確認 $ git diff -- app/view/list.php
■コマンドで操作を取り消す
PULL時に競合が発生した場合、list.twig の変更のみ取り消す git diff --name-only … 差分のあるファイルを確認 git diff -- app/view/list.php … 差分の詳細を確認 git checkout HEAD -- app/view/list.php … ファイルを指定して変更を取り消し git diff --name-only … 差分が無くなったことを確認 指定した時点の履歴に戻る git log git reset --hard xxxxxxx 履歴を元の状態に戻す git reset --hard ORIG_HEAD デプロイ済みのファイルを現在のブランチに強制一致 git checkout . デプロイ済みのファイルをmasterに強制一致 git fetch origin git reset --hard origin/master デプロイ済みのファイルをdevelopに強制一致 git fetch origin git reset --hard origin/develop 強制的にチェックアウト git checkout --force <ブランチ名> プッシュを取り消す(完全に無かったことになるが、取り消し履歴も残らないので注意) git log --oneline git reset --hard xxxxxxx git log --oneline git push -f ... 強制プッシュ。ユーザ名とパスワードを入力する 取り消した内容を他の環境に反映させる場合、 「Sourcetreeでgitを操作する」の「masterにマージしてプッシュした内容を無かったことにした内容を他の環境に取り込む」を参照 コミットのコメントは、直前の内容のみ編集できる Sourcetreeのコミット画面で「オプションのコミット」を「最後のコミットを上書き(Amend)」にし、コメントを修正してコミットする Gitでやらかした時に使える19個の奥義 - Qiita https://qiita.com/muran001/items/dea2bbbaea1260098051 gitでmasterを過去のある位置に戻すには - uehatsu's tech blog https://uehatsu.info/tech/archives/2015/03/rewind-the-master-on-git.html git pushを取り消す http://tweeeety.hateblo.jp/entry/2015/06/10/215753 git reset --hard で指定した時点の履歴に戻る方法 http://blog.roundrop.jp/show/37 git log --oneline のお供に --no-merges http://qiita.com/hattorix@github/items/f18b172aafe1340d87f6 困った時の逆引きGitメモ http://myenigma.hatenablog.com/entry/2016/07/09/190058 gitでリモートのブランチにローカルを強制一致させたい時 http://qiita.com/ms2sato/items/72b48c1b1923beb1e186 GitでリモートにPushした内容を取り消したい!! http://grandbig.github.io/blog/2016/07/16/git-reset/ Git で コミットを無かったことにする方法 (git revert の使い方) http://akiyoko.hatenablog.jp/entry/2014/08/21/220255 git revertでmerge commitを取り消す http://qiita.com/shizuma/items/313ed581e071f53a4d2e 【派閥別】Gitのコミットを間違えたときの対処法まとめ http://freak-da.hatenablog.com/entry/20111105/p1 gitでいろいろ取り消したい - Qiita https://qiita.com/tani-shi/items/3419600447292abf6c79 Gitで過去のバージョンに戻す(チェックアウト) - JavaScript勉強会 http://jsstudy.hatenablog.com/entry/Checkout-with-Git SourceTreeでコミットを取り消す | cly7796.net http://cly7796.net/wp/other/cancel-the-commit-sourcetree/ 「git checkout .」と「git reset」の違いは以下が参考になる 基本的に「git checkout .」で良いかも Git - リセットコマンド詳説 https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E... Git強制チェックアウト - Qiita https://qiita.com/ryotaro76/items/ca4c504e290d088aaa4c
■ブラウザ上でマージする
Bitbucketの場合、以下のようなURLでリポジトリのページがあり、Sourcetreeが無くてもここからマージ作業ができる https://bitbucket.org/xxx/yyy marge_test1 ブランチを develop ブランチにマージする場合のメモ ブランチ → (任意のブランチ名をクリック) から、ブラウザ上でマージなどを行える 「対象を変更」リンクから必要に応じて対象を変更し、「マージ」ボタンを押すとコメントとともにマージができる コメントは「marge_test1 を develop にマージしました。」のような初期値が入力済になっているので、基本的にこのままでいい なお、マージしようとしている内容にコンフリクトがある場合、「マージ」ボタンを押した際に以下の警告が表示される
このマージには衝突があり,コミットできるようにするにはこれを解消しなければなりません。 変更を master に手作業でマージするには、下記のコマンドを実行してください: $ git checkout master $ git merge remotes/origin/marge_test1
■プッシュせずに差分を共有する
以下の方法でやり取りできるようだが、癖があってエラーになることがあるみたい?未検証 SourceTreeで差分ファイルを共有する - Qiita https://qiita.com/masao_keda/items/2f30f240bd85dba46b7f
■ブランチを保護する
GitHubの場合、特定ブランチへの強制プッシュを無効にしたり、プルリクエストを必須にしたりできる Bitbucketの場合、特定ブランチへプッシュできる人を限定することができる マンガでわかるGit 10話「masterブランチを守れ!〜危険な強制プッシュ〜」 | リクナビNEXTジャーナル https://next.rikunabi.com/journal/20170516_t12_iq/ [GitHub] ブランチの保護設定を活用しよう 【レビューが通るまでマージさせんぞ】 | Developers.IO https://dev.classmethod.jp/tool/github/protect-branch/ プルリクレビュー必須にしてやった - もがき系プログラマの日常 http://kojirooooocks.hatenablog.com/entry/2018/05/11/033152 BitBucketでmasterブランチにpushできるユーザあるいはグループを制限したい | オガリア 技術ブログ http://tech.oga-ria.com/branch-management-in-bitbucket/
■大容量のバイナリファイルを扱う
Gitはその性質上、大容量のバイナリファイルを扱うことには適していない 巨大すぎるファイルはGit管理外にすることもある 以下のような模索はされているので、今後改良されるかも Git Large File Storage https://git-lfs.github.com/ 大容量ファイルもGitで管理。 Git LFSの使い方 https://www.slideshare.net/hibiki443/git-git-lfs-60951449 Git LFS で大きめのバイナリファイルも Git で管理する - Qiita https://qiita.com/msh5/items/582c086311d3630563bc
■リポジトリを複製(引っ越し)する
※履歴を保持したままリポジトリの引っ越しを行う方法 ※複製先はカラの新品のリポジトリである必要がある ※Bitbucketで実際に試した 1. Bitbucket上にカラのリポジトリを作成する 2. 複製したいリポジトリを、ローカルにCLONEする 3. CLONEしたリポジトリをSourcetreeで開き、「設定」からリモートリポジトリのパスを編集する 4. PUSHする(大抵の場合、結構時間がかかる) 5. Bitbucket上に反映されていることを確認する 【Git】コミット履歴込みでリポジトリの移行を行う。(Git to Git) - Qiita https://qiita.com/msht0511/items/467a0cbffb4fed60f885 Gitレポジトリを移行する方法 - Qiita https://qiita.com/tanacasino/items/901723e3463bac38f40e
■リポジトリを譲渡する
まずはリポジトリの所有者が作業する リポジトリの「Repository settings」の「リポジトリの詳細」のページ右上にある「Manage Repository」から「Transfer Repository」を選択する 譲渡先のワークスペースを指定する 対象ユーザに承認メールが飛び、許可するとリポジトリが譲渡される。その際に移動先のプロジェクトも選択する Sourcetreeなどを使用している場合、リポジトリの参照先を変更する 例えば taro から hanako に test リポジトリを譲渡した場合、参照すべきリポジトリのURLが https://taro@bitbucket.org/taro/test.githttps://taro@bitbucket.org/hanako/test.git に変化するので、Sourcetreeなどのリポジトリ設定もそのように変更する リポジトリの譲渡などでリポジトリのURLが変更された場合、デプロイ時の参照先も変更する必要がある リポジトリの所有権を譲渡する - アトラシアン製品ドキュメント https://ja.confluence.atlassian.com/bitbucket/transfer-repository-ownership-289964397.html 【git】リポジトリの移行時などでremote urlを変更する - KDE BLOG https://kde.hateblo.jp/entry/2018/02/18/200459 以下は実際にリポジトリの譲渡を試したときのメモ ■準備 以下にリポジトリを作成してあるものとする https://bitbucket.org/taro/test ローカルのSourcetreeで参照できるものとする 権限を与えた他のユーザからも、Sourcetreeで参照できるものとする サーバ上でPULLできるよう設定してものとする 以下は作業例 $ sudo su -s /bin/bash - apache $ cat /var/www/.ssh/id_rsa.pub ... CLONEできるようにするため、この内容をリポジトリに登録。id_rsa.pub は作成済みのものとする $ mkdir /var/www/vhosts/test $ cd /var/www/vhosts/test $ git clone git@bitbucket.org:taro/test.git /var/www/vhosts/test $ git pull ■譲渡 譲渡元でリポジトリの譲渡作業を行う 「Repository settings → Manage repository」から、譲渡先のIDを入力する 譲渡先でメールを受け取ると、以下の内容が書かれているので許可する (「以下のグループは」の下には何も書かれていなかった) - - - - - - - - - - リポジトリの所有権の移転 太郎 山田が、リポジトリtaro/testの所有権をあなたに譲ろうとしています。 あなたが承認すれば、存在する全てのユーザーとグループがリボークされたリポジトリにアクセスできます。 また、以下のグループはリポジトリにアクセスできます: [許可する] [拒否する] - - - - - - - - - - 許可すると「リポジトリは譲渡されました。」と表示される この時点で、旧URLにはアクセスできなくなる 譲渡先では以下のURLでアクセスできるが、譲渡元は権限が無いのでアクセスできない 譲渡先で「ユーザーとグループのアクセス権」を与えれば、もちろんアクセスできるようになる https://bitbucket.org/hanako/test ■譲渡後の設定(Sourcetree) SourcetreeでPULLすると、リポジトリが見つからない(移動した)ため以下のエラーになる remote: Repository taro/test not found Sourcetreeで「設定 → origin → 編集 → URL/パス」を以下のように変更して「OK」すると、PULLできるようになる https://taro@bitbucket.org/taro/test.githttps://taro@bitbucket.org/hanako/test.git ■譲渡後の設定(サーバ) サーバ上でPULLすると、リポジトリが見つからない(移動した)ため以下のエラーになる $ git pull repository does not exist. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. 以下の手順でリポジトリの参照先を変更すると、PULLできるようになる $ git remote -v origin git@bitbucket.org:taro/test.git (fetch) origin git@bitbucket.org:taro/test.git (push) $ git remote set-url origin git@bitbucket.org:hanako/test.git $ git remote -v origin git@bitbucket.org:hanako/test.git (fetch) origin git@bitbucket.org:hanako/test.git (push) $ git pull Already up-to-date.
■GitLab
GitHub買収騒動によりスポットが当たっているらしい 未検証 GitLabとは?GitHub買収で10倍のインポート数。使い方を解説 | TECH::NOTE|テックノート|テクノロジー学習やエンジニア転職に役立つ情報を発信しています https://tech-camp.in/note/technology/44434/ GitLab自社運用のための注意点とノウハウ(2018/06版) https://techracho.bpsinc.jp/morimorihoge/2018_06_04/57628
■独自ブランチモデルの考察
gitflowだと、案件によっては 「本番環境に反映できないものがdevelopにあるので運用しづらい」 が多く発生するため、ブランチモデルについて考察 独自のブランチ名やルールは極力避けたい 通常のgitflowに戻して運用できるのが理想 「日々の更新が頻繁に発生するWebシステムだが、大きな機能追加も並行して進める必要がある」 という案件に導入して、スムーズに運用できたと思うのでメモ ■master 本番環境と同一 このブランチで直接作業は行わない releaseとhotfixからのみマージされる releaseからマージした場合、1.0.0 → 1.1.0 とする(バージョンタグを付ける場合) hotfixからマージした場合、1.0.0 → 1.0.1 とする(バージョンタグを付ける場合) hotfixのreleaseへのマージ忘れ対策に、定期的にmasterからreleaseにマージする ■release ステージング環境と同一(最終確認用のステージング環境がある場合) 原則としてこのブランチで直接作業は行わないが、すぐに(「本日中に」くらいの目安)本番反映してもいい軽微な調整なら直接作業も可 masterから作成し、リリースのタイミングでmasterへマージする 日々の更新を開発版に反映するため、定期的にreleaseからdevelopとtestにマージする ■topic/1-xxx 大きな機能開発とは別に、すぐに(「数日中に」くらいの目安)本番反映してもいい日々の更新を行う releaseから作成し、完了したらreleaseへマージする 先方に確認してもらう場合、testにマージする 他の作業との差異が大きくなりすぎないように、ときどきreleaseから自身のtopicにマージする ■develop 機能開発を行う このブランチで直接作業は行わない releaseから作成し、開発が一段落したらreleaseにマージする ■feature/1-xxx 日々の更新とは別に、大きな機能開発を行う developから作成し、完了したらdevelopへマージする 先方に確認してもらう場合、testにマージする 他の作業との差異が大きくなりすぎないように、ときどきdevelopから自身のfeatureにマージする ■hotfix/1-xxx 即座に本番反映が必要な緊急対応を行う masterから作成し、完了したらmasterにマージする 問題なければreleaseとtestにもマージする ■test(必要に応じて) テスト環境と同一(先方確認用のテスト環境がある場合。社内案件の場合など、先方確認用環境が不要ならtestは無しでreleaseで確認する) このブランチで直接作業は行わない releaseから作成する ■support/1.0.1(必要に応じて) 過去バージョンのサポートを行う 必要になったときに、masterから作る バージョンタグを付けている場合、そのバージョンをブランチ名に使う - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ■デザイナーの簡易対応 topicで作業してreleaseにマージ。testにマージしたものをテスト環境に反映 gitに慣れていなければreleaseで直接作業して、testにマージしたものをテスト環境に反映 ■開発者の対応 featureで作業してdevelopにマージ。testにマージしたものをテスト環境に反映 topicで作業してreleaseにマージ。testにマージしたものをテスト環境に反映 ■その他メモ 独自のブランチ名やルールは極力避けたい 通常のgitflowに戻して運用できるのが理想 プルリクエストを活用するか否か featureからdevelopにマージするときと、topicからreleaseにマージするときに使用するか masterブランチは原則として保護しておくか 開発初期にプルリクエスト必須にしたりすると手間がかかるので、途中から変更すべきか 定期的にmasterブランチのバックアップを取っておくか backup/master_20180911 最悪無くてもGitで戻せるので、2〜3世代程度あれば十分 大きな仕様変更による競合が問題になりそうなら、場合によっては ・マイグレーションや共通関数の調整は、できるだけ早い段階で本番反映する ・その後、隠し機能として実装を進める という手順を検討する ただし早い段階で本番反映することにより、作業の取り消しが難しくなるのは注意 topicの内容を他のtopicに取り込みたいが、本番反映はもう少し先なのでreleaseには取り込みづらい という場合はどうするか testを経由するのは可能だが、本来の目的とは違うしtestが無い場合もある チェリーピックを使ったり、topic同士でマージするくらいか ■以下、考察メモ 主に http://developers.gnavi.co.jp/entry/GitFeatureFlow/koyama これを元にするか Aの作業が完了した上にBとCの機能を追加する…という場合にどうするかは要検討 stagingからmasterにマージしないので、作業の差が残り続ける懸念があるのは要検討 https://postd.cc/gitlab-flow/ GitLabFlowというのもあるらしい - - - - - master work/1-aaa work/2-bbb work/3-ccc staging masterからworkブランチを作成 作業が完了したらworkをstagingにマージし、ステージング環境に反映して動作確認 確認が完了したらworkをmasterにマージし、本番環境に反映 - - - - - 「うっかりmasterにマージした」を防ぐために、作業者はローカルにmasterを持たなくていいようにすべきか。つまりmasterからいったんブランチを作るべきか それならうっかりstagingにマージする可能性もあるので、masterからbackup/20180903 のようなブランチをときどき作る方がいいか masterからいったんdevelopを作成し、そこから作業ブランチを作るほうがいいか。それならworkとか独自の名前を付けないほうがいいか (でもgitflowと違って、気軽にfeatureからdevelopにマージしてはいけないので、独自の名前のほうがいいか。要検討) - - - - - master develop feature/1-aaa feature/2-bbb feature/3-ccc staging masterからdevelopブランチを作成 developからfeatureブランチを作成 作業が完了したらfeatureをstagingにマージし、ステージング環境(先方確認用など)に反映して動作確認 確認が完了したらfeatureをdevelopにマージし、developをmasterにマージして本番環境に反映 作業者の環境に、原則としてmasterブランチは置かない - - - - - とすればいいか そのうえで、 ・マイグレーションや共通関数の調整は、できるだけ早い段階で本番反映する ・その後、隠し機能として実装を進める とすればいいか ただし早い段階で本番反映することにより、作業の取り消しが難しくなるのは注意 masterから作業ブランチを作ると、masterに色々マージして動作確認しているときの緊急対応がやりづらい masterからリリースブランチを作って、そこからworkブランチを作るか 緊急対応はmasterからhotfixを作る 作業のマージはリリースブランチにマージしてからworkブランチへ …なら、普段どおりdevelopという名前でいいか featureからdevelopとreleaseに戻せればいい?それに加えて、デーベース定義の変更などは、早い段階でリリースを目指して隠し機能扱いにする? developからではなくmasterから作業したいfeatureがある場合はどうするか 本来はhotfixが妥当だが、開発系は常にreleaseからfeatureブランチを作るか。その後必要に応じてdevelopからfeatureにマージ。ただし慎重に - - - - - - - - - - master ... 本番環境と同一 releaseとhotfixからのみマージされる releaseからマージした場合、1.0.0 → 1.1.0 とする hotfixからマージした場合、1.0.0 → 1.0.1 とする release ... ステージング環境と同一(環境自体は無くていいかも。test ブランチの確認用環境のみでいいかも) featureはここから作る(?) developからマージされるが、featureから直接マージもあり得る(?) develop ... 開発版 featureからマージされる。開発が一段落したらreleaseにマージする feature/1-xxx ... 作業用 releaseから作り、必要に応じてdevelopからマージする(?) 大きな改修はdevelopから作っても問題はない 完了したらdevelopへマージ。先方連携するものはtestへマージ。すぐにリリースするものはreleaseへマージ(?) 他の作業との差異が大きくなりすぎないように、ときどきreleaseからマージ。developの内容を取り込んでいる場合はdevelopからマージ(?) hotfix/1-xxx ... 緊急対応用 masterから作る 完了したらmasterとreleaseとtestとdevelopにマージする。競合が心配だし面倒か(?) test ... テスト環境(先方確認用など)と同一 featureとhotfixからマージされる support ... 過去バージョンのサポート用(必要になったときのみ) masterから作る 通常のgitflowとしても運用できるのが理想 ときどき develop → release → master のマージを行わないと、コンフリクトが発生したときに差異が残り続けそうなのは懸念 featureブランチに、developの内容が混ざっているものと混ざっていないものがあるのは混乱するかも develop に対する feature のように、release から派生する作業ブランチに特別な名前を設けて区別するか fix/1-xxx とするか。修正ではなく追加もあるので topic/1-xxx とするか。完了したら release と develop と test にマージするか このブランチを設けるなら、feature は通常どおり develop から作ればいい - - - - - - - - - - Git-flowって何? - Qiita https://qiita.com/KosukeSone/items/514dd24828b485c69a05 GitFlowをやめて本番リリースが楽になった話 - Qiita https://qiita.com/koyopro/items/b4569285efc22c6397c6 Gitブランチについての基本まとめ - Qiita https://qiita.com/katsunory/items/252c5fd2f70480af9bbb
■トラブル
■トラブル時にとりあえず試すといいこと Sourcetreeを最新版にする、もしくは再インストールすると解消されることがある 「ツール → Git → Gitバージョン」部分から内蔵のGitをアップデートすると解消されることがある ターミナルから「git pull」などコマンドを直接実行すれば操作できることがある ■プッシュしようとしてもブランチが表示されない Git - Sourcetreeのプッシュ時にブランチが表示されない状態を解消したい|teratail https://teratail.com/questions/217580 Sourcetreeの不具合?3.3.9 でも発生した 「ツール → オプション → Git → Gitバージョン」で「Embedded」をクリックすると、下の「System」ボタンがアクティブになった この状態だとブランチが表示された ■他の人の変更内容を取り込むと、手元で変更していないのにSourcetreeでは「ファイル内のすべての行を変更した」とみなされる Windowsでは改行コードが自動でCRLFに変換される 1環境だけSourcetreeではなくコマンドでのコミット…のような場合におかしくなることがあるみたい 以前問題が起きた際に開発者に確認すると、 「Sourcetreeはよく解らないので、普段からコマンドでコミットしている。 他の人が作成したファイルに手を加えて、初めてコミットした際に起きているかもしれない」 とのこと 差分の出る環境でそのまま差分ファイルをコミットして解決したが、以下のページなどを参考にして根本解決を試みたい (「コミットする改行コードを常にLFにする」のように、あらかじめ設定を統一しておくことが好ましいかも) gitで差分が出続ける現象の解決法 - Qiita https://qiita.com/katsukii/items/f046eb256111f6a4a804 SourceTreeの比較プレビューがおかしいのは、改行コードのせいだったりした件 - ゼロイチ http://0-1.life/771 Gitで変更していないはずのファイルが変更とみなされる - Qiita https://qiita.com/hishida/items/35d929845c0ac824b1c0 windows環境の git で改行コードの自動変換に注意 - Qiita https://qiita.com/yokoh9/items/1ec8099696ade0c1f36e Git - Source treeで改行コードが自動的にCRLFに変換されてしまう→設定法は?(37775)|teratail https://teratail.com/questions/37775 Windows の SourceTree で プル した際に改行コードを LF にする方法 - 約束の地 https://obel.hatenablog.jp/entry/20161124/1479955273 ■Sourcetreeで何度もGitHub、bitbucketのログインを求められる SourceTreeで何度もGitHub、bitbucketのログインを求められた時に解決した方法 - Qiita https://qiita.com/Raugh/items/e5e349edacf5b01b5e1e GitHubとbitbucketで同じユーザー名は使用できないらしい ターミナルからコマンドで「git pull」「git push」などを実行すれば、明示的に認証できるので試す 以下操作例 Sourcetreeでツールバーの「ターミナル」を選択する ターミナルで「git pull」を実行する 「GitHub Lgoin」ダイアログが表示されるが、こちらは認証できないのでキャンセルする ターミナルでユーザ名の入力待ちになっているので、ユーザ名を入力する 「OpenSSH」ダイアログが表示されるので、パスワードを入力すると認証できる 以降、ブランチの切り替えなどはSourcetree上で行えるが、「git pull」「git push」など通信が発生するものは上記手順で行う Sourcetreeと内蔵のGitを最新版にすれば解決することはある 内蔵のGitはメニューの「ツール → Git → Gitバージョン」部分からアップデートできる ■SourcetreeでGitHubからコードを取得できない PULLしようとすると「GitHub Lgoin」のダイアログが表示され、情報を入力しても認証できない GitHub - SurceTreeでGitHubと連携できず「ログインエラー」が発生してしまう問題(48719)|teratail https://teratail.com/questions/48719 Sourcetreeを最新版にすると、解決することがあるみたい SourceTreeで突然gitリモートリポジトリに繋がらなくなった時。 - ノウハウブログ - カンタローCGI https://kantaro-cgi.com/blog/git/bitbucket-permission-error.html リポジトリのパスをhttpsにすると、解決することがあるみたい SourceTree + Bitbucketで認証エラーが出る場合の対処方法 on Windows | TeraDas https://www.teradas.net/archives/29134/ Sourcetreeが使うGitを、EmbeddedではなくSystemにすると解決することがあった 上にあるように、GitHubとbitbucketで同じユーザー名は使用できないらしい 他の要因の可能性もあるが、ターミナルからコマンドで操作すると取得できることが多い ■「pathspec 'develop' did not match any file(s) known to git」と表示されてブランチを切り替えられない ブランチを切り替えようとすると以下のエラーになった $ git checkout develop error: pathspec 'develop' did not match any file(s) known to git リモートにブランチは存在している $ git branch * main $ git branch -a * main remotes/origin/HEAD -> origin/main remotes/origin/develop remotes/origin/main 以下のコマンドでなら、ブランチを切り替えられた バージョン依存ではなく、指定した名前のブランチが複数のリモートに存在するとエラーになるらしい 詳細は要勉強 $ git checkout -b develop origin/develop git - fetchしたremoteブランチのトラッキングブランチがcheckout時に自動で生成されない - スタック・オーバーフロー https://ja.stackoverflow.com/questions/18047/fetch%E3%81%97%E3%81%9Fremote%E3%83%96%E3%83%A9%E3%83%B... ■「Your local changes to the following files would be overwritten by merge」と表示されてPULLできない pullを行おうとすると以下のエラーになった $ git pull Updating eb9423a..4e02523 error: Your local changes to the following files would be overwritten by merge: html/sitemap.xml Please commit your changes or stash them before you merge. Aborting リモート側でファイルが編集された場合などに、競合が発生している $ git checkout HEAD -- html/sitemap.xml として、該当ファイルの編集をリセットしておくと大丈夫だった もしくは若干強引だが、 $ git reset --hard origin/develop として、強制的にブランチの内容をリポジトリと一致させると大丈夫だった この場合は develop ブランチに強制一致させるので、他のブランチの場合は適宜コマンドを調整する ■「The following untracked working tree files would be overwritten by merge」と表示されてPULLできない pullを行おうとすると以下のエラーになった $ git pull remote: Enumerating objects: 11, done. remote: Counting objects: 100% (11/11), done. remote: Compressing objects: 100% (4/4), done. remote: Total 11 (delta 7), reused 11 (delta 7), pack-reused 0 Unpacking objects: 100% (11/11), done. From github.com:uqo/obutsudan ab88a21f..13fcaa56 develop -> origin/develop Updating ab88a21f..13fcaa56 error: The following untracked working tree files would be overwritten by merge: app/template/default/Help/about.twig app/template/default/Help/privacy.twig Please move or remove them before you merge. Aborting リモート側でファイルが作成された場合などに、競合が発生している $ rm app/template/default/Help/about.twig $ rm app/template/default/Help/privacy.twig として、該当ファイルを削除しておくと大丈夫だった もしくは若干強引だが、 $ git reset --hard origin/develop として、強制的にブランチの内容をリポジトリと一致させると大丈夫だった この場合は develop ブランチに強制一致させるので、他のブランチの場合は適宜コマンドを調整する ■「error: cannot lock ref」と表示されてPULLできない pullやfetchを行おうとすると以下のエラーになった $ git pull remote: Counting objects: 12, done. remote: Compressing objects: 100% (5/5), done. remote: Total 12 (delta 6), reused 10 (delta 6) Unpacking objects: 100% (12/12), done. From bitbucket.org:xxx/yyy b60cc33..e036554 master -> origin/master 1d5cc1a..f2070a0 develop -> origin/develop error: cannot lock ref 'refs/remotes/origin/hotfix/sdk': 'refs/remotes/origin/hotfix' exists; cannot create 'refs/remotes/origin/hotfix/sdk' ! [new branch] hotfix/sdk -> origin/hotfix/sdk (unable to update local ref) $ git fetch origin error: cannot lock ref 'refs/remotes/origin/hotfix/sdk': 'refs/remotes/origin/hotfix' exists; cannot create 'refs/remotes/origin/hotfix/sdk' From bitbucket.org:xxx/yyy ! [new branch] hotfix/sdk -> origin/hotfix/sdk (unable to update local ref) リモート側でブランチが削除された場合などに発生するみたい $ git remote prune origin $ git fetch origin としてから再度PULLすると大丈夫だった git fetchで、unable to update local refとエラーが出た場合の対処法 - tech::hexagram https://manji602.hatenablog.com/entry/2017/08/14/123137 ■「github.com:xxx/xxx.git did not send all necessary objects」と表示されてPULLできない rsyncで双方向同期を行っているECCube環境で発生 何度PULLしても
$ git pull 〜略〜 error: packfile .git/objects/pack/pack-2c4de2814e00bb352de0bb80a1a1f7e82da7990c.pack claims to have 3583 objects while index indicates 3710 objects error: packfile .git/objects/pack/pack-2c4de2814e00bb352de0bb80a1a1f7e82da7990c.pack claims to have 3583 objects while index indicates 3710 objects error: packfile .git/objects/pack/pack-2c4de2814e00bb352de0bb80a1a1f7e82da7990c.pack claims to have 3583 objects while index indicates 3710 objects error: packfile .git/objects/pack/pack-2c4de2814e00bb352de0bb80a1a1f7e82da7990c.pack claims to have 3583 objects while index indicates 3710 objects error: packfile .git/objects/pack/pack-2c4de2814e00bb352de0bb80a1a1f7e82da7990c.pack claims to have 3583 objects while index indicates 3710 objects error: packfile .git/objects/pack/pack-2c4de2814e00bb352de0bb80a1a1f7e82da7990c.pack claims to have 3583 objects while index indicates 3710 objects fatal: bad object 55584a0c340f1428bc54f0fdd61a9d6150bcd88e error: github.com:uqo/obutsudan.git did not send all necessary objects
で止まってしまったが、しばらく時間を置いて「git pull」を実行すると、最後に「Already up-to-date.」が表示されるようになった 念のため再度 $ git pull $ git fetch origin $ git reset --hard origin/master と実行することで、以降は正常にPULLできるようになったことはあった ただし「git reset」によって、サーバ上で直接変更したファイルがあれば、変更内容が消えてしまうので注意 最初にPULLを実行したときの内容が、時間をかけてrsync同期されて解決した…などはあるかもしれないが不明 もし次回発生したら、PULLのあとに時間を置いてみるのと、rsyncを停止してから実行するのは有効かもしれない 上記の手順で解決せず、別の方法で解決したときのメモを「2」として別途以下に記載する ■「github.com:xxx/xxx.git did not send all necessary objects」と表示されてPULLできない 2 検収環境と本番環境でほぼ同時期に発生し、本番環境では上にある手順でも解消できなかった .git の内容が一部壊れて修復できなくなっている可能性がありそうなので、 1. 別のフォルダにCloneする 2. 本番環境の .git を退避させる 3. 別のフォルダにCloneした .git を、本番環境の領域に移動させる とすることで復旧できた 具体的には $ git clone git@bitbucket.org:refirio/test.git /var/www/html/temp $ git pull として別のフォルダにCloneしたあと、問題が発生しているリポジトリの領域にて $ mv .git /path/to/backup/git $ mv /var/www/html/temp/.git /path/to/project のようにすることで解決できた 以下は、上記を行う前に色々と検証したときのメモ 検証のためにCloneする $ sudo su -s /bin/bash - apache $ cd /var/www/html/temp $ git clone git@bitbucket.org:refirio/test.git /var/www/html/temp $ git pull $ ll .git/objects/pack/ 合計 28 -r--r--r-- 1 apache apache 3312 5月 28 13:43 pack-93f65e1e0459bd961922cd3029dc3996fd446911.idx -r--r--r-- 1 apache apache 21494 5月 28 13:43 pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack リポジトリをバックアップしておく $ cp -rp .git git_backup ルート権限で以下のファイルを「test」に書き換えてみる(意図的にファイルを壊してみる) /var/www/html/temp/.git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack PULLしようとすると以下のとおりエラーになる $ git pull error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile error: refs/heads/master does not point to a valid object! error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile error: refs/remotes/origin/HEAD does not point to a valid object! error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile error: refs/remotes/origin/develop does not point to a valid object! error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile 〜略〜 error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is far too short to be a packfile Already up-to-date. もっと大量に(5000byteほど)書き込んでみる PULLしようとすると以下のとおりエラーになる $ git pull error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is not a GIT packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is not a GIT packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is not a GIT packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is not a GIT packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is not a GIT packfile 〜略〜 error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is not a GIT packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is not a GIT packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is not a GIT packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is not a GIT packfile error: file .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack is not a GIT packfile Already up-to-date. 以下を実行しても結果は同じだった $ git pull --prune ファイルを直接編集して正しい内容に戻すと、エラーは表示されなくなる 以下でも戻すことができる $ cp git_backup/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack .git/objects/pack/pack-93f65e1e0459bd961922cd3029dc3996fd446911.pack 以下でも戻すことができる $ mv .git git $ mv git_backup .git .git/objects 自体を削除するとどうか…と思ったが、削除後にPULLしようとすると 「fatal: Not a git repository (or any of the parent directories): .git」 のエラーになった 手順中に「git pull --prune」を試しているのは以下の記事があったためだが、 少なくとも今回は改善に繋がるものでは無かった git pullのとき常にpruneするための設定 - Qiita https://qiita.com/suin/items/27a559ab678bc054747e ■「Repository not found.」と表示されてPULLできない remote: Repository not found.となった時の対応方法 - Qiita https://qiita.com/ponsuke0531/items/4fe191b7bed03342cff2 最後にある「対応 : configファイルのurlに認証情報を追記する」で解決できたことがあった ■GitHubやBitbucketに接続できない GitHubの障害情報が以下にある GitHub Status https://www.githubstatus.com/ Bitbucketの障害情報が以下にある Atlassian Bitbucket Status https://bitbucket.status.atlassian.com/