GitHubで共同開発をしていると、フォークしてから作業をするという形で作業することが多くなるかと思います。 その際、フォーク元のリポジトリに差分が生じてしまうとgit pullでは差分を取り込むことができません。 そこで今回はフォーク元の差分を自身のリポジトリに反映させる方法を書きます。 手順 まずは正しくupstream先が登録されているか確認します。 $ git remote -v origin git@github:private/hoge.git (fetch) origin git@github:private/hoge.git (push) upstream git@github:work/hoge.git (fetch) upstream git@github:work/hoge.git (push) もしupstream先を登録できていない場合は下記コマンドで登録します。 $ git remote add upstream git@github:work/hoge.git 後はupstream先の最新をfetchで追いかけて自身のリポジトリにマージします。 $ git fetch upstream $ git merge upstream/master 意外と調べてもピンポイントで記事が出てこなかったので書きました。
GitHubで共同開発をしていると、フォークしてから作業をするという形で作業することが多くなるかと思います。
その際、フォーク元のリポジトリに差分が生じてしまうとgit pullでは差分を取り込むことができません。
git pull
そこで今回はフォーク元の差分を自身のリポジトリに反映させる方法を書きます。
まずは正しくupstream先が登録されているか確認します。
$ git remote -v origin git@github:private/hoge.git (fetch) origin git@github:private/hoge.git (push) upstream git@github:work/hoge.git (fetch) upstream git@github:work/hoge.git (push)
もしupstream先を登録できていない場合は下記コマンドで登録します。
$ git remote add upstream git@github:work/hoge.git
後はupstream先の最新をfetchで追いかけて自身のリポジトリにマージします。
$ git fetch upstream $ git merge upstream/master
意外と調べてもピンポイントで記事が出てこなかったので書きました。
はじめに GitHubのデフォルトブランチがmasterからmainに変更されました。 理由等は以下の記事を参考にしてもらえるとmainに変更された理由がわかります。 GitHub、これから作成するリポジトリのデフォルトブランチ名が「main」に。「master」から「main」へ変更 － Publickey これに準じて、ローカルリポジトリもmasterからmainに変更したほうがいいなと感じることがあります。 例えば、masterのままでいると、first commitでリモートのmainブランチに直プッシュをしたくてもリモートにmainブランチを作成してからプルリクエストを出してマージする手順が必要になります。 これを続けているとかなり面倒くさいです。ですが、ローカルリポジトリのデフォルトブランチをmasterからmainに変更することで面倒くささがなくなり、mainのリポジトリに直プッシュできます。 以下で、デフォルトブランチをmasterからmainに変更する方法を載せます。 ローカルのデフォルトブランチをmasterからmainに変更する方法 変更するにあたって行う手順は2つだけです。 Gitのバージョンをアップデートする git configでデフォルトのブランチを変更する Gitのバージョンをアップデートする 最新にする前に、Gitのバージョンを確認してください。 Gitのバージョンが 2.28.0 以降でしたらコマンドでデフォルトのブランチ名を変更できるため、バージョンをアップデートする必要はありません。次に進んでください。 Macユーザーの場合 Homebrewなどでアップデート等する必要があるので、以下の記事等を参考にしてアップデートしてください。 最新の Git を Mac にインストールする手順 - Qiita macOS git を update したメモ - Qiita Windowsユーザーの場合 GitBashやコマンドプロンプト等を用いて以下のコマンドを打ち込むことでアップデートが可能です。 $ git update-git-for-windows 筆者は、以下の記事を参考にアップデートすることができました。 【Git】インストール済みのGitをアップデートする【Windows環境】 | かずさプログラマーの雑記帳 git configでデフォルトのブランチを変更する 以下のコマンドを打ってもらえるとデフォルトのブランチ名を変更できます。 $ git config --global init.defaultBranch main これでデフォルトブランチの変更が完了です。 実際にローカルリポジトリを作成してステージングしてコミットした後に git branch で確認すると、作成されたブランチがmainに変更されています。 （補足）作成したmasterブランチをmainに変更する方法 $ git branch -m master main これで変更が可能です。 すでにブランチを作ってしまった場合はこれで変更可能です。 参考記事 Highlights from Git 2.28 - The GitHub Blog
GitHubのデフォルトブランチがmasterからmainに変更されました。 理由等は以下の記事を参考にしてもらえるとmainに変更された理由がわかります。
GitHub、これから作成するリポジトリのデフォルトブランチ名が「main」に。「master」から「main」へ変更 － Publickey
これに準じて、ローカルリポジトリもmasterからmainに変更したほうがいいなと感じることがあります。 例えば、masterのままでいると、first commitでリモートのmainブランチに直プッシュをしたくてもリモートにmainブランチを作成してからプルリクエストを出してマージする手順が必要になります。
これを続けているとかなり面倒くさいです。ですが、ローカルリポジトリのデフォルトブランチをmasterからmainに変更することで面倒くささがなくなり、mainのリポジトリに直プッシュできます。
以下で、デフォルトブランチをmasterからmainに変更する方法を載せます。
変更するにあたって行う手順は2つだけです。
最新にする前に、Gitのバージョンを確認してください。 Gitのバージョンが 2.28.0 以降でしたらコマンドでデフォルトのブランチ名を変更できるため、バージョンをアップデートする必要はありません。次に進んでください。
Homebrewなどでアップデート等する必要があるので、以下の記事等を参考にしてアップデートしてください。
GitBashやコマンドプロンプト等を用いて以下のコマンドを打ち込むことでアップデートが可能です。
$ git update-git-for-windows
筆者は、以下の記事を参考にアップデートすることができました。
【Git】インストール済みのGitをアップデートする【Windows環境】 | かずさプログラマーの雑記帳
以下のコマンドを打ってもらえるとデフォルトのブランチ名を変更できます。
$ git config --global init.defaultBranch main
これでデフォルトブランチの変更が完了です。
実際にローカルリポジトリを作成してステージングしてコミットした後に git branch で確認すると、作成されたブランチがmainに変更されています。
git branch
main
$ git branch -m master main
これで変更が可能です。 すでにブランチを作ってしまった場合はこれで変更可能です。
Highlights from Git 2.28 - The GitHub Blog
Git利用時のフローはどれを使うか - Qiita Pete HodgsonさんのFeature-togglesが面白かったので翻訳してみた - Qiita GitLab flowから学ぶワークフローの実践 | POSTD 2019年のDevOps/MLOpsエンジニアの標準的スキルセット - Qiita
Git利用時のフローはどれを使うか - Qiita
Pete HodgsonさんのFeature-togglesが面白かったので翻訳してみた - Qiita
GitLab flowから学ぶワークフローの実践 | POSTD
2019年のDevOps/MLOpsエンジニアの標準的スキルセット - Qiita
global:プロジェクトをまたいだ全体の設定 現在の状態を確認 $ git config -l ユーザ名の設定 $ git config --global user.name "ユーザ名" メールアドレスの設定 $ git config --global user.email メールアドレス
global:プロジェクトをまたいだ全体の設定
$ git config -l
$ git config --global user.name "ユーザ名"
$ git config --global user.email メールアドレス
コードレビュー時に意識するべき観点を、最下部の資料からまとめました。 自分への戒めとして、記しておきます。 考慮に入れるべきこと レビューの目的はなにか、チーム内でコンセンサスを取る 「コードレビューが完了したときに、どういう状態になっていれば成功なのか」を意識する。 指摘を受けて修正する場合、優先順位を検討する。 自分の指摘にはどれくらい実現可能性があるか 指摘を反映した場合に、プロジェクト全体にどんなメリットがもたらされるか ソースコードの基本は、「将来的に必要になる修正・対応コストを削減する」こと。 メンバー同士の知識がチームに共有されることで、技術レベルが向上する 「どんな勉強をすれば、コードレビューで受けた指摘を改善しやすくなるか」もセットで教える 初学者は、どういう勉強をすればいいかそもそもわからない場合があるので、学習方法についても案内する。 また、パブリックな場で教えることで、知識を共有し合う文化の形成につながる。 ソースコードのいい部分には「いいね！」という 良いコードやいい指摘を目にしたら、積極的に「いいね」とコメントする。 フィードバックとは、悪い部分を改善するためだけではなく、いい部分を伸ばすためにでもある。 「最悪を最初に」 影響範囲が広い、手戻りコストが高くつく、失敗するようなリスクがないか確認する。 残りを適切な順序でみる。 資料 コードレビューを成功させるためにCTOが考えるべき7つのことー監修：高遠和也（株式会社LIG CTO） | FLEXY（フレキシー） https://flxy.jp/article/4298 コードレビューのイロハをまとめました（レビュイー/レビュアー両者の心得や実践的なテクニックなど） - Qiita https://qiita.com/hariNEzuMI928/items/5e3d96a069e075e37720
コードレビュー時に意識するべき観点を、最下部の資料からまとめました。 自分への戒めとして、記しておきます。
初学者は、どういう勉強をすればいいかそもそもわからない場合があるので、学習方法についても案内する。 また、パブリックな場で教えることで、知識を共有し合う文化の形成につながる。
良いコードやいい指摘を目にしたら、積極的に「いいね」とコメントする。 フィードバックとは、悪い部分を改善するためだけではなく、いい部分を伸ばすためにでもある。
影響範囲が広い、手戻りコストが高くつく、失敗するようなリスクがないか確認する。
残りを適切な順序でみる。
コードレビューを成功させるためにCTOが考えるべき7つのことー監修：高遠和也（株式会社LIG CTO） | FLEXY（フレキシー） https://flxy.jp/article/4298
コードレビューのイロハをまとめました（レビュイー/レビュアー両者の心得や実践的なテクニックなど） - Qiita https://qiita.com/hariNEzuMI928/items/5e3d96a069e075e37720
