エラー

背景：
1、既にgitにpushしたリポジトリB(最新のもの)にあります。リポジトリBは他の方で作成したもの。現時点は自分のローカルにはないです。
2、既にgitにpushしたリポジトリA(過去のもの)にあります。リポジトリAは自分で作成したもの。現時点は自分のローカルにあります。
3、リポジトリBにリポジトリAのコードを取り込みたいです。
4、ローカルで　$ git clone リポジトリB でリポジトリBをcloneしました。
5、ローカルで　リポジトリAを　リポジトリBのディレクトリの下にコピーしました。
6、リポジトリBのディレクトリで　$ git add .　　を実行する時に、下記のエラーが発生した。

$ git add .
warning: adding embedded git repository: リポジトリ名
hint: You've added another git repository inside your current repository.
hint: Clones of the outer repository will not contain the contents of
hint: the embedded repository and will not know how to obtain it.
hint: If you meant to add a submodule, use:
hint: 
hint:     git submodule add <url> リポジトリ名
hint: 
hint: If you added this path by mistake, you can remove it from the
hint: index with:
hint: 
hint:     git rm --cached リポジトリ名
hint: 
hint: See "git help submodule" for more information.

原因

原因：cloneしたリポジトリBはリポジトリAのものを取り込んできていました。

解決策

色々試したが、下記の通りにうまくできました。あまり技術的にならないですが、、(1~4は上記の背景と同じ内容です）

1、既にgitにpushしたリポジトリB(最新のもの)にあります。リポジトリBは他の方で作成したもの。現時点は自分のローカルにはないです。
2、既にgitにpushしたリポジトリA(過去のもの)にあります。リポジトリAは自分で作成したもの。現時点は自分のローカルにあります。
3、リポジトリBにリポジトリAのコードを取り込みたいです。
4、ローカルで　$ git clone リポジトリB でリポジトリBをcloneします。
5、gitにあるリポジトリAはローカルでリポジトリBのディレクトリに直接のコピーではなく、リポジトリAをgitからzip fileの形でリポジトリBのディレクトリにdownloadしてください。
6、downloadしたリポジトリAを展開します。zip fileを削除します。
7、再び　$ git add .　を実行すれば、うまくできました！

参考

git add .で警告。warning: adding embedded git repository: を参考しました！

GitHubのサポートチームに連絡して、
二段階認証を解除してもらう。

　前提

SSH接続ができるよう設定されていることが必須。
GitHub – SSH接続の設定方法

　手順

　① コマンド

ターミナルにて、以下を入力。

ssh -T git@github.com verify

表示されるメッセージは、あとで使う。

// 表示されるメッセージ?
Please provide the following verification token to GitHub Support.
AOD6ZCPYBAVKMNZGUZZPUHGYAVJYHHAFM3W74.....　//　以下省略。

　② GitHubサポートページ

Help with your GitHub accountにて、必要事項を英語で入力。

終えたら、Send Request。

以上。
GitHubサポートにより、二段階認証が削除されます。

　補足

英文コピペシート。

　subject

2-step verification process Trouble

　How can we help?

I lost authentication application and my recovery code. Please remove the 2-Step Verification process from the account.

// 以下、ご自身のターミナルを貼り付けて下さい。?

ssh -T git@github.com verify
Please provide the following verification token to GitHub Support.
AOD6ZCPYBAVKMNZGUZZPUHGYAVJYHHAFM3W74.....　//　以下省略。

おしまい。

はじめに

本記事は、JavaのFWを開発するプロジェクトにおいて、モノレポ開発のメリットを享受する為のリポジトリ運用について考える記事です。

モノレポとは

端的にいって、モジュールを横断してコードを一つのリポジトリで管理しようというリポジトリの運用戦略です。モノレポの考え方として下記の2つがありますが、本記事では後者について考えます。

1. 企業のコード全てを1つのリポジトリで管理しようとする考え方
2. プロジェクトのモジュール全てのコードを1つのリポジトリで管理しようとする考え方

これってモノレポでは？

私の所属するチームでは、JavaのFWを開発しています。FWはいくつかのモジュールから構成されており、それらのモジュールは1つのGitリポジトリで開発されていました。何故こういったリポジトリ構成になったのか、チームに経緯を確認した所、製品として品質保証したい範囲でリポジトリを作成した為とのことでした。
当時、Gitの経験が浅かった私は違和感を抱かなかったのですが、どうやらこういったリポジトリの運用をモノレポと言うらしいので、モノレポ運用のメリットを活かせている運用か調べてみることにします。

モノレポのメリット

モノレポ開発の為のツールセットであるNxのドキュメントを参考にすると、モノレポ運用をすることのメリットとして挙げられるのは下記の4点です。

1. コードが全て同じリポジトリにあり、互いに参照できるため、コードの再利用がしやすい。
2. モジュール変更の影響が同じリポジトリ内で完結し、1PRで解決できる。
3. 異なるツールや技術を利用したモジュール群のビルドやテスト手順を一貫したものにできる。
4. モジュール毎の依存を単一のセットに固定でき、後になって依存関係の競合に悩まされない。

チームのJavaリポジトリを顧みる

下記の2点から、リポジトリはモノレポのメリットを享受できていると言えそうです。実際のところ、機能の開発・修正に伴って、あちこちのリポジトリにPRを投げるようなことはないですし、連結テストになって依存関係に悩まされることもありません。

1. 製品を構成するモジュールが同一リポジトリで管理

モジュール群はテストコードを含め、同一のリポジトリで開発されており、互いに参照されるとともに、変更の影響を確認できます（※画像の構成はイメージ）。GitLab CI/CDのように、リポジトリにパイプラインジョブを定義するファイル（.gitlab-ci.yml）が含まれる場合、パイプラインジョブの再利用がしやすいこともメリットとして挙げられますね。

2. 依存関係はgradleファイルで一意に管理されている

製品の依存関係は単一のgradleファイルで管理されています。

dependencies {
    implementation("org.aspectj:aspectjrt:1.9.4")
    implementation("org.aspectj:aspectjweaver:1.9.4")
    implementation("com.fasterxml:classmate:1.4.0")
    implementation("commons-beanutils:commons-beanutils:1.9.3")
    implementation("commons-betwixt:commons-betwixt:0.8") {
        exclude module: "commons-beanutils-core"
    }
    // 中略
}

モノレポの運用

上述の通り、チームはモノレポのメリットを受けられていることを確認できました。
次はモノレポのメリットを最大化し、モノレポの運用課題に対処するために、モノレポ運用の検討事項について考えてみます。
こちらは参考文献を基に記載しています。参考文献については、本記事の末尾に記載しているので、こちらもご参照ください。

1. 物理的なリポジトリサイズの増加にどう対処するか
全てのコードが単一のリポジトリで管理される都合上、リポジトリが肥大化します。サイズはもちろんのこと、ビルドやテストにかかる時間の増加への対処を検討する必要があります。一般的に、影響範囲のみのビルドやテストを実施するよう制御します。

2. いじられたくないモジュールをどう守るか
全てのモジュールが単一のリポジトリに格納されると、別チームにモジュールを破壊される可能性があります。モジュールに対してチーム毎に制御を設けることなどが検討されます。

3. 各モジュールに対して単一の規格をどれだけ浸透させられるか
モジュール毎にコーディングスタイルや品質の管理基準、依存セットが異なっていると、モノレポのメリットは失われ、管理が煩雑になります。対処方法としてデファクトスタンダードの規格をモジュールに強制するアプローチなどが取られます。

4. モジュールの変更を素早くリポジトリ全体に浸透させられるか
モノレポ運用のメリットは、全てのモジュールの最新コードを全ての開発者が参照できることに依る所が大きいです。したがって、リポジトリの運用として、CI/CDを前提としたトランクベース開発が好ましいと考えられます。

チームのJavaリポジトリ運用を顧みる

モノレポの運用と比較して、チームのリポジトリ運用の評価は下記の通りです。

1. リポジトリと開発チームは巨大ではない。
2. プロジェクトの性質として、多数のチームが参加して開発するものではない。
3. 製品として重厚な品質管理が規定、一定の規格がモジュール間で統一されている。
4. featureブランチによる開発。

チームでは、品質管理のCI/CD化を進めることでコードの変更反映を速めています。加えて、少数チームでの開発で、開発者がリポジトリ全体を掌握しきれている為、リポジトリサイズや開発規模に起因する課題は生じていないという状況だといえるでしょう。

まとめ

モノレポで開発することのメリットと運用方法について説明し、チームのモノレポとその運用について確認しました。結論として、チームのリポジトリは、モノレポ運用に関して大きな課題はなく、メリットを受けつつ開発を進められているという結論でした。
少数チームで開発するリポジトリにおいては、モノレポにすることで生じる課題はあまりないと言えるのではないでしょうか。

余談ですが、レポジトリとリポジトリが並ぶと少々違和感がありますね。

参考文献

モノレポに関して、下記の参考文献をもとにメリットや運用の検討について述べています。

• Nxのドキュメント：https://nx.dev/angular/getting-started/why-nx
• Misconceptions about Monorepos: Monorepo != Monolith：https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c
  • 翻訳：https://www.graat.co.jp/blogs/ck1099bcoeud60830rf0ej0ix
• Monolith→MultiRepo→MonoRepoでの リポジトリ戦略：https://slides.com/kotamat/repository-strategy

はじめに

git stash を使用すると、作業コピーに加えた変更を一時的に棚上げし、他の作業をした後で戻って再適用することができます。
なので作業ブランチを間違えた場合はgit stashを使用します。

変更内容をstashする

変更内容を違うブランチに移動するコマンドは下記の通りです。

ターミナル

$ git stash -u             // オプションで"-u"をつけるとuntrackファイルも全てスタッシュできます
$ git checkout [ブランチ名]   // ブランチ移動
$ git stash pop              // 最新のスタッシュを適用し、削除する

git stashの詳細は下記を参照してください。
色々な git stash
gitで未追跡（untracked)なファイルもまとめて退避(stash)する

終わりに

gitの使い方を他にも書いていますので良かったら参考にしてください。
gitの使い方
gitのブランチ作成〜リモートへの登録
【git】ブランチ名の変更方法(ローカル、リモート)

はじめに

gitのブランチ名を間違えてしまったという場合の対処法をまとめました。(ローカル、リモートそれぞれ)

ローカルブランチ名の変更

ターミナル

$ git branch -m 古いブランチ名 新しいブランチ名

// 今いるブランチの名前を変更する場合
$ git branch -m 新しいブランチ名

リモートブランチ名の変更

リモートブランチ名に関しては厳密に言うと変更ではないかもしれません。
直接、名前を変更するのではなく、名前を変更したブランチを新たにpushします。
なのでPRとかコードへのコメントとかは新しいブランチにはないのでご注意ください。

手順としては、
1. ローカルのブランチ名を変更
2. 変更したブランチを新たにリモートへpush
3. 間違えてpushしたリモートブランチを削除

実際のコマンドは下記の通りです。

ターミナル

$ git branch -m 古いブランチ名 新しいブランチ名
$ git push -u origin 現在のブランチ名      // $ git push -u origin HEAD とするとブランチ名を入力しなてもpushできるので便利です。
$ git push origin :リモートのブランチ名

おわりに

gitの使い方を他にも書いていますので良かった参考にしてください。
gitの使い方(git init 〜git push)
gitのブランチ作成〜リモートへの登録(git checkout ~ git push -u origin)

はじめに

自分用です。。
参考
https://dotinstall.com/lessons/basic_git
http://lilylila.hatenablog.com/entry/2018/06/22/071932

リポジトリの作成

管理したいディレクトリに移動して

$ git init

GitHubのページに行って、新しいRepositoryを作る。
ターミナルに戻って、README.mdを作る。

$ echo "# <プロジェクト名>" >> README.md

のっけたくないファイルやフォルダがあったら、.gitignoreファイルを作ってその名前をかく。

# style.cssがいらない
style.css
# tsファイルは全部いらない
*.ts
# /imagesフォルダはいらない
/images

インデックス(ステージングエリア)に追加(add)する。

$ git add .  # 全部 
$ git add <ファイル名>

リポジトリにcommitする。

$ git commit -m "コメント"

リモートリポジトリにpushする。

$ git remote add origin https://github.com/CanonMukai/<プロジェクト名>.git
$ git push -u origin master

ちょっとだけコマンド集

# commitをログを見る
$ git log
# 見るのを終了するときはqを押す

# 差分を見る(ステージングに何かあるとき)
$ git diff
# ないとき
$ git diff --cached

# 直前のコミットに戻る
$ git reset --hard HEAD
# 直前の1こ前のコミットに戻る
$ git reset --hard HEAD^
# とあるコミットに戻る
$ git reset --hard <commit idの最初の7桁以上>
# 1こ前まで自分が採用していたコミットに戻る(今までのはあくまでコミットの時系列)
$ git reset --hard ORIG_HEAD

branch

hogeというbranchを作る。下の流れを見るとbranchのすごさがわかる。

$ git branch  # branchを見る
*master
$ ls
index.html 
$ git branch hoge  # hogeというbranchを作る
$ git branch
*master
 hoge
$ git checkout hoge
$ git branch
*hoge
 master
## 新しいファイルstyle.cssを作る
$ ls
index.html style.css
$ git add .
$ git commit -m "Add style.css"
$ git checkout master
$ ls
index.html  ## style.cssはhogeにしかない！！

branchちょい技紹介。
以下のコマンドでhogeという新しいbranchを作り、さらにcheckoutすることができる。便利。

$ git checkout -b hoge

merge(さっきの続き)

hogeで作ったstyle.cssをmasterにも反映させたいとき

$ git branch
*master
 hoge
$ git merge hoge
# ログを見るとhogeのcommitが付け足されてる
$ ls
index.html style.css
# hogeを消そう
$ git branch -d hoge
$ git branch
*master

merge conflictの対応(頑張るぞ)

a.txtをを用意し、masterにすでにcommitしている状態。

a.txt

original

ここで、hogeというbranchを作っておく。このときmasterでもhogeでもa.txtの内容は"original"。

$ git branch hoge

master branchでa.txtを以下に変更してadd, commitしておく。

a.txt(master)

Edit in master

hogeに移動する。

$ git checkout hoge
$ git branch
*hoge
 master

a.txtを以下に変更してadd, commitしておく。

a.txt(hoge)

Edit in hoge

masterに移動。

$ git checkout master
$ git branch
 hoge
*master

ここで、hogeの内容をmasterにmergeしようとすると、a.txtの"original"の状態からどちらのbranchでも変更しているのでmerge conflictが起こる。

$ gir merge hoge
Auto-merging a.txt
CONFLICT (content): Merge conflict in a.txt
Automatic merge failed; fix conflicts and then commit the result.
# 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 modified:   a.txt

no changes added to commit (use "git add" and/or "git commit -a")

このmerge conflictをエディタを使って解消する。
masterのa.txtをエディタで開くと以下のようになっている。

a.txt(master)

<<<<<<< HEAD
Edit in master
=======
Edit in hoge
>>>>>>> hoge

hogeを適用したいので以下のように変更する。手作業面倒だけども...

a.txt(master)

Edit in hoge

これをadd, commitするとmerge conflictを解消できる。

とりあえずここまで。