発生したエラー

 % git clone https://github.com/xxx/yyy.git

を実行すると以下のエラーメッセージが

Cloning into 'yyy'...
ssh: Could not resolve hostname github: nodename nor servname provided, or not known
fatal: Could not read from remote repository.

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

解決策

.gitconfigが悪さをしていそうなので削除

ファイルの存在確認
 % ls -la ~/ | grep git
-rw-r--r--   1 mo    staff        84  2  4 08:07 .gitconfig

発見したので削除
% rm ~/.gitconfig

参考

• カスタマイズはほどほどにしましょう - Aikの技術日記

そもそも鍵とは...

そもそも鍵はなぜ必要なのか。
リポジトリにアクセスするために、SSH認証キーを使う。
SSH認証することで、
・セキュリティ向上（言わずもがな）
・アクセス時に毎回パスワードを聞かれなくてストレスフリー
私が今回この記事を書こうと決めたのは、パスワードを毎回聞かれ、
ストレスがやばかったから。
では、そのSSH認証するための鍵の生成について見ていきましょう。

---

SSH認証するための鍵をBitbucketに設定する

1.SSH認証の公開鍵/秘密鍵を作成
2.公開鍵をクリップボードにコピー
3.Bitbucketに公開鍵を登録

---

SSH認証の公開鍵/秘密鍵を作成

ターミナル上で以下コマンドを叩いて、公開鍵と秘密鍵を生成。

bash

$ cd ~/.ssh
$ ssh-keygen -t rsa -C hoge@example.com  # 自分のメールアドレス

以下コマンドを叩いて、生成されたファイルを確認。

bash

$ ls -l 
合計 12
-rw------- 1 hoge 1831  2月 5 18:00 id_rsa
-rw-r--r-- 1 hoge  405  2月 5 18:00 id_rsa.pub

各ファイル名は下記です。
秘密鍵：id_rsa
公開鍵：id_rsa.pub

公開鍵をクリップボードにコピー

cat(またはless)コマンドで公開鍵の内容をクリップボードにコピー。

bash

$ cat id_rsa.pub

Bitbucketに公開鍵を登録

1.Bitbucketにログイン後、左下のユーザアイコンをクリックし、view profileをクリック。

2.「設定」をクリックし、「セキュリティ」の中の「SSH　鍵」をクリック。

3.「鍵を追加」をクリックし、「Label」に適当な名前を入力し、「Key」に先ほどクリップボードにコピーした公開鍵の中身をペースト。

4.「鍵を追加」をクリックして設定完了。

これで、リポジトリにプッシュ！！！

発端

弊社ではTortoiseGitを利用してGitによるバージョン管理を行っているのですが、

• フェッチするのにワークディレクトリまで移動して、右クリック＞フェッチ　という操作が毎回面倒くさい！！
• コミットログを確認するのにワークディレクトリまで(ry

とにかくこのオペレーションを簡略化したかったというのが発端になります。

解決策

ほぼほぼ、参考ページに記載の通りです。
オリジナリティは特にありません。

フェッチしたい場合

"C:\Program Files\TortoiseGit\bin\TortoiseGitProc.exe" /command:fetch /path:"{dir}"

コミットログを確認した場合

"C:\Program Files\TortoiseGit\bin\TortoiseGitProc.exe" /command:log /path:"{dir}"

最後に

作成したスクリプトはマクロやランチャーに登録して使用してください。
私はエクスプローラ（QTTabBar）と組み合わせて使ってます。

参考ページ

https://matsuoshi.hatenablog.com/entry/20110502/1304327645

明日Qiitaに隕石が衝突するかもしれない, もしものために.

環境

• Windows 10

記事バックアップ

• Python 3.8.1
• Git for Windows 2.5.3(Command Lineで実行)

画像取得

• サクラエディタ Ver2.2.0.1
• DS Downloader Ver2.12.0

Mac環境でもできると思います. 試していないため, あくまで提案です.
- Boot Camp
- Wineで実行.
- (仮想化ソフトウェア(VirtualBox等))
- Macでサクラエディタ
- grep機能があるエディタ
- SiteSucker for MacOS

記事エクスポート

@i-tanaka730さんのみんな大好きQiitaのバックアップツールを作ったので公開
の力を借ります.

Qiitaのバックアップツール

qiita_backupper

Gitインストール

• Git-2.5.3-64-bit.exeをダウンロード、実行する. Git for Windows 2.5.3
• Command Lineを選択する.（参考[1]:自分用 Git For Windowsのインストール手順）

バージョンは合わせました.

Pythonインストール

• python-3.8.1-amd64-webinstall.exeをダウンロード、実行する. Python 3.8.1

あとはREADME.mdをよく読んで、記事のエクスポートを実行する.

画像エクスポート

[3]を参考にしました.

1. 〇〇.mdをサクラエディタで開く
2. Ctrl + G (検索メニューの中にあるGrep(G))
3. 条件を入力する.(コピペ)

grep.txt

https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/.*png|https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/.*jpg|https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/.*gif

Grep条件入力	実行結果

4.赤枠をコピーし, DS Downloaderに貼り付ける.

5.オプションで保存先, 最大登録数を設定する.

6.Downloadを押せば、保存先に画像をダウンロードしてきます.

補足

• メリット：画像が多い場合は, 効率良い.
• デメリット：camo.qiitausercontent.com (参考[4])

参考文献

[1] みんな大好きQiitaのバックアップツールを作ったので公開
[2] 自分用 Git For Windowsのインストール手順
[3] はてなブログ内の画像を一括でダウンロードする簡単な方法
[4] Camoでプロキシした画像の元URLを展開するワンライナー

TL;DR

• 表題通りで今更感はありますが、とにかく自分が忘れまくるのでメモ
• リポジトリのURL/compare/from...toで比較可能

ブランチやコミット間の比較をする

こんな感じで。

http://[GitBucketが動作しているホスト]:[ポート]/[リポジトリ名]/compare/[比較対象1]...[比較対象2]

比較対象には、ブランチやコミット、タグなどを指定しましょう。

参考

• GitBucket 3.0をリリースしました
• GitHub / 時間でコミットを比較する

目的

• HomebrewでインストールしているmacOSのGitのバージョンを最新に上げる方法をまとめる

実施方法

1. 現在のGitのバージョンを確認する。

   $ git --version
   

2. Homebrewをアップデートする。

   $ brew update
   

3. Gitのバージョンアップを行う。

   $ brew upgrade git
   

4. Gitのバージョンを確認してバージョンアップされたことを確認する。

   $ git --version
   

はじめに

Git,GitHubを学んでいく上で、用語等を中心に整理していきます。
もうすでにご存知の方、省略の仕方等ご存知でしたら、ご教授願います。

リポジトリ

リポジトリ　：　バージョン管理をするための入れ物（変更履歴を保管）

以下、２種類のリポジトリがある。
　　　
ローカルリポジトリ　：　自分のPC上に置くリポジトリ　
リモートリポジトリ　：　外部サーバーやネットワークに置くリポジトリ

ローカルリポジトリの作成

ターミナルへ入力することを前提とする。

git init　：　当該ディレクトリをGitの管理下におく。
ls .git　：　隠しディレクトリである.gitがあるかどうか確認する。

インデックス

バージョンを記録するためにファイルを一時的に登録する場所のこと

以下、ターミナルへ入力することを前提とする。

git status　：　インデックスに追加されている変更修正、されていない変更修正を確認することができる。
git add　：　インデックスに追加、変更修正記録の対象とすることができる。

コミット

インデックスに追加された変更修正をバージョン記録する操作のこと

git commit -m 'タイトル名'

ログ

コミットの履歴のこと　

git log　：　修正をインデックスに追加する。

さいごに

日々勉強中ですので、随時更新します。
皆様の復習にご活用頂けますと幸いです。

はじめに

弊社プロダクトの開発スピードアップを見込んで、とある国のオフショア企業の力を借りることになり、その開発ディレクティングを行いました。
結果的に契約期間の三ヶ月で打ち切りとなりまして、それにいたった過程・所感などをここに残しておきたいと思います。

契約期間

4ヶ月
（※そのうち、BSEとPGは3ヵ月）

メンバー構成

• BSE（ブリッジシステムエンジニア）×１
  • 現地のPG、テスターへの仕様伝達・メンバー管理・請負企業側とのコミュニケーションが主な業務。
• PG（プログラマー）×5
  • 開発の実行部隊。皆日本語は未対応だが、英語は対応可能。
• テスター×4
  • 各チケット単位でテスト仕様書の作成・テストを実施。
• コンター×１
  • おそらく、コミュニケーターの略。現地語しか対応できないメンバーへの橋渡し役。こちらが作成したチケットの現地語翻訳や、テスターが作ったテスト仕様書の日本語翻訳の他、BSEが不在時の連絡役として対応。

メンバー背景

PGの採用条件として理系大学を卒業していることが必須。コンターは外語大出身、テスターは文系学部出身など、大学の出身学部により職位は別れているようで、PGはテストをしないし、テスターは開発をしないなど完全分業体制であった。

（蛇足ではあるが、WEB案件はPGが取り組むにあたって価値の高い案件ではなく、モチベーションとしては高いものではなかったらしい。）

メリットと感じた点

初回プルリクの作成が早い

平均的に、作業開始から１日でプルリクを作成していたので、スピードは早かった。

BSEはいつでもビデオチャットでチャットよりも早い仕様の伝達ができる

チャットで意思の疎通が完全にできていなかった分、こまめにビデオチャットで対応できたのはよかった。

テスターのテスト粒度が細かい

開発会社側のテスターだけでなく、弊社側でも仕様書の作成を行ったが、こちらはテスト専門にやっていた人間はいなかったため、どうしても、テストケースの粒度が粗くなってしまっていた。

その一方で、テスターは細かい粒度でテストケースを作成していてくれたため、テスト仕様書の品質向上に繋がった。

課題と感じた点

報告・連絡の意識が低い

日本ではありえないことだと思うが、BSEと連絡が全くできなくなる日が三ヶ月のうち二日あった。その理由は体調不良ではなく、私用の理由。BSE以外のチャットでのやりとりが皆無（おそらくPGはやりとりしないといったルールが開発会社側にあったようである。）であったため、その間はPGへの修正依頼が不可能となってしまった。

また、改善策としてBSEが不在時にCTOやコンターが代わりとなることを約束したものの、CTOやコンターも連絡が遅い・一切返信しないなどがあり、一気に信頼度が落ちた。

日本語の習熟度が低い

これは仕方がないこととはいえ、仕様をわかりやすく伝えるためにチケットやビデオチャットでのやり取りの際の文章量が多くなり、日本人PGと比較すると、明らかにコミュニケーションコストの差が大きかった。

また日本語非対応のテスターが作ったテスト仕様書をコンターが翻訳したものをチェックしたが、わかりにくい表現・日本語となっていない部分などが多く、その修正に2~3人で１０数日何時間と対応することになってしまった。

プルリク 後の戻りが最低2~3回生じる

こちらの仕様書の不備、開発会社側の仕様書の低い理解度、PGのテスト未実施、BSEのテスト品質の低さが原因かと思われるが、一つのチケットがマージされOKとなるまで最低２〜３週間かかってしまっていた。

Gitのフローを独自の運用方法以外受け入れない

githubの運用ルールを共有したものの、一切守ってもらえなかった。理由としては、他者で身につけた運用ルールの方が価値が高かったため、守る必要性を感じなかったというのがBSEの言い分であった。

こちらとしても、運用ルールの見直しをするべきであった。しかし開発会社としても、受注元の提示したルールには従う、もしくは新しい運用ルールを提案する姿勢を見せるべきだと思うが、ただこちらの意見を無視するだけだったので、正直ありえないと感じた。

PGがテストをできない

開発会社社内で完全分業としていたため、最初テスターとは契約していなかったため、PGの作業確認・テストはほぼこちらの作業となっていた。PG自らが全くテストをしないせいか、その戻りは確実に２〜3回発生していた。
とりわけ顕著だったのが、デザインラフの画像ファイルを元に修正するチケットで、期待する機能の色になっていないのに完了報告をしたこと。目視で修正点を確認できるにも関わらず、それに気づかず（もしくは無視して）報告するのは正直理解し難い部分であった。

BSEのテスト品質が低い

PGがテストできない分、BSEがテストを実施した上で報告しているということではあったものの、上記のデザインラフの件もあり、BSEの作業チェックはあまり機能していないようだった。

テスターがアカウント作成ルールを守らない

該当プロダクトにログインできるアカウント属性が十数種類にも及ぶため、アカウント名にはルールを儲け入力・登録するように他の関連会社ともルールを守るように伝達した。

しかし、12月末の契約最後までルールを守らず、テスターがテストアカウントを登録してしまったため、「aa」などのクズデータアカウントが今もテスト環境で残ってしまっている。

日本と休日が異なる

これは仕方がない点ではあるが、日本の国民の休日はオフショア側にとっては関係なく稼働日であったため、こちらが休日の際も、BSEからの相談・質問に対応しなければならなかった。（と書いたものの、私自身休日稼働することに抵抗はないので一番課題点は低い。ただし、こちらからの返信が遅くなってしまったのは申し訳なかった。）

インターン生を１人工のPGとして作業させていた

これはBSEが実際に契約完了前にこっそり教えてもらったことであるが、PG３人いたうち、1人はインターン生であり、全くの初心者であったらしい。これは契約開始時に伝達はなかったことである。

反省点

仕様書を用意していなかった

システム・機能が複雑になっているものの、これを外部の人に理解してもらうために十分なドキュメントを用意していなかった。また、作業フローに関しても契約後に用意したので、準備が遅く、これもコミュニケーションコストをあげる原因になっていた。

まとめ

結果的に、50件以上のバグ改修・新機能開発対応とテスト仕様書の作成など助けられた部分は決して小さくはない。しかし、その反面コミュニケーションの難しさに苦しむことが多く、自分で改修した方が早いと感じる部分も多々あった。

今回の開発会社特有の問題点もあったものの、次回またオフショア企業と連携して作業を行う際は、コミュニケーションの壁がどれほどあるかを選定の時点で考慮すべきであり、かつ仕様を全く理解していない外部の人にも理解を助けるようなドキュメントを残すことは必須。

はじめに

弊社プロダクトの開発スピードアップを見込んで、とある国のオフショア企業の力を借りることになり、その開発ディレクティングを行いました。
結果的に契約期間の半年で打ち切りとなりまして、それにいたった過程・所感などをここに残しておきたいと思います。

契約期間

半年
（※そのうち、BSEとPGは5ヵ月）

メンバー構成

• BSE（ブリッジシステムエンジニア）×１
  • 現地のPG、テスターへの仕様伝達・メンバー管理・請負企業側とのコミュニケーションが主な業務。
• PG（プログラマー）×5
  • 開発の実行部隊。皆日本語は未対応だが、英語は対応可能。
• テスター×4
  • 各チケット単位でテスト仕様書の作成・テストを実施。
• コンター×１
  • おそらく、コミュニケーターの略。現地語しか対応できないメンバーへの橋渡し役。こちらが作成したチケットの現地語翻訳や、テスターが作ったテスト仕様書の日本語翻訳の他、BSEが不在時の連絡役として対応。

メンバー背景

PGの採用条件として理系大学を卒業していることが必須。コンターは外語大出身、テスターは文系学部出身など、大学の出身学部により職位は別れているようで、PGはテストをしないし、テスターは開発をしないなど完全分業体制であった。

（蛇足ではあるが、WEB案件はPGが取り組むにあたって価値の高い案件ではなく、モチベーションとしては高いものではなかったらしい。）

メリットと感じた点

初回プルリクの作成が早い

平均的に、作業開始から１日でプルリクを作成していたので、スピードは早かった。

BSEはいつでもビデオチャットでチャットよりも早い仕様の伝達ができる

チャットで意思の疎通が完全にできていなかった分、こまめにビデオチャットで対応できたのはよかった。

テスターのテスト粒度が細かい

開発会社側のテスターだけでなく、弊社側でも仕様書の作成を行ったが、こちらはテスト専門にやっていた人間はいなかったため、どうしても、テストケースの粒度が粗くなってしまっていた。

その一方で、テスターは細かい粒度でテストケースを作成していてくれたため、テスト仕様書の品質向上に繋がった。

課題と感じた点

報告・連絡の意識が低い

日本ではありえないことだと思うが、BSEと連絡が全くできなくなる日が三ヶ月のうち二日あった。その理由は体調不良ではなく、私用の理由。BSE以外のチャットでのやりとりが皆無（おそらくPGはやりとりしないといったルールが開発会社側にあったようである。）であったため、その間はPGへの修正依頼が不可能となってしまった。

また、改善策としてBSEが不在時にCTOやコンターが代わりとなることを約束したものの、CTOやコンターも連絡が遅い・一切返信しないなどがあり、一気に信頼度が落ちた。

日本語の習熟度が低い

これは仕方がないこととはいえ、仕様をわかりやすく伝えるためにチケットやビデオチャットでのやり取りの際の文章量が多くなり、日本人PGと比較すると、明らかにコミュニケーションコストの差が大きかった。

また日本語非対応のテスターが作ったテスト仕様書をコンターが翻訳したものをチェックしたが、わかりにくい表現・日本語となっていない部分などが多く、その修正に2~3人で１０数日何時間と対応することになってしまった。

プルリク 後の戻りが最低2~3回生じる

こちらの仕様書の不備、開発会社側の仕様書の低い理解度、PGのテスト未実施、BSEのテスト品質の低さが原因かと思われるが、一つのチケットがマージされOKとなるまで最低２〜３週間かかってしまっていた。

Gitのフローを独自の運用方法以外受け入れない

githubの運用ルールを共有したものの、一切守ってもらえなかった。理由としては、他者で身につけた運用ルールの方が価値が高かったため、守る必要性を感じなかったというのがBSEの言い分であった。

こちらとしても、運用ルールの見直しをするべきであった。しかし開発会社としても、受注元の提示したルールには従う、もしくは新しい運用ルールを提案する姿勢を見せるべきだと思うが、ただこちらの意見を無視するだけだったので、正直ありえないと感じた。

PGがテストをできない

開発会社社内で完全分業としていたため、最初テスターとは契約していなかったため、PGの作業確認・テストはほぼこちらの作業となっていた。PG自らが全くテストをしないせいか、その戻りは確実に２〜3回発生していた。
とりわけ顕著だったのが、デザインラフの画像ファイルを元に修正するチケットで、期待する機能の色になっていないのに完了報告をしたこと。目視で修正点を確認できるにも関わらず、それに気づかず（もしくは無視して）報告するのは正直理解し難い部分であった。

BSEのテスト品質が低い

PGがテストできない分、BSEがテストを実施した上で報告しているということではあったものの、上記のデザインラフの件もあり、BSEの作業チェックはあまり機能していないようだった。

テスターがアカウント作成ルールを守らない

該当プロダクトにログインできるアカウント属性が十数種類にも及ぶため、アカウント名にはルールを儲け入力・登録するように他の関連会社ともルールを守るように伝達した。

しかし、12月末の契約最後までルールを守らず、テスターがテストアカウントを登録してしまったため、「aa」などのクズデータアカウントが今もテスト環境で残ってしまっている。

日本と休日が異なる

これは仕方がない点ではあるが、日本の国民の休日はオフショア側にとっては関係なく稼働日であったため、こちらが休日の際も、BSEからの相談・質問に対応しなければならなかった。（と書いたものの、私自身休日稼働することに抵抗はないので一番課題点は低い。ただし、こちらからの返信が遅くなってしまったのは申し訳なかった。）

インターン生を１人工のPGとして作業させていた

これはBSEが実際に契約完了前にこっそり教えてもらったことであるが、PG３人いたうち、1人はインターン生であり、全くの初心者であったらしい。これは契約開始時に伝達はなかったことである。

反省点

仕様書を用意していなかった

システム・機能が複雑になっているものの、これを外部の人に理解してもらうために十分なドキュメントを用意していなかった。また、作業フローに関しても契約後に用意したので、準備が遅く、これもコミュニケーションコストをあげる原因になっていた。

まとめ

結果的に、100件以上のバグ改修・新機能開発対応とテスト仕様書の作成など助けられた部分は決して小さくはない。しかし、その反面コミュニケーションの難しさに苦しむことが多く、自分で改修した方が早いと感じる部分も多々あった。

今回の開発会社特有の問題点もあったものの、次回またオフショア企業と連携して作業を行う際は、コミュニケーションの壁がどれほどあるかを選定の時点で考慮すべきであり、かつ仕様を全く理解していない外部の人にも理解を助けるようなドキュメントを残すことは必須。

[student@workstation DO288-apps]$git checkout -b source-build
Switched to a new branch 'source-build'
[student@workstation DO288-apps]$git push -u origin source-build...output omitted...
* [new branch]      source-build -> source-build
Branch source-build set up to track remote branch source-build from origin.

これの意味が分からないので、調べてみた。

リンクのみ提示の他力本願。

git push -u の-uの意味。
https://qiita.com/shumpeism/items/1b8027c8905ca826416d

origin とか master の意味。
https://qiita.com/seri1234/items/e651b3e108a695a92809

結論としては、ローカルで作成したブランチ source-build での変更を、リモートリポジトリの source-build ブランチに紐づける設定？
ローカルブランチは暗黙(前のコマンドgit checkout -bでスイッチしているから)で、git push -u origin source-build で指定している originもsource-buildもリモートリポジトリ上のリソースを指定。
でもローカルブランチ source-buildとリモートブランチ source-buildは一致させておかないと駄目なようだ(エラーになった)。