refirio.org

マンガでわかる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 第1話 リポジトリを作ってコミットしてみよう【連載】マンガでわかるGit 〜コマンド編〜 - itstaffing エンジニアスタイル https://www.r-staffing.co.jp/engineer/entry/20190621_1 Git はなぜ空のディレクトリを無視するのか？ - Qiita https://qiita.com/POPOPON/items/964d0904e32cb38c9303 たぶんもう怖くないGit ~Git内部の仕組み~ - Qiita https://qiita.com/marchin_1989/items/2ec01553e907f3a9e6bb 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」などの情報は不要なので削除する ■ブランチモデル gitでは自由にブランチを作成できるが、何のルールも無く作成すると混乱のもとになる 有名どころのルールとして以下がある ・GitHub Flow ... 小規模開発向け mainブランチから開発用ブランチを作成し、作業が完了したらmainブランチに戻す ・Git Flow ... 中規模〜大規模開発向け main、develop、feature、release、hotfix という5種類のブランチを使い分ける ・GitLab Flow ... 上記で対応が難しい場合にと考え出されたもの mainブランチから開発用ブランチを作成し、作業が完了したらmainブランチに戻す またproductionやstagingなど、環境に応じたブランチを持つ mainブランチは本番環境とイコールではなく、開発の中心ブランチとなる ・Trunk Based Development ... 開発者はビルドが通る状態を保ちながら、小さな修正をそのままmainブランチにコミットする 大きな機能開発の場合、機能のON/OFFをフラグで管理する これにより、大規模なマージ地獄から抜けられる 自動テストが整備されていることが前提にはなる 【図解】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 Gitlab-flowの説明 - Qiita https://qiita.com/tlta-bkhn/items/f2950aaf00bfb6a8c30d GitLab flowから学ぶワークフローの実践 | POSTD https://postd.cc/gitlab-flow/ アプリ開発にはGitlab flowが合うと思います - Shoichi Matsuda's diary https://shoma2da.hatenablog.com/entry/2015/11/04/233534 Git の最新アップデートから考える開発手法の潮流 - Speaker Deck https://speakerdeck.com/yuukiyo/trends-in-development-methodology-from-the-latest-git-updates DevOps 技術: トランクベース開発 | DevOps の能力 | Google Cloud https://cloud.google.com/architecture/devops/devops-tech-trunk-based-development?hl=ja もうリリースは怖くない ― 大きな変更を安全に本番適用するTips - Cybozu Inside Out | サイボウズエンジニアのブログ https://blog.cybozu.io/entry/2021/07/28/080000 これらのブランチモデルをベースに、独自のブランチモデルで運用しているところもある ■コミットの粒度とメッセージ あとで見直しやすいように、ということを意識してコミットするといい 「コミットの際に課題番号も書く」など、独自のルールが設けられることも多い ■.gitignore バージョン管理対象外にするファイルを指定できる Thumbs.db や .DS_Store は管理対象外にしておく その他環境依存の設定ファイルや、巨大すぎる動画ファイルやライブラリも省いておくと管理しやすくなる ■課題管理・Wiki 大抵のホスティングサービスには用意されている うまく使うと便利。この部分は、BacklogやRedmineなど他のサービスやツールを使うこともある ■ブランチ操作 理解を深めるために、Gitに慣れてきたら知っておくといい master ... 最初にコミットすると作成される、デフォルトのブランチ名。 「master ブランチは本番環境（成果物）と同一」という運用をされることが多い なお「master」という名前は差別用語になりうるので、「main」という名前にしようという動きがあり、実際GitHubのデフォルトブランチは「main」に変更された origin/xxx ... リモートサーバにある内容をそのまま保持しているブランチ。読み取り専用 origin/HEAD ... リモートサーバのデフォルトブランチ。基本的に origin/master と同一 fetch ... 例えば master に対して操作した場合、origin/master の内容をリモートサーバの最新状態に更新する Sourcetreeの場合、初期設定では定期的に自動で fetch が行われる merge ... ブランチを統合する pull ... 例えば master に対して操作した場合、origin/master の内容をリモートサーバの最新状態に更新する さらに origin/master の内容を master に merge する fetch して内容に問題がなければ pull する…とすれば慎重な運用になる ■コミットルール 細かなルールは各々や会社によって異なるが、一例として以下のようにするといい ・GitHubやBitbacket上に課題を作成して、その課題番号をもとにブランチの作成やコミットを行う ・ブランチ名の先頭には課題番号を付け、それに続いて課題内容を把握できる英数字を付ける ・コミットのコメントの先頭には、「#」に続けて課題番号を付ける 具体的には「PostgreSQLでマイグレーションを実行できない #104」という課題を作ったとして、 ブランチは develop から feature/104-pgsql_migrate_error を作成して作業し、 コミットは「#104 PostgreSQLでマイグレーションを実行できない不具合を修正」のようにコメントする このようにすることで、GitHub上ではコミットのコメントの「#104」から該当の課題に遷移できるようになり、管理しやすくなる 課題の管理にBacklogなど外部ツールを使うこともあるが、その場合は一例として以下のようにするといい ・Backlog上に課題を作成して、その課題キーをもとにブランチの作成やコミットを行う ・ブランチ名の先頭には課題キーを付け、それに続いて課題内容を把握できる英数字を付ける ・コミットのコメントの先頭には、課題キーを付ける 具体的には「DEV-104 PostgreSQLでマイグレーションを実行できない」という課題を作ったとして、 ブランチは develop から feature/DEV-104-pgsql_migrate_error を作成して作業し、 コミットは「[DEV-104] PostgreSQLでマイグレーションを実行できない不具合を修正」のようにコメントする （ブランチ名やコミットに「DEV-」という接頭語を含めるか否かは、検討の余地がある） BitbucketとBitbucketを使う場合の実例を記載 ■Bitbucketでリポジトリを作成 ※本格的に使うなら、リポジトリを作る前に「チーム」や「プロジェクト」を作るといい Bitbucketにアクセスしてログイン 左の「＋」ボタンを押してから「リポジトリ」を選択 リポジトリ名: 英数字で入力。URLに使われるので、案件を判別できるものを英数字で入力するといい アクセスレベル: リポジトリに誰でもアクセスできるようにするか否か。仕事用なら原則として非公開にする READMEを含めますか？: 「No」のままでいい。「Yes」にすると README.md というテキストファイルがリポジトリ内に自動作成され、リポジトリの説明を書くことができる バージョン管理システム: 「Git」のままでいい 入力したら「リポジトリの作成」をクリック リポジトリが作成され、「バケツに何かを入れましょう」という画面になる のようにURLが表示されているが、SourcetreeにCLONEするときなどはこれを使用する ■SourcetreeでCLONE 上部にある「＋」をクリック メニューから「CLONE」をクリック 元のパス/URL: 上記URLを入力 保存先のパス: 保存したい場所を入力。「元のパス/URL」を入力すると自動入力されるが、必要に応じて調整する。内容はカラにしておく 名前: 案件を判別できる名前。Sourcetreeでの表示に使われるだけなので日本語可 「クローン」ボタンを押すとクローンされる 実際にファイルを配置して、コミットやプッシュを試す クローン時に認証できない場合、先に「ツール → オプション → 認証」でアカウントを追加すると解決することがある 以前にGitHubのアカウントを追加した際、 1. ホスティングサービスを「GitHub」にする 2. 認証が「OAuth」になっていることを確認して「OAuthトークンを再読み込み」をクリックする 3. 「認証に成功」となれば「OK」をクリックする という手順で追加できた 追加後、CLONEやPULLができることを確認する ■リポジトリに他の作業者を追加 Bitbucketにアクセスしてログイン 対象のリポジトリにアクセスして「設定 → ユーザーとグループのアクセス権」を選択 Bitbucketのユーザ名を入力して、「読み取り」を「書き込み」に変更して（プッシュを受け付ける場合）、「追加」をクリックする 過去に一度もやりとりしたことの無いユーザは候補に表示されないので、その場合はそのユーザのメールアドレスを入力する 対象のメールアドレスに、リポジトリへの招待メールが送信されるので確認する Sourcetreeを例に、特別な操作の実例を記載 ■過去のコミットに戻る 戻りたいコミットをダブルクリックする 「作業コピー切り替えの確認」が表示されるので「OK」をクリックする（過去の状態に戻る） ■過去のコミットから作業を続ける 「過去のコミットに戻る」の操作で過去の状態に戻る その状態でツールバーの「ブランチ」をクリックし、作業ブランチを作成する 作業を行いコミットする ■過去のコミットを無かったことにする（プッシュしていない場合のみ有効） 戻りたいコミットを右クリックし、「現在のブランチをこのコミットまでリセット」をクリックする モードは以下のとおり Soft ... 変更したファイルはIndexにステージされた状態でコミットがリセットされる Mixied ... 変更したファイルはIndexにステージされない状態でコミットがリセットされる Hard ... 作業が完全に無かった状態でコミットがリセットされる ■過去のコミットを打ち消す（プッシュしている場合、過去のコミットと反対の内容のコミットを作成する） 打ち消したいコミットを右クリックし、「このコミットを打ち消し」をクリックする 確認が表示されるので「Yes」をクリックする ■masterにマージしてプッシュした内容を無かったことにする（推奨手順） masterブランチの名前を master_20180721 などに変更する master_20180721 ブランチの戻りたいコミットをダブルクリックする その状態でツールバーの「ブランチ」をクリックし、masterブランチを作成する 以下のコマンドでmasterブランチを強制的にプッシュする ■masterにマージしてプッシュした内容を無かったことにする（非推奨手順） ※作業が別ブランチにバックアップされず、完全に削除される 特別な理由が無ければ「masterにマージしてプッシュした内容を無かったことにする（推奨手順）」の手順を推奨 「過去のコミットを無かったことにする」の手順で、Hardでリセットする 以下のコマンドで強制的にプッシュする ■masterにマージしてプッシュした内容を無かったことにした内容を他の環境に取り込む masterブランチの名前を master_20180721 などに変更する 「リモート」にあるmasterブランチにチェックアウトする もしくは以下のコマンドで、サーバ上の状態と強制的に一致させる ■直近のコミットメッセージを修正する コミット画面を開く 「オプションのコミット」を「最後のコミットを上書き」を選択する 確認が表示されるので「OK」をクリックする ■未コミットのファイルを作業を一時退避する ツールバーから「スタッシュ」を選択する 任意の名前を付けて「OK」をクリックすると、サイドバーの「スタッシュ」に変更内容が格納される 元に戻したいときは、スタッシュを右クリックして「適用」を行う 新規のファイルはスタッシュの対象外になる 対象に含めたい場合、コマンドラインでは「-u」オプションを付ける Sourcetreeの場合、いったんIndexにステージした状態でスタッシュを実行する git stash で、作業中の変更をいったん横に退けておく ｜ Tips Note by TAM https://www.tam-tam.co.jp/tipsnote/program/post10600.html ■別のブランチから特定時点のコミットを取り込みたい 作業ブランチでコミットA, B, C と進めた場合、通常はコミットCまで進めたものを大元のブランチにマージする が、コミットAやBの時点のものをマージできるか ブランチを右クリックしてマージ…ではなく、任意のコミットを右クリックしてマージすることで対応できる ■別のブランチから特定のコミットを取り込みたい コミットを積み重ねたいブランチにチェックアウトしておく 取り込みたいコミットを右クリックし、「チェリーピック」をクリックする 確認が表示されるので「Yes」をクリックすると、即座にコミットが実行される ■コミットに目印を付ける タグを設定したいコミットを右クリックし、「タグ」をクリックする 任意の名前を付けて「タグを追加」をクリックすると、サイドバーの「タグ」にタグが表示される タグをクリックすると、その時点のコミットが表示される 「すべてのタグをプッシュ」にチェックを入れた状態でプッシュすると、リモートのリポジトリにもタグが反映される GitHubの場合、各画面でブランチを選択する際にタグが表示される 「release」から、その時点の圧縮ファイルをダウンロードすることもできる Bitbucketの場合、各画面でブランチを選択する際にタグが表示される 「ダウンロード」から、その時点の圧縮ファイルをダウンロードすることもできる ■グローバル無視リスト ※以下の手順で反映できると思われるが、反映されなかった すでにGit管理されているファイルだからか C:\Users\xxx\.gitignore_global を作成して以下のように無視したいファイルを記述 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」が改行コード変換の設定） 上記の gitconfig ファイルを確認すると、以下のようになっている 確かに true となっている グローバル設定が存在する場合、以下のように表示される リポジトリ固有の設定がある場合、以下のように表示される 以下のようにすると、設定を変更できる false に変わることが確認できる。このとき、 C:\Users\Refirio\.gitconfig のファイルも書き換わっている また、以下などのファイルを直接編集して設定を変更することもできる C:\Users\Refirio\Docker\test\html\.git\config 以下で確認 ファイルによる指定となり、false になったことが確認できた ただし、これだと初回CLONEのときに反映されないことになる 一例だが、以下の手順で対応してみる C:\Users\Refirio\.gitconfig で以下のように変更（改行コードを自動変換しない） 以下で確認 この false の状態でCLONEする つまり、Linuxの改行コードでファイルが配置される CLONEが完了したら、いったん設定を確認する 確認できたら、 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/ ■その他 SourceTreeの使い方 - 初心者が習得すべき基本操作(diff, stash, tag, revert, cherry-pick) - ICS MEDIA https://ics.media/entry/1365/ 以下について解説されている 1. diff - 差分を見る 2. stash - 一時的に作業状態を保管しておく 3. tag - コミットにタグをつける 4. cherry-pick - 別ブランチのコミットを取得する 5. revert - コミットした内容を打ち消すコミットを作成する Git入門（VSCode Git の使い方） - セルティスラボ https://celtislab.net/archives/20180418/git-vscode/ バージョンを確認する クローン 現在のブランチ名を表示 もしくは もしくは もしくは以下なら、他のブランチは除外して表示される ブランチを切り替え（切り替えられなければ、先にプルを行う） 上記で切り替えられなければ、以下のようにする（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... プル 他人の作業ブランチを取り込み プッシュ（初回） プッシュ（2回目以降） 更新したファイルを表示 履歴を表示 プログラマは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コマンド集 - Qiita https://qiita.com/osakanaaaa/items/544343005b7ffe2a3929 ■作業ブランチを作成 現在のブランチを確認 作業ブランチとして feature/test を作成 ブランチを切り替え ブランチの切り替えを確認 ■作業内容をコミット 作業内容の差分を確認 作業内容の差分の詳細を確認 作業内容をステージに追加 ステージに追加した内容を取り消す場合 もしくは以下 ■作業内容をコミット（参考） ステージに追加したファイルが複数の場合、以下のように表示される ■作業内容をプッシュ ■作業内容をマージしてプッシュ ■ブランチの差分 ※必要に応じて「git status」も使用する 「git status」については後述している ブランチの差分を比較（詳細に表示される） ブランチの差分を比較（ファイルごとの変更量のみ表示される） ブランチの差分を比較（ファイルごとの変更有無のみ表示される） ブランチの差分コミットを比較 コミットの差分を比較 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」でも確認しておくと無難 作業の状態を確認（ブランチ名を表示） 作業の状態を確認（ブランチ名を表示しない） 差分のあるファイルを確認 差分の詳細を確認 ※取り消しは「Sourcetreeでgitを操作する（応用）」の内容も参照 PULL（デプロイ）時に競合が発生した場合、list.twig の変更のみ取り消す 直前のコミットを取り消し（作業内容は残る） 直前のコミットを取り消し（作業内容も消える） コミット後の作業をすべて取り消し 指定した時点の履歴に戻る 履歴を元の状態に戻す デプロイ済みのファイルを現在のブランチに強制一致 デプロイ済みのファイルをmasterに強制一致 デプロイ済みのファイルをdevelopに強制一致 強制的にチェックアウト プッシュを取り消す（完全に無かったことになるが、取り消し履歴も残らないので注意） 取り消した内容を他の環境に反映させる場合、 「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に間違って機密データを上げてしまった時の対処 - Qiita https://qiita.com/dynamonda/items/fa99d141c44098890be3 ■マージの取り消しについて考察 「Sourcetreeでgitを操作する（応用）」の「masterにマージしてプッシュした内容を無かったことにする（推奨手順）」を確認する 以下はそれとは別に色々と調べた内容 ■マージの取り消し（プッシュはしていない）について考察 プッシュしていなければ、以下でマージを取り消せる 間違えてマージした直後にhardの方を実行すれば良さそう 直前のコミットを取り消し（作業内容は残る） 直前のコミットを取り消し（作業内容も消える） GUIで操作するなら、戻りたいコミットを右クリックして「現在のブランチをこのコミットまでリセット」で良さそう Hardにすればマージ内容を取り消せる なお、そのままプッシュすればリモートリポジトリの内容も巻き戻せるかもしれない とはいえ、それは 「プッシュを取り消す（完全に無かったことになるが、取り消し履歴も残らないので注意）」 を実行しているのと同じのはず リモートリポジトリも含めて確認してみたい 引き続き、間違えてマージしてプッシュもしたときの対応を検証 ■マージの取り消し（プッシュもした）について考察 間違えてマージしてプッシュもしたときの対応を検証したときのメモ git merge の取り消し方法。reset と revert コマンドについて。 | WWWクリエイターズ https://www-creators.com/archives/2111 【git】マージしたけどやっぱりやめたい時のやり方4種類 - Qiita https://qiita.com/chihiro/items/5dd671aa6f1c332986a7 revertでマージの取り消しはできるものの、後からの再マージが無視されるなど色々問題がある gitでまだマージしたくない変更を間違ってmasterにマージしてしまった時の対処 - @satomikko94.b https://satomikko94.hatenablog.com/entry/2014/06/30/235603 revertのrevert（取り消しの取り消し）をすれば打ち消した内容を復元できるが、履歴も含めて管理がややこしそう 結論として「間違えてdevelopをmasterにマージしてプッシュもしてその後作業もしてしまった」ような場合は取り消しは難しそう 特定ブランチへのマージを禁止する、などで対応すべきか マンガでわかるGit 10話「masterブランチを守れ！〜危険な強制プッシュ〜」 | リクナビNEXTジャーナル https://next.rikunabi.com/journal/20170516_t12_iq/ 上記のとおり一応できるが、「featureからdevelopへのマージを一定期間だけ禁止したい」のような場合には対応が難しい 以下、色々と検証した内容のメモ 「常にこういう操作で対応できる」というものは無さそう 前提： develop から feature/test を作って作業した まだマージすべきではなかったが、feature/test を develop にマージしてプッシュもしてしまった これを取り消せるか 対処法1： developブランチに切り替えておく マージのコミットではなく、打ち消したいコミットを右クリックして「このコミットを打ち消し」としてみる developブランチからは作業内容が消えた。feature/testブランチには作業内容が残っている 本来マージすべきタイミングになってから feature/test を develop にマージしても何も起きない なぜなら「マージした」という履歴が残っているから つまり完全な取り消しができているわけでは無い 対処法2： developブランチに切り替えておく マージのコミットではなく、打ち消したいコミットを右クリックして「このコミットを打ち消し」としてみる developブランチからは作業内容が消えた。feature/testブランチには作業内容が残っている develop を feature/test にマージする これにより「打ち消し」の作業内容がマージされる 作業ブランチからも作業内容が消えているので、自身のブランチの履歴からチェリーピックで作業内容を復元する ただしチェリーピックでの復元なので、作業コミット数が多い場合は作業が大変だし履歴もゴチャゴチャする 本当の意味でのマージ取り消しにはなっていない 対処法3： developブランチに切り替えておく マージのコミットではなく、打ち消したいコミットを右クリックして「このコミットを打ち消し」としてみる developブランチからは作業内容が消えた。feature/testブランチには作業内容が残っている 本来マージすべきタイミングになってから、打ち消したコミットを右クリックして「このコミットを打ち消し」としてみる これにより、打ち消された内容を復元できる ただし「マージ間違いがあったのでコミットを打ち消したんだ」ということを覚えておかないと、間があくと「なぜかマージできない」と悩むかもしれない また、「打ち消したコミットをさらに打ち消す」前に feature/testブランチでの追加作業を取り込んでしまうとコンフリクトが発生するはず 本当の意味でのマージ取り消しにはなっていない 結局のところ、何が何でもきれいに取り消すのなら 「プッシュを取り消す（完全に無かったことになるが、取り消し履歴も残らないので注意）」 でマージもプッシュも完全に取すくらいか ただし他の人が作業を取り込んだ後だと混乱するので、「絶対に他の人が作業を取り込んでいない」と断言できる状態でのみ使えるものだと思われる また、必要なコミットが本番環境で消えたりすると問題なので、やはり原則使わない方が無難 公開リポジトリで不特定多数に公開するなら、知っておくといい 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される （複数のリポジトリを持っている場合、フォーク先を確認される） ※Bitbucketの場合、対象リポジトリにアクセスして 「… → Fork this repository」をクリックするとフォークできる フォークの際、「Workspace」「プロジェクト」「名前」を入力する ■プルリクエストの送信 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ブランチにマージしたりする ■その他 main（master）ブランチ宛にプルリクエストが来たが、いったんdevelopブランチに取り込みたい …のような場合、プルリクエストの向き先を変更できる 【地味に便利】GitHubでPull Requestの向き先を変更する方法 - Qiita https://qiita.com/ryoichi-u/items/60d38a1054ddc09e4450 develop ブランチを master ブランチにマージする場合など、 master と develop で作業内容に差がありすぎると 1. master に切り替える 2. master をプルする という作業において、1を行なった瞬間にローカルの必要なファイルが消える可能性がある この場合、いったん別の場所に新規にクローンしてからマージしてプッシュする そのうえで、作業している環境では 1. develop のままにしておく 2. master ブランチを右クリックして「masterをフェッチ」を実行する という作業をするといい（Sourcetreeの場合） この後は通常どおり操作できる ■インデントの変更を無視して差分を確認する GitHub・Bitbucketとも、?w=1 を指定するとインデントの変更を無視して差分を確認できる 条件分岐の追加などによりインデントが変更され、差分が大量に発生したが、ロジックの変更はごく一部…という場合の確認が楽になる 例えばURLが以下の場合、 https://bitbucket.org/user/repo/pull-requests/1/changes/diff 以下のようにURLの最後に ?w=1 を追加すると、空白が無視して表示される https://bitbucket.org/user/repo/pull-requests/1/changes/diff?w=1 ■特定コミット間の差分を確認する 以下のようなURLで、コミットの差分を表示できる https://github.com/ユーザ名/リポジトリ名/compare/コミットAのハッシュ…コミットBのハッシュ 具体的には、以下のようなURLになる https://github.com/refirio/freo/compare/3eba2e00f4270b034c5a14c8a164b7cb3ffa0d9e%E2%80%A631073e42523... GitHub 特定のcommit間の差分を表示 - Qiita https://qiita.com/gestalt/items/fb7e0475f11788b0996b GitHub - コミット間・ブランチ間の差分(Diff)の確認方法・見方 | Howpon[ハウポン] https://howpon.com/8540 Bitbucketの場合、以下のようなURLでリポジトリのページがあり、Sourcetreeが無くてもここからマージ作業ができる https://bitbucket.org/xxx/yyy marge_test1 ブランチを develop ブランチにマージする場合のメモ ブランチ → （任意のブランチ名をクリック） から、ブラウザ上でマージなどを行える 「対象を変更」リンクから必要に応じて対象を変更し、「マージ」ボタンを押すとコメントとともにマージができる コメントは「marge_test1 を develop にマージしました。」のような初期値が入力済になっているので、基本的にこのままでいい なお、マージしようとしている内容にコンフリクトがある場合、「マージ」ボタンを押した際に以下の警告が表示される 以下の方法でやり取りできるようだが、癖があってエラーになることがあるみたい？未検証 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 フック https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-G... Git フックの基本的な使い方 - Qiita https://qiita.com/noraworld/items/c562de68a627ae792c6c 【実践式】Gitフックを使ってミスを減らす方法｜Career Supli https://careersupli.jp/work/githooks/ 追加の依存パッケージなしでプロジェクトごとのGitコミットフックを設定する方法 | Web Scratch https://efcl.info/2021/08/21/git-precommit-hook/ 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.git ↓ https://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できるよう設定してものとする 以下は作業例 ■譲渡 譲渡元でリポジトリの譲渡作業を行う 「Repository settings → Manage repository」から、譲渡先のIDを入力する 譲渡先でメールを受け取ると、以下の内容が書かれているので許可する （「以下のグループは」の下には何も書かれていなかった） 許可すると「リポジトリは譲渡されました。」と表示される この時点で、旧URLにはアクセスできなくなる 譲渡先では以下のURLでアクセスできるが、譲渡元は権限が無いのでアクセスできない 譲渡先で「ユーザーとグループのアクセス権」を与えれば、もちろんアクセスできるようになる https://bitbucket.org/hanako/test ■譲渡後の設定（Sourcetree） SourcetreeでPULLすると、リポジトリが見つからない（移動した）ため以下のエラーになる Sourcetreeで「設定 → origin → 編集 → URL/パス」を以下のように変更して「OK」すると、PULLできるようになる https://taro@bitbucket.org/taro/test.git ↓ https://taro@bitbucket.org/hanako/test.git ■譲渡後の設定（サーバ） サーバ上でPULLすると、リポジトリが見つからない（移動した）ため以下のエラーになる 以下の手順でリポジトリの参照先を変更すると、PULLできるようになる 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で扱えないファイルがある SourcetreeでCloneしようとすると以下のエラーになった（Windowsの通常領域とWSL2領域で発生） 一応、以下の操作をするとSourcetree上で作業履歴は表示されるようになった ただし「docker/chrome/keys/keys_dir.」を扱うことができないようで、 このファイルをステージに追加したり削除したりしようとすると、やはり以下のエラーになる これは警告のとおり「keys_dir.」が原因 Windowsではピリオドで終わるファイルを扱うことができないため 該当するファイルを削除するか、ファイル名を変更することで扱えるようになる ■他の人の変更内容を取り込むと、手元で変更していないのに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 - 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を行おうとすると以下のエラーになった リモート側でファイルが編集された場合などに、競合が発生している として、該当ファイルの編集をリセットしておくと大丈夫だった もしくは若干強引だが、 として、強制的にブランチの内容をリポジトリと一致させると大丈夫だった この場合は develop ブランチに強制一致させるので、他のブランチの場合は適宜コマンドを調整する ■「The following untracked working tree files would be overwritten by merge」と表示されてPULLできない pullを行おうとすると以下のエラーになった リモート側でファイルが作成された場合などに、競合が発生している として、該当ファイルを削除しておくと大丈夫だった もしくは若干強引だが、 として、強制的にブランチの内容をリポジトリと一致させると大丈夫だった この場合は develop ブランチに強制一致させるので、他のブランチの場合は適宜コマンドを調整する ■「error: cannot lock ref」と表示されてPULLできない pullやfetchを行おうとすると以下のエラーになった リモート側でブランチが削除された場合などに発生するみたい としてから再度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」を実行すると、最後に「Already up-to-date.」が表示されるようになった 念のため再度 と実行することで、以降は正常に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 を、本番環境の領域に移動させる とすることで復旧できた 具体的には として別のフォルダにCloneしたあと、問題が発生しているリポジトリの領域にて のようにすることで解決できた 以下は、上記を行う前に色々と検証したときのメモ 検証のためにCloneする リポジトリをバックアップしておく ルート権限で以下のファイルを「test」に書き換えてみる（意図的にファイルを壊してみる） PULLしようとすると以下のとおりエラーになる もっと大量に（5000byteほど）書き込んでみる PULLしようとすると以下のとおりエラーになる 以下を実行しても結果は同じだった ファイルを直接編集して正しい内容に戻すと、エラーは表示されなくなる 以下でも戻すことができる 以下でも戻すことができる .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に認証情報を追記する」で解決できたことがあった ■「Please enter a commit message to explain why this merge is necessary,」と表示されてPULLできない サーバ内でpullを行おうとすると、以下のメッセージが表示になった git merge実行時に「Please enter a commit message to explain why this merge is necessary」が表示される | mebee https://mebee.info/2021/03/02/post-30147/ 「コミットメッセージを入力して」という内容のようなので、「:q!」として終了するとPULLは完了している ■「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」と表示されてGitHubからPULLできない We updated our RSA SSH host key | The GitHub Blog https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/ `git push`しようとしたら`WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!`が出た時の対処ログ https://zenn.dev/fujishiro/scraps/9dcbd03aa608ae 突然以下のようなエラーが表示されるようになった GitHubが秘密鍵を不用意に公開してしまったらしい 対策として鍵を交換したので、PULLするサーバ側でも鍵の変更が必要らしい 解説を元に対応したが、known_hosts にはドメインに加えてIPアドレスも追加する必要があった ■「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」と表示されてBitbucketからPULLできない 基本的にはGitHubと同じ現象で、同じ対応が必要 ACTION REQUIRED: Update your Bitbucket Cloud SSH Host Keys - Bitbucket https://bitbucket.org/blog/ssh-host-key-changes 公式の解説ページのうち、主に「WHAT YOU NEED TO DO」部分を参考に作業する ただしこれだけだと、PULLのたびに毎回確認が表示される known_hostsでBitbucketのドメインに続いて、上に表示されたIPアドレスを指定する。（3行ある。） これで対応は完了 サーバは上記で対応できたが、SourcetreeでPULLやPUSHが実行できないようになった Sourcetreeで「ツール → オプション → 認証」を選択 Bitbucketのアカウントを選択 しばらく待つと「ログイン失敗」と表示される 「パスワードを再読み込み」ボタンをクリックしてみる 「認証に成功」と表示された 「OK」ボタンでダイアログを閉じる 再度PULLしてみる…が、状況は変わらず Sourcetreeを再起動しても変わらず 以下からアプリパスワードを再発行してみるが、状況は変わらず https://bitbucket.org/account/settings/app-passwords/ ターミナルからgit pullを実行。パスワードは、再発行したアプリパスワードを入力 とても重いが、PULLできることがある ob-websys.さんはTwitterを使っています: 「朝からbitbucketから「認証キー変えといたのねん」と届いて確認…やっぱり接続できん 検索してレジストリ消してコマンド打ってキャッシュ作って接続確認できた」 / Twitter https://twitter.com/tobtks/status/1671307211136720897 上記を参考に、コマンドプロンプトから以下を実行しても変わらず Sourcetreeで「設定 → origin → 編集 → URL/パス」を以下のように変更すると問題が解消した https://refirio@bitbucket.org/refirio/example.git ↓ https://bitbucket.org/refirio/example.git PULLしようとすると、ユーザ名とパスワードを聞いてくる 何度か認証を試みると、成功することがあった URLを元に戻しても、PULLできるようになっていた 他のリポジトリもPULLできるようになっていた 認証情報を変更したことにより、古い情報のキャッシュが削除されたのか ただしGibHubのリポジトリに比べると、通信時間が結構長い なお、ECSからBitbucketのソースコード参照は問題無かった ■「You have divergent branches and need to specify how to reconcile them.」と表示されてBitbucketからPULLできない サーバ内でPULLを実行してエラー内容を確認 Gitの警告"You have divergent branches and need to specify how to reconcile them."は、pull時分岐したブランチに対する設定を明確にすることで解決する。 - appbirdNotebook https://scrapbox.io/appbirdNotebook-public/Git%E3%81%AE%E8%AD%A6%E5%91%8A%22You_have_divergent_branc... サーバにインストールされているGitのバージョンは以下のとおり Git ver 2.27.0 から、 「分岐しっ放しの複数の[ブランチ]があるため、それらに対してどう操作(調節)を行うか、挙動を明確にしなければなりません。」 となったらしい 以下の対応を行った。以降は問題なくPULLできるはず。 ■GitHubやBitbucketに接続できない GitHubの障害情報が以下にある GitHub Status https://www.githubstatus.com/ Bitbucketの障害情報が以下にある Atlassian Bitbucket Status https://bitbucket.status.atlassian.com/ ■GitHubで認証できない GitHubがパスワード認証を廃止するらしいので - Qiita https://qiita.com/shiro01/items/e886aa1e4beb404f9038 突然GitHubにpushできなくなった解決方法 - Qiita https://qiita.com/anaqe3/items/018c6fc24c9658ea2250 個人アクセストークンを使用する - GitHub Docs https://docs.github.com/ja/github/authenticating-to-github/keeping-your-account-and-data-secure/crea... Githubから届いたDeprecation Noticeメールに対応する - Qiita https://qiita.com/hiro5963/items/da0b9bcfa512bf0cb833 Homebrew使用後、GitHubから「Deprecation Notice」メールが来た話 - Qiita https://qiita.com/nafuka/items/cfcf9b35163e3146dc84 GitHubでhttpsのパスワード認証が廃止された。Please use a personal access token instead. - Qiita https://qiita.com/shunsa10/items/e43564cf48f84b95455b GitHubは2021年8月13日以降はパスワードではなくアクセストークンでの認証が必要になる 具体的には、以下のようにPULLはできるがPUSHができなくなる（対象が非公開リポジトリの場合、PULLもできなくなる） この場合、GitHubにログインしてトークンを発行する必要がある Setting → Developer settings → Personal access tokens → Generate new token 一例だが以下のように入力 Note: Sourcetree for Personal Expiration: No expiration Select scopes: repo (Full control of private repositories) 「Generate token」ボタンをクリック 以下のようにトークンが表示されるので、これをSourcetreeなどでパスワードの代わりに使用する トークンは作成直後しか確認できないので注意 上記で対応できたが、環境によっては ・Sourcetreeからは相変わらず「Support for password authentication was removed on August 13, 2021.」のエラーになる ・ターミナルからならPULLなどを実行できる。ただし毎回ユーザ名とパスワードを求められる という状態になることがあった この場合、以下の記事を参考にして GitHubのパスワード認証廃止でSourcetreeで403エラーが発生して解決策がわからなかったのでまとめておく - Qiita https://qiita.com/mamoru6344/items/ea4a34c8eec26bb60e69 Sourcetreeで「設定 → origin → 編集 → URL/パス」を以下のように変更すると問題が解消した https://github.com/[ユーザ名]/[リポジトリ名].git ↓ https://[アクセストークン]@github.com/[ユーザ名]/[リポジトリ名].git 具体的には以下のように変更した 恐らく、新規にPULLするときは同じ対応が必要になると思われる （ただし逆に、アクセストークンなしのURLにしないと繋がらないこともあった。よく解らず） https://github.com/refirio/levis.git ↓ https://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX@github.com/refirio/levis.git なお作業環境によっては以下のエラーが表示されたこともあったが、 鍵を切り替えるのではなくアクセストークンに切り替えることで対応できた 【解決方法(画像付き)】急に。git pushしたら「Please make sure you have the correct access rights and the repository exists.」 | 武骨日記 https://kenjimorita.jp/please-make-sure-you-have-the-correct-access-rights-and-the-repository-exists... Macで発生した SSHキーを発行して登録し直すことで解消できた ■Bitbucketで認証できない SourcetreeからBitbucketへアクセスする際、通常のパスワードではなくアプリパスワードを求められることがある この場合、Bitbucketでアプリパスワードを作成し、SourcetreeではBitbucketのパスワードではなくアプリパスワードで認証するといい 二段階認証設定したBitbucketをSourceTreeで使う | 電脳ノート https://dennou-note.blogspot.com/2019/11/bitbucketsourcetree.html GitHub - sourcetreeを導入後、プッシュしようとしたらcredentialHelperSelectorと出たんですがこれはなんですか？｜teratail https://teratail.com/questions/253792 基本的には「manager」を選択すれば良さそう ■Bitbucketで認証できない2 2022/03/10にBitbucketからPULLしようとしたら、以下のエラーが表示された アカウントパスワードでの認証は廃止され、アプリパスワードで認証するように変更されたらしい 以下で解説されている App passwords | Bitbucket Cloud | Atlassian Documentation https://ja.confluence.atlassian.com/bitbucket/app-passwords-828781300.html 二段階認証設定したBitbucketをSourceTreeで使う | 電脳ノート https://dennou-note.blogspot.com/2019/11/bitbucketsourcetree.html 以下は実際に作業した時のメモ まずは、Bitbucketでアプリパスワードを作成する 設定の「アプリ パスワード」ページを開く https://bitbucket.org/account/settings/app-passwords/ 「アプリパスワードの作成」ボタンをクリック 「詳細」Labelに「Sourcetree」と入力 「権限」はすべての項目にチェックを入れておけばいい（もしくは必要に応じて取捨選択する） 「作成」ボタンをクリック 「新しいアプリパスワード」が表示されるので控えておく （このパスワードは再表示できないので注意） 次に、Sourcetreeにアプリパスワードを設定する メニューから「ツール → オプション」を選択 「認証」タブ内に表示されるアカウントを選択し、Bitbucketのアカウントの「編集」をクリック Credentialの「認証」を「Basic」にし、「パスワードを再読み込み」をクリック 先の手順で控えていたパスワードを入力する 解説によるとこれで完了のようだが、相変わらず同じエラーが表示された 以下は引き続き作業した内容 SourceTree + Bitbucketで認証エラーが出る場合の対処方法 on Windows | TeraDas https://www.teradas.net/archives/29134/ 上記ページにある「GCMW導入と認証情報のリフレッシュ」を試すとパスワードを聞いてきた （この作業により、「Gitバージョン」が「Embeded」から「System」に変更されることになる） プルはできるようになったが、プッシュの際にブランチが表示されなくなった Sourcetreeのプッシュ時にブランチが表示されない状態を解消したい https://teratail.com/questions/217580 Sourcetreeをバージョンアップして再起動しても変化なし メニューから「ツール → オプション → Git」を選択 先の手順で「Gitバージョン」を「System」にしていたが、再度「Embeded」に変更してみた これでPULLすると「credentialHelperSelector」のウインドウが表示されたが、「manager」を選択して進めた sourcetreeを導入後、プッシュしようとしたらcredentialHelperSelectorと出たんですがこれはなんですか？ https://teratail.com/questions/253792 これで、再度プルとプッシュができるようになった ■Bitbucketで認証できない3 上にある「「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」と表示されてBitbucketからPULLできない」の 「サーバは上記で対応できたが、SourcetreeでPULLやPUSHが実行できないようになった」以降も参照 ■Bitbucketで認証できない4 Mac+Sourcetreeで発生 一度CloneやPullに成功したが、数日後に試すと「Permission denied (publickey)」というエラーが表示された macOS で再起動しても ssh agent に秘密鍵を保持させ続ける二つの方法 - Qiita https://qiita.com/sonots/items/a6dec06f95fca4757d4a Macでは鍵を作成しても、再起動すると消えてしまうらしい .ssh/config に特別な記述（後述）を行うことで、内容を保持できるようになるらしい また、作成した鍵はBitbucketに登録しておく Mac版のSourceTreeでプル/プッシュするときに「Permission denied」と言われる場合の対処方法 / icoro https://www.icoro.com/2019060710275 上記を参考にターミナルで作業 .ssh/config に以下を記述した 続いてSourcetreeのアカウント設定画面で「SSHキー」欄からキーを作成 以下のように作成されたことを確認できた Personal settingsにアクセス https://bitbucket.org/account/settings/ 「SSH鍵」にアクセスし、公開鍵「refirio-Bitbucket.pub」の内容を登録した これでPULLできるようになった …が、再起動するとまたエラーが表示されるようになった Cloneの際に「SSH」のURLを使用していたが、「HTTPS」のURLを使用するように変更した （アカウント設定の「プロトコル」も「HTTPS」に変更し、すでにClone済みのプロジェクトもURLを変更した） アプリパスワードなどを求められるかと思ったが、これでCloneできるようになった （キーチェーンのパスワードを求められたが、Macのログインパスワードを入力すると完了した） Macを再起動しても問題は無かった ■ときどき「Askpass.exe - アプリケーション エラー」と表示される ※未解決 SourcetreeやGitを操作中か否かに関わらず、ときどき以下のエラーが表示されるので調べたメモ - - - - - - - - - - Askpass.exe - アプリケーション エラー アプリケーションを正しく起動できませんでした (0xc0000142)。[OK] をクリックしてアプリケーションを閉じてください。 [ OK ] - - - - - - - - - - Askpass.exe の「アプリケーションを正しく起動できませんでした」というエラーへの対処 (仮) - Ewig Leere(Lab2) https://labor.ewigleere.net/2021/03/05/askpass_error_from_sourcetree_1/ Askpass.exe の「アプリケーションを正しく起動できませんでした」というエラーへの対処 (アカウント追加編) - Ewig Leere(Lab2) https://labor.ewigleere.net/2021/03/06/askpass_error_from_sourcetree_2/ askpassのことを書いておく - なんかかきたい https://t-cyrill.hatenablog.jp/entry/2018/02/09/205930 IntelliJ IDEA起動時にGitが古いと警告が表示されるのでアップデートしたときのメモ Gitのバージョンは以下のコマンドで確認できる Git Bashを手動でアップデートする方法【Git for Windows】 | 己で解決！泣かぬなら己で鳴こうホトトギス https://onoredekaiketsu.com/manually-update-git-bash/ Git Bashで以下を実行した 完了し、Git Bashでのバージョン表記は最新になったが、コマンドプロンプトからのバージョンは変わらなかった コマンドプロンプトから同コマンドを実行しようとするとエラーになった 【Git】インストール済みのGitをアップデートする【Windows環境】 | かずさプログラマーの雑記帳 https://kazusa-pg.com/installed-git-update/ 2.13以前だと使えないらしいので、公式サイトからダウンロードしてインストール （インストール時、古いGitを削除する旨の文言が表示されていた） これでコマンドプロンプトでのGitバージョンも最新になった また、IntelliJ IDEA起動時に警告は表示されなくなった ※未検証 GitHubの提供している断片コードの共有サービス 初めてでも分かる「GitHub Gist」の使い方【サイトへの埋め込み手順なども解説】 - 副業ベース（旧 bryog）- 副業でお金を稼ぎたい人のよりどころ https://bryog.com/how-to-use-github-gist/ Github Gistの良いところ、悪いところ - Qiita https://qiita.com/YumaInaura/items/d8ba7ce702d844f11ae0