はじめに

JenkinsでGit Checkoutをしたところ下記のErrorが出ました。
結果的にはファイル容量が大きすぎてタイムアウトしてビルドが通らなかったのですが、その時の解決方法です。

ERROR: Timeout after 10 minutes
FATAL: Could not checkout git hash
Hudson.plugins.git.GitException: Command “/usr/local/bin/git checkout -f git hash” returned status code 143:
stdout:
Stderr: Filtering content: 22%(2/9), 70.42 MiB | 9.20 MiB/s
　　at org.jenkinsci.plugins.gitclient.CliGitAPllmpl.launchCommandln(CliGitAPllmpl.java:2450)
　　at org.jenkinsci.plugins.gitclient.CliGitAPllmpl.access$1100(CliGitAPllmpl.java:84)
　　at org.jenkinsci.plugins.gitclient.CliGitAPllmpl$9.exeute(CliGitAPllmpl.java:2767)
Hudson.plugins.git.GitException: Could not checkout git hash
　　at org.jenkinsci.plugins.gitclient.CliGitAPllmpl$9.exeute(CliGitAPllmpl.java:2791)
…
Performing Post build task…
Match found for :: True

解決策

Advanced clone behaviorsの設定を加えます。
Fetch tagsをTrue。
クローンとフェッチのタイムアウト(分)を30に設定
Shallow clone -> Shallow clone depthを0に設定

shallow cloneを使うことよりcheckoutの時間を短縮させますが、git logをしても過去のコミットを見ることはできません。
最新のリポジトリの状態でビルドしたいけど過去のコミットの情報は不要という場合に使用した方が良いです。

事象

新しいPCになって最初のコミットの際に、コミッタの名前とメールアドレスがPCのユーザ名とホスト名になっていたことに（警告が出ていたのにも関わらず）気付かないまま何度かコミットをしてしまった。
個人利用のリポジトリだがログが残るのが気持ち悪いため、修正する。

名前、メールアドレスの修正

Gitの設定情報を正しい内容に修正する。

$ git config --global --edit

viが起動するため、以下のように追記してesc + :wq

# This is Git's per-user configuration file.
[user]
# Please adapt and uncomment the following lines:
#       name = XX YY
#       email = xxyy@xxyy.local
name=mamfrog                 <-- 追記
email=mamfrog@dummy.jp       <-- 追記

コミットを修正

修正したいコミットが何個前のコミットなのかをログで確認する。

$ git log

二つ前のコミットを修正する場合、以下を実行する。
（三つ前ならHEAD~3となる。コミットIDを直接指定してもOK）

$ git rebase -i HEAD~2

※この時error: cannot rebase: You have unstaged changes.といったエラーが発生した場合、コミットしていない変更があるため、コミットまたはスタッシュしておく。

viが起動するため、対象のコミットの先頭のpickをeditと書き換えてesc + :wq

pick 9cbd3f9 二つ前のコミットメッセージ
pick 7d136e8 一つ前のコミットメッセージ

# Rebase fedede1..7d136e8 onto fedede1 (2 commands)
（以下略）

対象のコミットがチェックアウトされた状態になるため、コミッタの修正コミットを行う。

$ git commit --amend --reset-author

修正が終わったので、リベース完了する。

$ git rebase --continue

再度git logしてコミッタが修正されたことを確認。

補足

一つ前のコミットだけを修正する場合はリベース不要。
Gitの設定情報を修正後、以下を実行すればOK。

$ git commit --amend --reset-author

参考

6. rebase -i でコミットを修正する｜サル先生のGit入門【プロジェクト管理ツールBacklog】

動機

こちらのツイートを見て「確かに…」と思ったので、サクッと実行するためのエイリアスを作ってみた。

Git無意識&&手癖で触ってるから気づかなかったけど実はmasterブランチを手元にチェックアウトする必要ないな。git fetch origin && git checkout -b new-branch origin/masterからのgit push -u origin new-branchで良い。

— Toshiyuki Takahashi (@tototoshi) March 4, 2021

エイリアスを作るコマンド

アップストリーム(upstream)とは開発時にメインとなるブランチのこと。 master だったり、 develop や development などプロジェクトによってどのブランチがアップストリームなのかは違うため、以下のコマンドを使う前に読み替えていただきたい。

origin : リモートサーバーの名前。 git remote -v などで表示される。
master : アップストリームのブランチ名。

$ git config --local --add alias.nb '!f(){ [ $# -eq 0 ] && echo "Usage: git nb <branch>" && exit; git fetch --tags --prune origin && git switch -c $1 origin/master; };f'

作成したエイリアスは次のように使う。

$ git nb feature/something

エイリアス名 nb は new branch として適当につけてますが、使いたい人が打ちやすい名前にすれば良いと思います。

解説

コマンドの部分はこんな意味。

• git config --local : 現在のプロジェクトの設定を表示したり、更新したりする。自分用の全プロジェクト向けの共通設定は --global などで定義可能。
• --add alias.nb : alias 設定グループに nb を追加する。 alias 設定グループに指定した値は git nb のようにエイリアスとして追加される。

エイリアスに指定した文字列は ! で始まる場合シェルスクリプトとして認識される。
この場合、 f(){ ... } で関数 f を定義して、最後に f で実行しているので、引数を含めて実際には f feature/something として実行される形となる。

f の内容は次のような構成になっている。

• [ $# -eq 0 ] && echo "Usage: git nb <branch>" && exit; : 引数がなかったらUsageを表示して終了する。
• git fetch --tags --prune origin : タグと削除されたブランチを含め、リモートの最新状態を取得する
• git switch -c $1 origin/master : origin/master を基準として、新しいブランチを作成しブランチへ移動する

動機

こちらのツイートを見て「確かに…」と思ったので、サクッと実行するためのエイリアスを作ってみた。

Git無意識&&手癖で触ってるから気づかなかったけど実はmasterブランチを手元にチェックアウトする必要ないな。git fetch origin && git checkout -b new-branch origin/masterからのgit push -u origin new-branchで良い。

— Toshiyuki Takahashi (@tototoshi) March 4, 2021

追記(2021-03-04): デフォルトブランチ、追跡ブランチ等の名称を変更しました。

追跡ブランチ(tracking branch)とはリモートサーバの状態をローカルにコピーして追従するためのブランチです。
基本的には追跡ブランチを最新の状態にし(pull)、そのブランチから新しい機能追加・修正用のブランチを作ります。
しかし、最新の状態にし忘れてブランチを作ってしまったり、ローカルで変更したものをうっかり追跡ブランチ上でコミットしてしまったりするとリモートの状態とずれてしまうため事故が起こりやすいのも欠点です。

エイリアスを作るコマンド

デフォルトブランチとは開発時にメインとなるブランチのことで、 master だったり、 develop や development などプロジェクトによってどのブランチがデフォルトなのかは違うため、以下のコマンドを使う前にそれぞれの環境に合わせて読み替えていただきたいです。

origin : リモートサーバーの名前。 git remote -v などで表示される。
master : デフォルトブランチ名。

$ git config --local --add alias.nb '!f(){ [ $# -eq 0 ] && echo "Usage: git nb <branch>" && exit; git fetch --tags --prune origin && git switch -c $1 origin/master; };f'

作成したエイリアスは次のように使う。

$ git nb feature/something

エイリアス名 nb は new branch として適当につけてますが、使いたい人が打ちやすい名前にすれば良いと思います。

解説

コマンドの部分はこんな意味。

• git config --local : 現在のプロジェクトの設定を表示したり、更新したりする。自分用の全プロジェクト向けの共通設定は --global などで定義可能。
• --add alias.nb : alias 設定グループに nb を追加する。 alias 設定グループに指定した値は git nb のようにエイリアスとして追加される。

エイリアスに指定した文字列は ! で始まる場合シェルスクリプトとして認識される。
この場合、 f(){ ... } で関数 f を定義して、最後に f で実行しているので、引数を含めて実際には f feature/something として実行される形となる。

f の内容は次のような構成になっている。

• [ $# -eq 0 ] && echo "Usage: git nb <branch>" && exit; : 引数がなかったらUsageを表示して終了する。
• git fetch --tags --prune origin : タグと削除されたブランチを含め、リモートの最新状態を取得する
• git switch -c $1 origin/master : リモートブランチ origin/master を基準として、新しいブランチを作成しブランチへ移動する

はじめに

Gitでブランチを作成せずにmasterにcommitしてしまったため、記録として書きます。

今は記事作成に時間を割きたくないため、丁寧な書き方ではありませんが、画像を載せているのでご了承ください。

本記事について

SourceTreeを使用したGit操作を行っているのでお役に立っていただけば嬉しいです。

参考記事

手順

1

ブランチを作成せずmasterにcommitしてしまった

2

まずは新しいブランチの作成
1. 「ブランチ」をクリック
2. 新規ブランチ名を記載
3. 「ブランチを作成」をクリック

3

次に、masterに移動　※私のではmainとなっています
1. 左側のmainをダブルクリックでmainに移動
2. 画像２のように「コミット適用前に戻す」をクリック

4

1.確認画面が現れるでの「OK」をクリック

5

1.完了

これで、新しいブランチにはcommitした物が保存されてt、masterには元の状態に戻っています。

まとめ

masterに間違えてコミットしたら
新しいブランチを作成し、masterのcommitをリセットしたら終わり
です！
まとめたら簡単ですね。

今回は、よくあるgitのコマンドなどについて簡単にまとめました。

Git

Gitとは分散バージョン管理システムで、複数人での開発を行う際に用いられる。
自分の書いたコードを他人に共有できる。

リモートリポジトリ

リモートリポジトリとは
複数人で共有するためにネット上(主にGithub、Bitbucketなど)にアップロードされたリポジトリのこと

またローカルリポジトリとは、自分のPCに配置されているリポジトリのこと

　
リモートリポジトリの紐付け(追加)

git remote add origin url

・urlのところに、リモートリポジトリのurlを設定する
・originは、デフォルトの名前

git add

git add .

・ファイルをコミットの対象（Gitの管理対象）に入れる。
　

git add ファイル名

・ファイル名を指定することで個別に追加もできる。

git commit

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

・コミットするときに、メッセージをつけることができる。このメッセージは、コミットメッセージという

・メッセージの内容は、簡潔に変更した内容がわかるメッセージにする。

git push

git push origin master

・リモートリポジトリにアップロードする
・masterは、デフォルトのブランチ名

git pull

git pull origin master

・リモートリポジトリの最新の内容を取り込める。

git status

git status

・変更したファイルを確認できる。

ブランチ

ブランチとは
プロジェクトから分岐させプロジェクト本体別の環境に枝分かれさせることができる。機能ごとにブランチを分けることで、作業内容を明確に決め作業を進行させるなど様々な使い方ができる。

複数人で作業する際、作業内容が混在すると大変なことになりかねないので、そういった時にブランチを分岐することで安定した作業ができて効率よく機能の実装もしも不具合が発生してもプロジェクトに戻して復元も行えたり、問題を切り離して対応することが可能になり問題解決に集中できる。

コマンド

git checkout

ブランチの切り替えを行うときに使用するコマンド。
・オプション
「-b」

git checkout -b ブランチ名

チェックアウトとブランチ作成を同時に行える。

「-f」

git checkout -f master

・ブランチの強制切り替えを行う

参考元

こちらのサイトを参考にさせていただきました。
・サル先生のgit入門

ちょっとしたチップスみたいなものです

Android Studioでファイルを開くコマンドを生成する

1. Tools->Create Command-Line Launcher...
   

2. 適当な場所に保存
   

3. studioでファイルを展開できるようになる

コンフリクトしてるファイルの一覧を取得してstudioの引数に渡す

このコマンドを叩けばOK

git ls-files -u | cut -f 2 | sort -u | xargs studio

あとは、、、

お好みに合わせてaliasつけたりすれば完璧

【準備】前回のgit stashが残っていないかを確認する

git stash list

一時的な退避が残っていた場合

git stash clear

このコマンドですべて削除できます。
あくまで一時退避なので、長期間stashを残すのはオススメしません。
必要なものは残しておきます。

一部を削除したい時

git stash drop stash@{n}

ここがポイントなのですが一番最新の「git stash」したものが{0}になります。
古い退避は0,1,2,3,4,,,nと数字が大きくなっていきます。

【本編】stage前の変更を一時保存する

git stash
git stash save

コマンドはどちらでも構いません。上は単なる省略形です。
ちなみに、私は省略しないで下のコマンドを使います。
自分が何をしているのか忘れないために、極力省略形は使わない癖を付けています。

ブランチの移動

git branch
* develop
  master
git checkout master
git branch
  develop
* master

「git stash」をしたことでワーキングツリーがクリーンになりブランチの移動ができるようになります。
今回は、「develop」から「master」へ移動しています。多くの場合は、トピックブランチ(作業ブランチ)からバグフィックス(修正ブランチ)への移動が多いと思います。その後、トピックブランチへ戻ります。

修正作業が終わったら一時退避を元に戻します

git stash apply stash@{0}

ここで最新の「git stash」の番号は「0」になります。
「git stash」が溜まっていると、applyする番号を間違えやすいです。

「git stash apply」の番号を間違えた場合

git checkout .

上記のコマンドでワーキングツリーをクリアにして、前回のコミットまで戻します。
その後、再度正しい番号の「git stash apply stash@{n}」を行ってください。

さいごに

git stash list
git stash clear

最後に一時退避リストを確認してから、すべて削除しましょう。
一時退避を長期間残しておく、必要性はないです。

方法

①gitのエイリアスを設定

$ vim ~/.gitconfig

.gitconfig

[alias]
        tree = log --graph --pretty=format:'%x09%C(auto) %h %Cgreen %ar %Creset%x09by"%C(cyan ul)%an%Creset" %x09%C(auto)%s %d'

②ターミナルで$ git treeを入力

実行結果

結論

多くの記事にある通り、sshkeyを再度作成しgitに登録することで解決しました。
ただ、以下に当てはまる方々は参考になると思います。

対象読者

・初心者の方
・gitを複数アカウント使用している方
・何度も同じerrorが出る方
・~/.ssh/configの書き方に自信の無い方
・local --globalのuser.nameやuser.emailを変更した方
・個人用gitを持っていたが、新しく社内用gitをメインに使うという方
・まとめて、いろいろな記事を参照したい方

sshkeyを再度作成し登録を行い一度は解決しました。しかし、何度も同じエラー文が出てくるため、おかしいと思い調べた結果を備忘録として記します。

参考記事

・GitHub アカウントへの新しい SSH キーの追加
・新しいMacでGitHubのSSH接続をするまでの環境構築手順
・GitHubでssh接続する手順~公開鍵・秘密鍵の生成から~
・お前らのSSH Keysの作り方は間違っている
・gitでPlease make sure you have the correct access rights and the repository exists. が出た時の対処法
・Gitの設定をgit configで確認・変更

エラーの確認

作成したアプリケーションをgithubへadd,commit は完了。
いつもどおり、git push origin mainと打ち込んだところ、以下のようなエラー文が出てきました。

Error文について

 sample_app % git push origin main
ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

英語は一読して、わからなければGoogle翻訳に入れてみましょう。

エラー：リポジトリが見つかりません。
致命的：リモートリポジトリから読み取ることができませんでした。

正しいアクセス権があることを確認してください
リポジトリが存在します。

アクセス権限とリポジトリが存在しているのか確認してくださいが正しい訳です。
以前にも同じエラーにあいましたが、他の方の記事を参考にsshkeyを再度作成し解決できました。ただ、今回は何度やっても改善されなかったため、根本からの見直しを行いました。

原因は何だったのか

考えられる原因は、複数あります。

・localのglobalのuser.nameとuser.emailを個人用から会社用に変更した
・名前を変え、sshkeyを複数作ってしまった
・ユーザは会社用に変更したが、ssh接続をする際のユーザが前の個人用のままであった
・~/.ssh/config内の設定が正しくできていなかった

個人的に学習用でgithubを使用していたため、githubのアカウントをすでに持っていました。エンジニアとしての転職により、今後は個人での開発をメインで使わなくなるためglobalのユーザアカウントを個人用から会社用に変更しました。その際に ~/.ssh/configの設定の間違いをしてしまったようです。それに気づかずに、何度も同じエラーにあう度に作ってしまった、sshkeyの数々が原因となっていたと考えられます。

解決方法

今回解決できたのは、2点の変更が重要でした。

・sshkeyをデフォルト名のまま再作成したこと
・~/.ssh/configの再設定

設定した globalユーザの確認をします

gitにはsystem, global, localの3つの設定ファイルがあります。個人用で使用していたは globalの設定で、該当ユーザの全リポジトリを扱うタイプです。 現在の設定を見るためには、$ git config --global -lで確認できます。
(git initをしたディレクトリ以下、もしくは作業ディレクトリ上で確認してください。)
(参照：Gitの設定をgit configで確認・変更)

--globalでの設定

githubに登録した名前とメールアドレスを設定しましょう。
私は、個人用から会社用に変更をしました。

$ git config --global user.email xxxxx@yyyy.co.jp
$ git config --global user.name yamadataro

$ git config --global -lで上記で設定したユーザ名、メールアドレスになっていればOKです。

ssh-keyを作成する前に

sshkeyの作成を再作成します。一度作っているかどうかを確認してください。デフォルト設定ではgithubは~/.ssh/id_rsa、~/.ssh/id_rsa.pubから読み込みます。今回うまく行ったのは、こちらを再作成したことが大きいです。念の為、作成済みの方は削除してから作りました！( 後でsshkeyを作成する際に上書きもできますが、今回は削除してから作成しました。 )

// sshkeyのあるディレクトリに移動
$ cd ~/.ssh

//sshkeyを作る際に同時に作成される2つの id_rsa を確認。なければ新規作成からでOK
$ ls

//各ディレクトリを削除
$ rm id_rsa
$ rm id_rsa.pub

これでsshkeyを作成する準備ができました。
使っていないkeyについても、この際整理しても良いと思います。

ssh-keyの作成はここから

$ cd ~/.sshで鍵を作成するディレクトリに移動し、以下のコマンドを入力します。

// mac Big Surの場合
$ ssh-keygen -t rsa -b 4096 -C xxxxx@yyyy.co.jp

もし任意のsshkey名をつけたい場合は -f github_mainなどをメールアドレス以下につけることが可能ですが、今回はその方法ではなくrsaで再作成するため空欄にしています。

また、多くの参考記事に{},""でメールアドレスなどを囲った分がありますが、そちらの書き方は少し注意が必要です。使っているOSに依存したり、囲うことで範囲指定して事故を防ぐメリットがあるようです。必要に応じて対応をお願いします。私と同じOS:mac Big Surの方は特になくても構いません。

-c以下にはgithubに登録済みの社用メールアドレスを入れました。細かい用語や数値については他の記事を参考にしてください。(参考：お前らのSSH Keysの作り方は間違っている)

途中で3回確認をとられますが、特に設定のない場合は、そのままEnterを3回押してください！中身はざっと解説しておきます。

Generating public/private rsa key pair.

//作成されるディレクトリとファイル名の確認
Enter file in which to save the key (/Users/username/.ssh/id_rsa): 

//パスワードより長いパスフレーズを登録するかの確認
Enter passphrase (empty for no passphrase): 

//上で入力したパスフレーズを再確認
Enter same passphrase again: 

では、作成されたssh-keyを$ lsで確認しましょう。
その際に、id_rsa, id_rsa_pubが存在していればOKです。

./ssh/configで設定を変更する

sshkeyを作成した後、githubとssh接続をする設定ファイルがこちらです。同名のファイルがない場合は$ touch configで作成しましょう。$ vi ~/.ssh/configで編集できます。私の場合は以下のように設定しています。

# GitHub SSH key
Host github
  Host Name github.com
  IdentityFile ~/.ssh/id_rsa.pub
  User git
Host *
 UseKeychain yes
 AddKeysToAgent yes

確認するのはIdentityFileが先程作成したディレクトリ名~/.ssh/id_rsa.pubになっているかどうかです。gitとやり取りをするのは.pubの方なので注意！

もともと複数アカウントを設定するため、新しく作成したsshkeyのパス名を設定していました。しかし、どうもうまく実行できなかったため、再作成した~/.ssh/id_rsa.pubに変更しました。（参考はこちら：新しいMacでGitHubのSSH接続をするまでの環境構築手順）

github へ sshkeyの登録と接続確認

公式サイトのものが一番分かりやすいです。注意としては、sshkeyのコピーには
$ pbcopy < ~/.ssh/id_ars.pubを使いましょう！ということです。

いくつかの記事で、ディレクトリの中身を確認して、メールアドレスなどを省いてコピーするというのを見かけましたが、公式がやっている方法を使ったほうが確実ですね。
（参考：GitHub アカウントへの新しい SSH キーの追加）

無事接続できたかどうかの確認

さて、githubへsshkeyが登録できたかを確認するために、作業していたディレクトリに戻ります。小ネタですが、直前まで作業していたディレクトリへは$ cd -のコマンドで移動できます。

sample_app % ssh -T git@github.com

Hi user.name! You've successfully authenticated, but GitHub does not provide shell access.

上記のように新しく登録したuser.nameが表記されていたら無事完了です！！

--globalにはかなり前に会社用アカウントを設定していましたが、依然として個人のユーザ名が表示されていました。しかし、今回確認したところ、会社用のユーザ名に変更されていたため、~/.ssh/configで起きていたエラーは解決され、無事push出来ました！

まとめ

今回は、error:Please make sure you have the correct access rights and the repository exists.についてsshkeyを再度設定し、設定ファイルである~/.ssh/configの中身も整理しました。何度か違うリポジトリにpushしてみて、経過観察し問題ないことを確認したいと思います。

以上