Aさんは、Bさんのpull requestをレビューするために、Bさんがリモートレポジトリにpushしたfeature/Bブランチを自分のローカルに持ってきたい。
けれども、わざわざgit clone -b feature/B git@github.com:project-ab/git-sample.gitでレポジトリ全体をcloneしてくるのは時間がかかるし、避けたい。

リモートブランチをcheckoutしてみる

gitでリモートブランチをローカルにcheckoutするを参考に、Aさんはリモートブランチorigin/feature/Bをcheckoutしてみる¹が、うまくいかない。

MINGW64 ~/git-sample (main)
$ git checkout -b feature/B origin/feature/B

fatal: 'origin/feature/B' is not a commit and a branch 'feature/B' cannot be created from it

追跡していないリモートブランチは、まずfetchしてくる必要がある

原因は、リモートブランチorigin/feature/Bをローカルで追跡できていないから。（下図だとリモート追跡ブランチはorigin/mainとorigin/feature/Aのみ）

$ git branch -a

  feature/A
* main
  remotes/origin/HEAD -> origin/main
  remotes/origin/feature/A
  remotes/origin/main

fetchしてからcheckoutするとうまくいく。

$ git fetch origin feature/B

remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (2/2), done.
Unpacking objects: 100% (3/3), 245 bytes | 30.00 KiB/s, done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
From github.com:project-ab/git-sample
 * branch            feature/B  -> FETCH_HEAD
 * [new branch]      feature/B  -> origin/feature/B

$ git checkout -b feature/B origin/feature/B

Switched to a new branch 'feature/B'
Branch 'feature/B' set up to track remote branch 'feature/B' from 'origin'.

成功?

もっと楽な方法

リモートブランチを丸ごとすべて持ってくる。

$ git fetch

From github.com:project-ab/git-sample
 * [new branch]      feature/B  -> origin/feature/B

git checkout -b feature/B origin/feature/Bの代わりにgit checkout feature/Bとするだけで、リモート追跡ブランチからローカルブランチfeature/Bを作成し、そこへcheckoutしてくれる。

$ git checkout feature/B

Switched to a new branch 'feature/B'
Branch 'feature/B' set up to track remote branch 'feature/B' from 'origin'.

参考になる記事

• Git で「追跡ブランチ」って言うのやめましょう
• 【Git】リモートからの取得とリモートへの反映で行っていること(fetch, pull, push)
• （Git公式）3.5 Git のブランチ機能 - リモートブランチ

---

1. checkoutは主にブランチ間を行き来するコマンドなので、「リモートブランチをcheckoutする」という表現は本来あまりよろしくない。正しくは、「リモートブランチの最新コミットをfetchしてきて、リモート追跡ブランチからローカルブランチを作成し、そこへcheckoutする」と表現すべきでしょうか。しかしAtlassianの記事を見てみると、"checkout the remote branch"という表現があったり、ある程度この言い方は許容されているのかもしれません。 ↩

概要

前回に引き続きGitLabのプロジェクトの使い方について学習した内容を掲載します。
今回は以下の内容を実施していきます。
・作成したプロジェクトにテキストファイルを作成
・プロジェクトをローカルへクローン
・ローカルブランチ上でテキストファイルを修正し、テキストファイルをリモートブランチへプッシュ
・マスターブランチへマージ

作成したプロジェクトにテキストファイルを作成

まずは、前回作成したプロジェクトを開きます。
現時点ではプロジェクト上には何も入っていない空の状態となっていますので、適当なテキストファイルを追加したいと思います。

プロジェクトの「新規ファイル」を選択します。

すると以下の通りファイルの新規作成画面に移動します。
設定した項目は以下3点です。
・「File name」に任意のファイル名を入力
・黒い画面になにか入力
・コミットメッセージの「Add new file」の部分を分かりやすい文に修正
コミットメッセージ欄はデフォルトのままでも特に問題は無いですが、そのファイルに対してどういった変更を加えたか等を残しておきます。

今回は以下の通り入力しました。
入力が完了しましたら、「Commit changes」をクリックします。

「Commit changes」完了後、以下の画面に移動します。
これでプロジェクトにテキストファイルが作成されました。

プロジェクトをローカルへクローン

プロジェクト上のファイルは通常GitLab上で直接修正するのではなく、GitLabのプロジェクトをローカルにクローンし、ローカル上のファイルを修正します。
なので先程作成したテキストファイルをローカルPCにクローンします。
なお、通常Windowsの場合はそのままではGitLabのプロジェクトをクローンする事が出来ませんので、Gitに関連したツールをインストールする必要があります。
私はGit for Windowsをインストールして使用しています。
Git for Windowsのダウンロードはこちらから。
以下はGit for Windowsをインストールすると使用できるGitBashです。
※ユーザー名等は伏せています

GitLabのプロジェクトページに戻ります。
プロジェクトページの「クローン」をクリックしますと、「SSHでクローン」と「HTTPでクローン」の2種類があります。
両者の違いはクローン実施時の認証方法の違いです。HTTPの場合はクローン時にGitLabのユーザー名とパスワードを入力して認証しますので、ユーザー名とパスワードを知っていれば誰でもクローン出来てしまいます。
SSHの場合はGitLabのプロジェクトに登録した端末の公開鍵を元に認証しますので、登録されていない端末からのクローンは拒否されます。
前回SSHの公開鍵を登録していますので、今回はSSHでクローンを実施してみたいと思います。
「SSHでクローン」の右側にボードのようなアイコンがあります(青い四角の枠)ので、そちらをクリックします。

次にGit Bashに戻り、以下のコマンドを入力します。
コマンドの後ろに、GitLabでコピーしたコマンドを貼り付けて実行します。

git clone 

以下画像の様な結果となれば、無事クローン完了です。
ls -l等のコマンドでカレントディレクトリ内を確認してみると、クローンしたプロジェクト名のディレクトリが追加されていると思います。
分かりづらいかもしれませんが、水色の四角で囲ったディレクトリがクローンしたプロジェクトのディレクトリです。

上記のプロジェクト名のディレクトリへ、cdコマンドで移動します。
再びls -lを実行しますと、先程GitLab上で作成したテキストファイルが存在しています。
※ちなみにllコマンドを実行するとls -lコマンド実行時と同様の結果が返ってきます

以上でプロジェクトのクローンは完了です。
なお、プロジェクトをクローンして、プロジェクト名のディレクトリに移動した際に、パス名の右側に青い文字で(master)と表示されていました(具体的には以下画像の黄色の枠内)が、これは何かといいますと現在作業しているブランチです。

ブランチとは、枝の事を言います。一つのプロジェクトに対して複数のブランチを分ける事で複数メンバーの開発・管理がしやすくなります。
例えば現行バージョンのマスターブランチに対し、新たに機能を追加する場合にマスターブランチをクローンして開発用のブランチを切り、そこで更に細かい機能ごとのブランチを切って開発作業を行う、といった事などが可能です。(開発に携わった事が無いので詳しくはわかりませんが…)
話を戻しますと、この青文字の(master)と表示されているのは、名前通りマスターブランチ(原本)になります。
マスターブランチのまま作業をする事はあまり一般的ではないと思いますので、事前にブランチを切り替えたいと思います。
まずは以下のコマンドを入力し、現在のブランチを確認します。

git branch -a

-aオプションを追加する事でリモートブランチとローカルブランチの両方を一覧表示する事ができます。
緑文字がローカルブランチで、赤文字がリモートブランチとなっています。
ブランチ名の左に*がついているブランチが、現在のブランチです。
そしてリモートブランチに「HEAD」というブランチがありますが、これはローカルにクローンした際に参照したブランチの事を指すようです。
右側に「origin\master」とありますので、クローンした際には、masterブランチを参照したという意味合いになるようですね。

では、masterブランチから別のブランチに切り替えたいと思います。
以下のコマンドを実行し、ブランチを切り替えます。
現時点ではブランチはmasterしかないので、-bオプションを追加してブランチの作成と切り替えを同時に行います。
<ブランチ名>は今は任意の名前を入力します。今回はdevelopと入力しました。

git checkout -b <ブランチ名>

以下の通りブランチの切り替えを行うと、青枠の箇所が(master)から(develop)に変わっています。
また、git branch -aを実行すると、作成したdevelopブランチに*マークが付き、文字が緑色で表示されています。

以上でブランチの切り替えも完了しましたので、ローカル上でテキストファイルの編集を行います。

ローカルブランチ上でテキストファイルを修正し、テキストファイルをリモートブランチへプッシュ

GitLabのプロジェクトからテキストファイルをクローン出来ましたので、次はこのテキストファイルを編集し、GitLab上のリモートブランチへプッシュします。
まずはテキストファイルの編集ですが、ごく普通のテキストファイルなので、編集する手段は何でも良いと思います。
私はGitBash上からviエディタを使用し、直接編集しました。
下記画像の一回目のcat test.txtの実行結果は、編集前のtest.txtファイルの中身で、二回目のcat test.txtの実行結果はviエディタで編集した後のtest.txtファイルの中身です。
青枠内を追記しています。

テキストファイルの修正が完了したので、早速GitLab上のリモートブランチへプッシュしたいと思います。
プッシュを実施する前に以下のコマンドを入力し、変更対象のファイルを追加します。

git add <変更対象ファイル名>

<変更対象ファイル名>のところは、カレントディレクトリ内にあればファイル名を直接入力します。
ディレクトリ内にある場合は相対パスを入力します。
変更対象ファイルはgit add A.txt B.txtの様に複数入力できますし、git add .と入力すればカレントディレクトリ配下の全てのファイルを対象とする事もできます。(コンフリクトや修正発生時等、色々大変になるかもしれませんが・・・)
先程編集しました「test.txt」を追加しますので以下画像の通りaddしてみたところ、なにやらwarningが表示されてしまいました。

どうやら改行コードの問題らしく、GitLabが改行コードLFをWindowsのCRLFに自動で変換しようとしている事が原因だそうです。
以下のコマンドを実行すると自動変換を無効化できるそうなので、実行しました。

git config --global core.autoCRLF false

参考サイト様:https://normalblog.net/system/lf_replaced_crlf/

その後、再度addを実施してみましたところ、無事解消されました。

変更対象のファイル追加が完了しましたので、コミットしていきます。
コミットを実施するコマンドは以下です。

git commit -m "<コミットメッセージ>"

<コミットメッセージ>には、先程テキストファイルを作成した際に入力したコミットメッセージと同様、コミット時に残すメッセージを入力します。
全角でも問題ないと思います。
ちなみに複数コミット対象のファイルが存在する場合は、-aオプションを追加します。
今回は1ファイルしかないので以下の通りコミットしてみました。

コミット完了後、以下のコマンドを実行し、コミットした内容をリモートへプッシュします。
このoriginとははリモートブランチ、すなわちGitLab上のブランチの事を言います。

git push origin <ローカルブランチ名>

プッシュが正常に完了すると以下画像の様な表示になります。
特に「push success」みたいなメッセージが出るわけではないようです。

以上で修正したテキストファイルをリモートリポジトリへプッシュが完了です。

マスターブランチへマージ

修正した内容をマスターブランチへ反映させるためにマージを行います。
マージはWeb上で簡単に行うことが出来ます。
まずはGitLabのプロジェクトのページへ移動します。
すると画面右上に「マージリクエストを作成」というボタンが表示されていますので、クリックします。

「マージリクエストを作成」をクリックすると以下の画面に移ります。
ここでは主に「タイトル」と「Description」の項目を修正します。
タイトルはコミット時に入力したコミットメッセージが入力された状態となっています。そのままで良ければ編集不要です。
Descriptionには具体的な修正内容等を入力する為の項目となっています。
入力は強制ではありませんが、例えばmasterリポジトリへのマージ権限をもつユーザーにマージ依頼する際のレビュー等に活用できそうです。
その他の項目については余力があれば調べてみたいと思います。
入力が完了したら、「Submit マージリクエスト」ボタンを押下します。

マージリクエストを実施しましたが、まだ完了ではありません。
マージリクエスト実施後に以下の画面に移りますので、ここで「マージ」ボタンをクリックすることでマスターブランチへのマージが行われます。
なお、この画面はマージ対象をチームリーダー等のレビューを想定して作られているようで、コメントの投稿機能やマージ対象ファイルの差分確認機能等が備わっているようです。
このあたりは流石ソースコードの管理に特化しているだけありますね。

ちなみに上記画面内の「Web IDEで開く」をクリックすると、以下の画面に移動し、差分がひと目で分かるようになっています。

先程のマージリクエスト画面にて「マージ」ボタンを入力しますと、masterブランチにマージされたというコメントが追加されます。
これでマスターブランチへのマージまで完了しました。

プロジェクトのトップ画面へ戻りますと、コミットした時のメッセージが表示されています。

対象のtest.txtファイルをクリックすると、修正した内容が反映されている事がわかります。

以上でプロジェクトへテキストファイルの作成からローカルブランチ内で編集し、マスターブランチへの反映まで完了です。
次回はまだ決めていませんが、競合(コンフリクト)を発生させて、解消まで実施してみようかと思います。

monorepo に subrepo をマージ in する方法

monorepo 内での位置を決めておく

まず初めに、monorepo 内での subrepo のディレクトリを決めておく必要がある。

ここに移動したらすぐに動くはず、というのが決まっているなら、シンプルにそこを指定すれば良い。
例えば subrepo -> monorepo/library/subrepo 等になるパターン。

そうで無い場合、一旦 monorepo/temp/subrepo としてマージして、その後、順次 temp/subrepo 内のファイルを編集・各ディレクトリに移動すればよい。

まずは全てのファイルを同時に temp/xxxx にマージする のが大事。

subrepo を monorepo にマージする

以下を monorepo 側で実施

git remote add subrepo {subrepo ディレクトリへのパス}
git fetch --all

特にリモートを指定する必要は無いので、subrepo はローカルディレクトリで良い

subtree merge する

https://docs.github.com/en/free-pro-team@latest/github/using-git/about-git-subtree-merges
ここに書いてある事をそのままやればよい。

git merge subrepo/master --allow-unrelated-histories  -s ours --no-commit
git read-tree --prefix=temp/subrepo -u subrepo/master
git commit -m "Subtree merged subrepo into temp/subrepo"

このとき --allow-unrelated-histories を指定しないと fatal: refusing to merge unrelated histories で失敗する。

お好みでやっても良いこと

無駄なバイナリ履歴を削ぎ落とす

既に使われていないバイナリで、過去の履歴に残存しているものが無駄な場合、このタイミングで git-lfs に変換するとよい。

（これは追加作業でミスの恐れもあるため、移動の一環としてしれっとやるのはやめて、メンバーと相談すると良い。）

必要があれば https://github.com/git-lfs/git-lfs/blob/master/docs/man/git-lfs-migrate.1.ronn を確認して作業する。

etc. （何か思いついたら書く）

本格的に仕事で Git を使うようになってから半年が経ちました。
よく使うコマンドのまとめです。

( )がついてるものは可変部です！

リモートリポジトリ（GithubとかGitLabにあるやつ）からソースをローカルに持ってくる

$ git clone (URL)

ブランチを作る

$ git branch (ブランチ名)

今ある全ブランチ一覧を確認する

$ git branch -a

変更をステージングエリアに追加（コミット前の準備)

$ git add .

もしくは

$ git add (ファイル名)

コミットする

$ git commit -m "(コミットメッセージ)"

プロジェクトによってコミットメッセージのルールなどあるかもなので確認

リモートの master ブランチに変更があったときにローカルの作業ブランチにマージする

$ git pull -—rebase origin master

（なるべくリモートリポジトリとの差分を少なくするため、こまめにやっておくと良いらしい。）

コンフリクトがあった場合はコンフリクトを解消してから以下を実行

$ git rebase —-continue

強制的に master をマージ

①リモートの最新を取ってきておいて・・

$ git fetch origin master

②ローカルの master を、リモート追跡の master に強制的に合わせる

$ git reset --hard origin/master

リモートリポジトリにソースをあげる（プッシュする）

$ git push origin (作業ブランチ名)

作業中の変更を保存する（レビューなどで別ブランチを見たいときとか）

$ git stash save -u “(自分が分かる名前をつける)”

一つ前のコミットを取り消し（変更はそのまま残す）

$ git reset —soft HEAD~

一つ前のコミットに上書き（コミットしたあとにちょっとだけ変更したいとき）

$ git commit --amend -m “コミットメッセージ”

Git 操作をやり直したいとき（「違うコマンド実行しちゃった…」のときとか）

①git操作の履歴を見る

$ git reflog

②戻りたい番号を指定して以下実行

$ git reset --hard HEAD@{(戻りたい番号)}

【業務でSVN使っているが、今後のためにGit,GitHubと比較してみた。】

業務でSVNを使用していますが、Git,GitHubの方がメリットが多いと知りました。
そのため、業務外でGit,GitHubを使うようにしています。
後々のGit,GitHubのチーム開発に参画した時のために学習しています。

SVNを使ってはいますが、TortoiseSVNを使ってのGUIでの操作です。
コマンド操作は一切していません。
そのため、混乱せずにGitを学んでいけそうです。

（私の主観的な側面が多い記事になってしまっています。ゆるくご覧頂けると嬉しいです。）

Git　世界標準

ソースコードのバージョンを管理するツール。
分散型バージョン管理システム。
Macには、標準搭載されている。

GitHub　個人の作業をバージョン管理できる。

「Git」を利用した開発支援のWebサービス
GitHub以外にも類似のWebサービスは存在している。
開発者がローカルでソースのバージョンを管理することが可能。

※SVN　チームの成果しか管理できない。

集中型バージョン管理システム。
１コミットをハードルが高い。
また、エラーを特定する際にわかりにくい。
→これといって、メリットがわからない。

Git コミット（ローカルリポジトリ）してから、プッシュ（リモートリポジトリ）へ
　作業単位で気軽にコミットできる。
　他の開発者と競合しない。

SVN　（リモートリポジトリ）
　競合する。赤色警告？的なのが表示される。
　Gitよりは気軽にコミットしにくい。（一時コミット用にブランチを作成することでコミット可能）

→結論、Gitが世界標準であるため、SVNについて深く学ぶ必要はない(?)のかなと思いました。
UdemyでGitの教材を購入して、プログラムの勉強をしつつGitの学習もしています。

余談

GitとSVNを比較して、SVNの方が優れている点はないように感じました。
もし、SVNの方が優れているところなどありましたら、教えていただきたいです。

（正直、とても内容が薄いです。。自分が短期間に調べた結果、分かった内容です。）

エラー発生

git pushしたところ下記のエラーが発生

$ git push origin master
To https://github.com/xxx/xxx.github.io.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://github.com/xxx/xxx.github.io.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

対処法

GitHubへのpushが「fetch first」と表示されてrejectedとなったときの対処
上記記事が大変参考になったが、説明が最初で結論が最後だったため若干戸惑った点があったので、本稿では結論のみに絞って書きたい。

1.git statusで状況を確認する。

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)

    both added:      index.html

index.htmlがマージされていないのでgit addとgit commitをしろとのこと。

2.$ git add index.html
3.$ git commit -m "2nd commit"
4.$ git push origin master

※適宜git statusで状況を確認するとよい。

git branch --merged|egrep -v '\*|develop|master|main'|xargs git branch -d

こんにちは、くりぱんです。

この記事で実現できること

1. Githubにコードをアップロードできる
2. Github Desktopにアップロードしたリポジトリを追加できる

開発環境

• OS：MacOS
• Git：2.29.2

説明

私は個人開発や個人学習のために、Githubへコードをアップロードしています。
また、コードを簡単に管理できるように、Github Desktopを使用しています。
今回は、Githubへコードをアップロードしてもらい、Github Desktopを使用してコードを管理できるようにする方法を説明していきます。

簡単実装

実装準備

Githubのアカウントを下記から取得してください。
https://github.com/

Github Desktopを下記からダウンロードしてください。
https://desktop.github.com/

Github

• まずは、Newをクリック
  

• ①にfirst_githubと入力して、②のCreate repositoryをクリック
  ※ ①のfirst_githubは任意の名前で大丈夫です。
  

• Set up in Desktopをクリック
  

• GitHub Desktop.appを開くをクリック
  

• Choose...をクリック
  

• Finderで今回アップロードするコードが入ったフォルダを選択し、開くをクリック
  私の場合は、今回/Applications/MAMP/htdocs/first_githubというLaravelのプロジェクトをGithubにアップロードするので、'first_github'を選択しています。
  

• パスを確認して、OKならCloneをクリック
  

• 右上に今回追加したfirst_githubのリポジトリがGithub Desktopに追加されているのがわかります。
  

これで自由にコード管理ができるようになります！
Github Desktopは、とても簡単に操作できるのでぜひ使ってみてください！

最後に

コマンドなしでGithubにコードをアップロードして、Github Desktopでコマンドなしでコミットやマージなど何でもできます。初学者の方にも扱いやすいので、ぜひ良いコード管理ライフをお楽しみください！

Twitterもやってます！
プログラミングや金融知識、英語、エンジニアの現実についてつぶやいています！
よかったら見てみてくださいね！

https://twitter.com/sakuslife