- 投稿日：2020-03-27T16:16:17+09:00
git pull 出来なくなった時の対処法
どんなことが起きたか
いつもコードを書いているリポジトリで、fetchやpull、pushが出来なくなった。
いつも通りfetchをしようとすると、今までは聞かれなかったのに
UsernameとPasswordを求められてしまう状況。$ git fetch upstream Username for 'https://github.com':XXXXX Password for 'https://github.com': remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/XXXXX'正しいものを答えても認証に失敗してしまう・・・
調査する
毎回ユーザネームとパスワードを入力しないといけないのは、めんどい・・・
同様の問題に関する記事を参考に調査してみた。リポジトリのアドレスを調べる
参考記事によると、通信をhttp通信→sshプロトコル通信に変えればOKとのことなので
現在のgitの通信状態を調べる。$ git remote -v origin https://github.com/XXXXX/XXX (fetch) origin https://github.com/XXXXX/XXX (push)httpsでした。現在の通信状態がhttp通信であることがわかります。
社内リポジトリはsshでcloneしてくる必要があるのに、httpでcloneして居たことが判明。。。
ちなみに、ssh通信である場合は、https://ではなくgit@から始まります。ssh通信に変更する
方法はGitの公式にあります
リモート URL を HTTPS から SSH に切り替える
上記サイトの通り、SSHに切り替えると
リポジトリのアドレスもgit@から始まるアドレスに変更されたことが確認取れました。それでもダメな場合
ssh通信に変更も完了し、
よし！ついにpullできる！と思い、いざpull。$ git pull identity_sign: private key /Users/{user_name}/.ssh/XXXX/id_rsa contents do not match public git@github.com: Permission denied (publickey).・・・？
別のエラーが出ました、、、
秘密鍵が一致せず、権限が拒否されているようです。秘密鍵、公開鍵の作り直し
秘密鍵や公開鍵を確認しても、おかしいと思われる箇所が見当たらず
秘密鍵・公開鍵を作り直したら、うまく行きました。作り直しの際は、こちらの記事が参考になりました。
GithubのSSH通信設定途中、SSH接続のテストの際にでたエラーについても解決方法をわかりやすく書かれていました。
Warning: Permanently added the RSA host key for IP address '52.192.72.89' to the list of known hosts. identity_sign: private key /Users/{user_name}/.ssh/XXXX/id_rsa contents do not match public git@github.com: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.根本解決にはならないですが、どこが悪いのか検討もつかず
かなりの時間を費やしてしまう場合は秘密鍵、公開鍵の作り直しをするのも手段の一つかと思います。
- 投稿日：2020-03-27T00:57:51+09:00
GitHubでプルリク、GitLabでマージリクエストを送る前のチェックリスト！
マージリクエスト前にチェックするとよい内容
あくまで目安です。
全部をガチガチに確認することまではしなくて良いと思いますが
確認の抜け漏れがないか、参考にする程度に使ってください。指差し確認、ヨシ！
ブランチ関連
- マージ先のブランチが間違っていないか?
- 自分のブランチ名がわかりやすいか?
- (無理に修正しなくて良いが、次回以降気をつける)
- マージ先、リモートのmasterブランチの変更が適宜取り込まれているか
内容確認
マージ先と差分を取り確認
作業時の一時的なものがのこってないか
- 個人的なメモの為の改行、コメントの消し忘れがないか
- デバッグのためにしたコメントアウトが残っていないか
- 不要なimport文がないか
- 新しく一時的に作ったが使用していない変数、メソッド、処理など
- 不要ファイル(個人用IDEの設定ファイル等)が含まれていないか
自分の実装などの確認(ソースコード)
- エディタでのチェックが働かないようなファイル(XML, md, 設定ファイル等)に誤字がないか
- あやまって消してしまっている記述がないか
- 分かりづらい処理がないか。わかりづらい箇所にはコメントが書いてあるか
- テストが書かれているか (可能であれば)
- 命名規則、記法(camelCase, SNAKE_CASE, Pascal...)が守られているか
- フィールドを無意味に
publicにしていないか- コミットコメントが適切だったか
- (無理に修正しなくて良いが、次回以降気をつける)
テストが通るか確認
単体テスト
- 実装、変更箇所がEclipseからの単体テストで問題ないか
ビルドの確認
- ビルドツール(gradle)からのテスト・ビルドが通るか
- 通らない場合は、問題のある箇所を確認。環境依存などの問題がある。
動作の確認
- ローカル環境で、実際に動作確認をしたか。
- どのように確認したか
マージリクエストのコメント
- チケットの番号、内容がわかるか
- チケットに対して対応できているか(要求事項に過不足ないか)
- 変更箇所がわかりやすいか。
- 変更の意図がわかるか。
- ローカルでテストできているか、動作確認しているか
- 投稿日：2020-03-27T00:55:51+09:00
GitLabの運用フローを知ってチームでの開発を円滑にしよう
TL;DR
- ブランチの運用、プルリク、マージリクエストの書き方は、お互いのためにもちゃんと新人に教えよう。
はじめに
現在、開発でのバージョン管理やソースコードの変更点の管理等はGitで行うのが主流となっており
過去、SVNを使用していた会社も、Gitに移行して運用を実施してきています。Gitは非常に便利なものですが、チェックアウト、開発、ブランチ作成、マージ、リクエスト等
複雑な操作が多く、ブランチ間の移動や、マージ、チェリーピック等の際に「自分のコミットが消えた...!?」と思ってしまう初学者の人も多いかと思います。
(実際は消えているわけでは無いので、落ち着いて操作しなおせば良いのですが、少しヒヤっとしてしまいがちです...)本稿は、Gitでのリポジトリのチェックアウト、開発・修正、プッシュ、マージリクエストまでの流れを簡単にまとめ、下記のような、諸先輩方から指摘されがちな問題を減らしていき、Git運用のある程度の指針にすることを目的にしています。
（指摘が減ると、レビュイーもレビュワーも幸せ！やったね！！）
- よくある問題点、指摘
- コミット時のコメントが不明確
- マージリクエストが分かりづらい
- そもそもブランチ運用があやふや
※現在の会社に入社して1,2ヶ月。GitLabを使用しての開発のフローがなんとなくつかめてきましたが、wikiや会社内でのブランチ運用の明確なルールがなかったので、現在の自分のチェックリスト兼将来の自分の後輩育成用の資料として作成しました。今作ることで将来の自分の負担が減るね。天才じゃん。
Gitのブランチ運用
gitのブランチの運用は、様々な方向性があります。
- Git-Flow
- GitHub-Flow
- GitLab-Flow
- その他、上記のFlowの亜種
それぞれの運用方法にも特徴・有利な点・不利な点があるので興味があればその他の運用フローも確認してみてください。
- GitHub Flow – Scott Chacon
- はてなブログチームの開発フローとGitHub - Speaker Deck
- Introduction to GitLab Flow | GitLab
- Gitlab-flowの説明 - Qiita
準備
実際に開発を行う為のEclipse等の環境、およびGitのインストールは完了しているものとします。
1. リポジトリからのクローン
1.1. Gitからcloneする
対象のリポジトリにアクセスし、URLをコピー(HTTPSの場合)
例 : https://github.com/HirokiYoshida837/processingLibrary.git
自分のPC上で、リポジトリを置きたい場所をエクスプローラーで開く
対象の場所でシェルを開き、以下のコマンドを実行
$ git clone https://github.com/HirokiYoshida837/processingLibrary.git(※URLは上記の手順1.でコピーしたURL)リポジトリのフォルダ名を変更したい場合は、下記のコマンドになります。同一リポジトリを、同じ階層内に別のフォルダ名で保存したい場合などに使用します。
$ git clone https://github.com/HirokiYoshida837/processingLibrary.git 変更したいフォルダ名エクスプローラーもしくは
lsコマンド等で、チェックアウトされている事を確認する1.2. チェックアウトしたプロジェクトをEclipseで開けるようにする
- チェックアウトしたリポジトリに移動
- 移動先で以下のコマンドを実行する。 >
$ ./gradlew eclipse
gradle.buildファイルに、eclipse用プロジェクト生成のプラグインが含まれている為、上記のコマンドを実施するだけでeclipseプロジェクトに必要なファイル、クラスパスなどを生成し、必要なライブラリなどを取得してきてくれます。
- eclipseからプロジェクトをインポート。(詳細は割愛) eclipseからのプロジェクトのインポートは、他の資料などを参照。 Eclipseに限らず、好きなIDEでも問題有りません。
2. 自分の開発用ブランチの作成
2.1. masterブランチから新しくブランチを作成
今回は、チケット番号
#1234599という架空のチケット内容を例に開発していきます。
※あくまで説明の為なので、実際には、自分の担当しているチケットで作成してください。2.1.1. 適当な名前でブランチを作成しチェックアウトする
自分の担当しているチケット名に即した内容でブランチを作成します。
今回は、#1234599のチケットを担当しているので、ブランチ名は1234599_hogehogeとします。※hogehogeの部分は、チケット番号と、内容がわかるような名称をつけると良いです。
$ git checkout -b 1234599_hogehogeこれで、ローカルにブランチを作成し、自動でそのブランチに移動してくれます。
3. 開発
3.1. 開発、コミット
手順2. でチェックアウトしたブランチ上で開発を行っていきます。
プログラムをある程度書く度に、コミットしていく。
[補足] コミットの粒度、rebaseでのコミットのまとめ
gitでは
git rebaseコマンドで、複数のコミットをまとめて一つのコミットにする方法があります。
ただ、コマンドラインからrebaseでコミットをsquashするのはなれない場合には注意が必要です
(デフォルトでは起動するエディタがvimなので操作がわかりにくい、複数のジャンルのコミットがまとまってしまって逆に分かりづらい、失敗して焦ってしまう、等)3.2. プッシュ
作成・修正したプログラムは、現状、自分のPC上のリポジトリ(ローカル)にしか存在していません。
これをリモート(GitLabのリポジトリ)に反映させるためには、pushすることが必要です。3.2.1. プッシュの手順
$ git push [remote-name] [branch-name]を実施することで、リモート側に反映することができます。ただし、下記の引用文のように、他の人がすでに変更を反映している場合(同一ブランチで、複数人で開発を実施している場合など)には、そのままではpushできません。このコマンドが動作するのは、自分が書き込みアクセス権を持つサーバーからクローンし、かつその後だれもそのサーバーにプッシュしていない場合のみです。 あなた以外の誰かが同じサーバーからクローンし、誰かが上流にプッシュした後で自分がプッシュしようとすると、それは拒否されます。 拒否された場合は、まず誰かがプッシュした作業内容を引き出してきてローカル環境で調整してからでないとプッシュできません。
3.2.2. リモート上の変更を、自分のブランチに反映
$ git pull※
git pullコマンドを実行した場合、git fetchとgit mergeを自動的に実施するようになっており、自動的にリモートの変更がマージされてしまいます。(conflictが発生していた場合を除く)できれば、個別に
git fetchとgit mergeを実施し、fetchの時点で、どこが変わるのかを把握した方が良いです。3.2.3. masterブランチの変更を、現在のブランチに反映
ブランチでの開発が長くなってくると、masterブランチと、自分の開発ブランチとの間に差ができてきます。
すでに誰かが修正したバグ修正・仕様変更を自分の開発環境に反映できていない場合には、仕様との乖離ができてしまいますし、また、最終的にmasterブランチへのマージ時にconflict(変更箇所の競合)が大量に発生する可能性があります。
なので、適宜、リモート上の変更を自分の開発ブランチへ反映させていくことが望ましいです。
- ローカル(自分のPC) で、masterブランチをチェックアウト >
$ git checkout master- リモート上のmasterの最新をとってくる >
$ git fetch origin master- 自分のローカル上のmasterに、origin/masterをマージ >
$ git merge origin master- 自分の開発ブランチにmasterをマージ >
$ git checkout 1234599_hogehoge>$ git merge master4. マージリクエスト
4.1. テストをローカルで通してみる
マージリクエストを送る前に、ローカル環境でテストが問題なく通るかどうかを確認する。
問題があれば、エラーが出なくなるまで修正。4.1.1. Eclipse等での単体テスト
タイトルのとおりです。テストクラスから、右クリックでテストを実施できます。
テストが書かれてない...?書けばよかろうなのｄ4.1.2. gradleからテストタスクを実行
下記コマンドで、jenkinsと同じようにテストが実施できます。
$ ./gradlew testテストの結果は
test/..中略../build/report/tests/の中にhtmlで出力されます。具体的にどのテストが失敗した等の情報が見れるので活用してください。
テストが書かれてない...?(略)4.2. マージ先とのdiffを見る
マージリクエストを送る前に、マージ先との差分を確認します。
$ git diff [マージ先] [自分が開発したブランチ]これによって、
- 変更量がどれだけか
- 意図していない箇所を間違って修正してしまっていないか
- コンフリクトがどのあたりで発生しそうか
- 自分で理解できていない処理がないか。コメントが適切にかかれているか。
- 不要なファイル、記述類が含まれていないか
- 個人のPC環境用の設定ファイル
- メモの消し忘れ
- 無意味な沢山の改行
- コメントアウトの残り
- etc...がわかります。マージリクエストを送る前に、自分で一度、おちついて変更箇所に変な箇所がないかを確認する意味もあります。しっかり確認しましょう。
マージリクエストを送る前に、自分でおちついてソースコードを読むことで、悪い箇所・直したい箇所などを見つけられることもあります。
CLIで見る他にも、GitLabやGitHubでは、マージリクエストを書いている最中に、マージ先との差分を確認する事ができます。
その他、Git Diffで使えるツール・ソフトウェアは以下のリンクを参考にしてください。
- Git - 変更内容のリポジトリへの記録4.3. マージリクエストを送る
テスト・確認ができたので、マージリクエストを書いて、送ります。
※環境の問題、特殊な問題で確認・テストが十分にできていない場合は、それも含めてマージリクエストを書いてください。マージリクエストする際は、要点をちゃんとまとめたコミットメッセージになってるか確認する。
- この変更は、何によるものなのか(チケット番号とか)
- そもそも、ブランチ名をチケット番号に関連付けること。
- どのファイルを、どういう意図で修正・追加したか
- どの環境で動作確認、テストしたか
- etc...
GitHubでプルリク、GitLabでマージリクエストを送る前のチェックリスト！ - Qiita
こちらもチェック事項の参考にしてください。4.4. マージしてもらう
マージしてもらいます。
4.5. マージ後のJenkinsのテストの確認
masterブランチへのマージ後、jenkinsが自動でテスト・ビルドを走らせます。
ローカルでテストが通っていても、環境の差等で意図せずテストが通らない場合があります。
ビルドエラーが出た場合、Jenkinsに出ているログを確認して修正、再度マージを依頼します。
CI環境がない...?(略)4.6. デプロイ環境での確認
Jenkinsは、自動でテスト、ビルド、環境へのデプロイまでを行ってくれます。
(※行ってくれるように設定してあります。)場合によっては、DBの差、実行環境の違いなどが影響していることもあります。
デプロイされた環境で、再度自分で変更箇所まわりを触り、問題ないことを確認しましょう。
CI環(略)まとめ
以上で、おおまかな開発の流れの解説、Gitの運用についての解説おわりです。
Gitについてもっと詳しく知りたい方は、公式資料の『Git Book』を確認してみましょう！
(3. Git のブランチ機能あたりまで読むだけで、かなり理解が深まります。)
https://git-scm.com/book/ja/v2Gitを使って、チームで快適な開発ライフを送りましょう！
