■目次
Gitの基本基本メモブランチ操作メモフォークとプルリクエストSourcetreeでgitを操作する(基本)Sourcetreeでgitを操作する(応用)VSCodeでgitを操作するブラウザ上でマージする差分を取得するコマンドで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/ 【永久保存版】Gitのあらゆるトラブルが解決する神ノウハウ集を翻訳した - LABOT 機械学習ブログ https://blog.labot.jp/entry/2019/07/01/183204
■基本メモ
Git初心者への説明用メモ Gitの基本 - Qiita https://qiita.com/refirio/items/938ebf399029d9c62b3f ■バージョン管理システムとは ・作業内容を記録していくことができる ・過去の作業内容を簡単に把握できたり、特定の日時の状態に戻したりができる フォルダを丸ごとコピーし、日付を付けて置いておく…というのもバージョン管理の一つ ただしその方法だと、細かな変更内容を把握するのは難しい Gitでバージョン管理することにより、いつでも過去の状態を参照できるようになる ■Gitの特徴 以下の特徴を持つバージョン管理システム ・分散型 ... 一度サーバからソースコードを取得すればオフラインで作業でき、任意のタイミングでサーバに反映できる ・高速 ... SVNなど他のバージョン管理システムよりも、高速に動作する ・賢いマージ ... 他のバージョン管理システムよりも、作業内容を賢くまとめてくれる ■リポジトリ ソースコードは「リポジトリ」と呼ばれる場所で管理する リポジトリは基本的に、ホスティングサービス上で作成するといい ■ホスティングサービス リポジトリを管理してくれる場所 一人で作業する場合は無くてもいいが、バックアップのためにも使用することを推奨。複数人で作業する場合は必須 有名どころだと、以下のようなものがある ・GitHub 一番メジャーだと思われる。オープンソースで公開する場合に最適。非公開リポジトリを作りたい場合は有料 https://github.com/ https://github.com/pricing ・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とは?その違いは? - 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」をクリックすると、サイドバーの「スタッシュ」に変更内容が格納される 元に戻したいときは、スタッシュを右クリックして「適用」を行う ■別のブランチから特定時点のコミットを取り込みたい ブランチを右クリックしてマージ…ではなく、任意のコミットを右クリックしてマージする ■別のブランチから特定のコミットを取り込みたい コミットを積み重ねたいブランチにチェックアウトしておく 取り込みたいコミットを右クリックし、「チェリーピック」をクリックする 確認が表示されるので「Yes」をクリックすると、即座にコミットが実行される ■コミットに目印を付ける タグを設定したいコミットを右クリックし、「タグ」をクリックする 任意の名前を付けて「タグを追加」をクリックすると、サイドバーの「タグ」にタグが表示される タグをクリックすると、その時点のコミットが表示される 「すべてのタグをプッシュ」にチェックを入れた状態でプッシュすると、リモートのリポジトリにもタグが反映される GitHubの場合、各画面でブランチを選択する際にタグが表示される 「release」から、その時点の圧縮ファイルをダウンロードすることもできる Bitbucketの場合、各画面でブランチを選択する際にタグが表示される 「ダウンロード」から、その時点の圧縮ファイルをダウンロードすることもできる
■VSCodeでgitを操作する
Git入門(VSCode Git の使い方) - セルティスラボ https://celtislab.net/archives/20180418/git-vscode/
■ブラウザ上でマージする
Bitbucketの場合、以下のようなURLでリポジトリのページがあり、Sourcetreeが無くてもここからマージ作業ができる https://bitbucket.org/xxx/yyy marge_test1 ブランチを develop ブランチにマージする場合のメモ ブランチ → (任意のブランチ名をクリック) から、ブラウザ上でマージなどを行える 「対象を変更」リンクから必要に応じて対象を変更し、「マージ」ボタンを押すとコメントとともにマージができる コメントは「marge_test1 を develop にマージしました。」のような初期値が入力済になっているので、基本的にこのままでいい なお、マージしようとしている内容にコンフリクトがある場合、「マージ」ボタンを押した際に以下の警告が表示される
このマージには衝突があり,コミットできるようにするにはこれを解消しなければなりません。 変更を master に手作業でマージするには、下記のコマンドを実行してください: $ git checkout master $ git merge remotes/origin/marge_test1
■差分を取得する
ブランチの差分を比較 git diff master develop コミットの差分を比較 git diff ecd33874941c4d80ae8e292d73823779343ae3d7..e98941613496190c55e5ab56d8bab2f22e49a8c2 --stat git diff ecd33874941c4d80ae8e292d73823779343ae3d7..e98941613496190c55e5ab56d8bab2f22e49a8c2 --name-status ファイルごとの変更量を比較 git diff master develop --stat git diff master feature/event_media --stat ブランチの差分コミットを比較 git log --no-merges master..develop 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
■コマンドでgitを操作する
クローン 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 プル 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の操作を取り消す
指定した時点の履歴に戻る 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
■ブランチを保護する
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
■リポジトリを譲渡する
リポジトリの所有者が、リポジトリの「設定」にある「リポジトリの譲渡または削除」から譲渡先のユーザを指定する 対象ユーザに承認メールが飛び、承認するとリポジトリが譲渡される 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 ■譲渡 譲渡元でリポジトリの譲渡作業を行う 譲渡先でメールを受け取ると、以下の内容が書かれているので許可する (「以下のグループは」の下には何も書かれていなかった) - - - - - - - - - - リポジトリの所有権の移転 太郎 山田が、リポジトリ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 とする(バージョンタグを付ける場合) ■release ステージング環境と同一(最終確認用のステージング環境がある場合) 原則としてこのブランチで直接作業は行わないが、軽微なものなら直接作業も可 masterから作成する 日々の更新を開発版に反映するため、定期的にreleaseからdevelopとtestにマージする ■topic/1-xxx 大きな機能開発とは別に、日々の更新を行う releaseから作成し、完了したらreleaseへマージする 先方に確認してもらう場合、testにもマージする ■develop 機能開発を行う このブランチで直接作業は行わない releaseから作成する 開発が一段落したらreleaseにマージする ■feature/1-xxx 日々の更新とは別に、大きな機能開発を行う developから作成し、完了したらdevelopへマージする 先方に確認してもらう場合、testにもマージする 他の作業との差異が大きくなりすぎないように、ときどきdevelopから自身のfeatureにマージする ■hotfix/1-xxx 緊急対応を行う masterから作成し、完了したらmasterにマージする 問題なければreleaseとtestにもマージする ■test テスト環境と同一(先方確認用のテスト環境がある場合) このブランチで直接作業は行わない ■support/1.0.1 過去バージョンのサポートを行う(必要になったときのみ) masterから作る バージョンタグを付けている場合、そのバージョンをブランチ名に使う ■その他メモ 定期的にmasterブランチのバックアップを取っておくか backup/master_20180911 最悪無くてもGitで戻せるので、2〜3世代程度あれば十分 大きな仕様変更による競合が問題になりそうなら、場合によっては ・マイグレーションや共通関数の調整は、できるだけ早い段階で本番反映する ・その後、隠し機能として実装を進める という手順を検討する ただし早い段階で本番反映することにより、作業の取り消しが難しくなるのは注意
■トラブル
■他の人の変更内容を取り込むと、手元で変更していないのに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で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で同じユーザー名は使用できないらしい 他の要因の可能性もあるが、ターミナルからコマンドで操作すると取得できることが多い ■「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: sitemap.xml Please commit your changes or stash them before you merge. Aborting リモート側でファイルが編集された場合などに、競合が発生している $ 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