ラベル git の投稿を表示しています。 すべての投稿を表示
ラベル git の投稿を表示しています。 すべての投稿を表示

2026年6月22日月曜日

GitHubプルリクエスト前の準備の覚書

 GitHubのプロジェクトにプルリクエストをばお願いしてマージしてもらうときに、一般的なプルリクエストの方法などはあちこちで記事にされていますので、それ以外のちょっぴり外れたことをするための覚書です。

  • gitコマンドからgithubにpushする際にパスワードが聞かれますが、パスワードによる認証は廃止されているため、Personal access tokenを取得する必要があります。
    • そこで、まず画面右上のアイコンからuser navigation menuを開き、Settingsを選択します。
    • Settings画面を開いたら、画面左の大量にあるメニュー項目の一番下のDeveloper Settingsを開きます
    • 画面左のメニューからPersonal access tokensを選択し、Fine-grained tokens または Tokens( classic ) を選ぶと、メニューの左側のペイン、要は画面中央にボタンが一つ表示されるので、そいつを押下します。
      押下するとまたもたFine~かclassicかを選ばされる場合がありますが、もう一度選択します。
    • このトークンでgithubにアクセスする場合の権限やら有効期限やら山ほどあるチェックボックスが表示されて問われます。どのくらいの期間をこのトークンで作業するか、そのトークンで作業する際に必要な権限はどんなかな~と判断してチェックしてください。
    • 発行が成功するとすごい長い一行の文字列が表示されますので記憶してくださいムリメモって下さい。そいつが以後gitコマンドを使用する際のパスワード代わりになるトークンです。
    • なお、その画面を閉じると再表示されません。トークンを削除して再発行する必要があります。
    • このトークンはgithubにpushするまで必要ありません。ご苦労様でした。
  • webブラウザでプルリクエストを発出したいプロジェクトの画面を開いてください。
    そして、プロジェクト名の右に並んでいるボタンのうち、Forkをクリックしてください。

  • ↑コレ
  • githubからForkしてきたプロジェクトを自分の開発環境にcloneしてください。
    どっからクローンすんの?って場合はなんだか緑色の <> Code  ボタンを押してください。
    そうすると白く塗りつぶされたところに https://github.com/自アカウント名/リポジトリ名 と表示されていますのでcloneします。
    • Fork元でも開発用のブランチが切られていて、そこだけcloneしたい場合は
      $ git clone -b ブランチ名 https://github.com/自アカウント名/リポジトリ名
      とすると、不要なものがなければ誤操作する可能性も減りますので面倒がありません。
  • cloneしたローカルリポジトリにFork元のプロジェクトを上流リポジトリとして指定します。
    $ git remote add upstream https://github.com/Fork元のリポジトリ名
    • 上流を追加したかどうかを確認するには git remote -v コマンドで確認できます。
    • git fetch コマンドでいつでもローカルとfork元のリポジトリの違いを確認できるようになります。
  • ローカルリポジトリに自分の名前とemailアドレスを設定します。
    $ git config --local user.name 自ユーザ名
    $ git config --local user.email 自メールアドレス
    • githubの設定でメールアドレスを非公開に設定していても、commitログなどでメールアドレスが公開されてしまいますので、明示的に非公開に設定した際に github から発行されたダミーアドレス( ID+username@users.noreply.github.com といった形式です) を、ローカルリポジトリに明示的に設定してあげる必要があります。
      • メールアドレスの公開・非公開は画面右上のアイコン ( User navigation menu ) のSettings 画面左のメニューからEmalisを選択し、 Keep my email addresses private  をOnにします。
    • Windowsの人などは、gitにパーミッションの変更をしただけのファイルを改変とはみなさない設定をすると楽になる場合があるかもしれません。
      $ git config --local core.filemode false
  • cloneしてきたら、さらに自分用にブランチを切るとご安心です。
    $ git checkout -b 自ローカル作業用ブランチ名
  • ここでパッチを当てたい作業をして、作業を完了させます。
  • 成果物をaddしてcommitします。
  • 自ローカルリポジトリをgithubにpushします。
    $ git push origin 自ローカル作業用ブランチ名
    • ここでgithubへのログインのためのアカウントとパスワードを聞かれますが、githubではパスワード認証は廃止されていますので、冒頭で取得したトークンをパスワード代わりに入力します。
    • 間違ってpushしちゃって取り消す場合
      $ git push --delete origin 自ローカル作業用ブランチ名
  • githubのwebインターフェイスを開きます。
    • オリジナルのfork元のプロジェクトが更新されていないかを確認します。
       This branch is up to date with fork元プロジェクト名 
      と表示されていなければ、 Sync fork ボタンを押して最新版と同期します。
    • コンフリクトをしていないことを確認したら Compare & pull requests ボタンを押して、baseブランチとcompareブランチがあっていることを確認してから通常通りpull requestを発出します。
  • レビューをしてもらって指摘を受けた点を修正した場合は、commitしてpushするだけで、webインターフェイスでの操作は必要はありません。
    • マージされたら、ローカルのcloseリポジトリとgithub上の自fork先リポジトリが、fork元のオリジナルリポジトリとの間に差異が生じますので、手動で更新する必要があります。
    • github上の自fork先リポジトリはwebインタフェイスから Sync fork ボタンを押下して同期します。
    • ローカルのcloseリポジトリは、pullまたはcloneし直しが必要です。
以上です。どなた様の役にも立ち層のない記事で申し訳ございません。

2019年4月12日金曜日

ローカル環境にgoogle謹製SDKをインストールせずにGoogle App Engineにプロジェクトをdeployしてみる

たった数年前なのに、Google App Engine(以下GAE)というサービスがいろいろなものと統合されちゃって最近ではGoogle Cloud Platform(以下GCP)とかいうことにしたんですって奥様。

で、今も稼働中の、とあるサーバ機能を持つアプリはeclipseでdeployしてた覚えがあるんですが、もう既に安定稼働につきメンテナンス不要モードに入って何年もたっていて、GAEにアプリをdeployする方法も忘れちゃいました。

そこで、GAEの知識を更新したくなったので、一つなんかやってみるべえ、と思い立ちました。

今ではプロジェクトに選択できる言語が増えていますね。
無償枠で使える言語中から選ぶとすると、javaでのプロジェクトはdeployも運用もすでに経験済みというか運用中だからパスするとして、pythonはインデント縛りのおかげで私にとってメンテがだるい言語だし(インデントを忘れているのか意図しているのかわかりづらいケースがイヤ)、goは開発環境を整えるところから始めなくちゃいけないし、ということで、結局、残っている言語はphpとなりました。

そこで、phpで、アクセスされたら問答無用で四字熟語を送信するサーバを作って、それをGAEにdeployして運用してみようと思います。

余談ですが、以前と大きく変わった点としては、「組織」ってのが必須になっていることです。
これは私のアカウントがG Suiteのせいかもしれません(東日本大震災時に計画停電のせいで自宅サーバがぶっ飛んだ時にgoogle様に独自ドメイン用MXをお願いしたらなぜか今ではG Suiteというサービスになってしまったんですよねぇ)。
そして、めったやたらに権限が細かい。
何をするためにどんな権限が必要なのかがとってもわかりづらくて、プロジェクトを追加する権限は一体どれなんだ、と片っ端から権限を与えてはプロジェクト作成を試すという頭の悪いことをしてしまいましたが、結局どれが「組織なし」へプロジェクトの新規作成ができる権限なのかさっぱりわかりませんでした。
まあ、この辺りは本題から外れますのでいい加減にするとして、本題に戻ります。

ともかくGCP上でプロジェクトを作成してしまいましょう。
さすがにこの手順の解説は端折ります。
ブラウザ画面左上にプロジェクト名が表示が表示されていますから、そこからちゃちゃっと追加してください。

プロジェクトが無事生成出来たら、今度は画面右上の
というアイコンボタンをクリックしますと、bash(Cloud-shell)が立ち上がっちゃいます。

こうなったら、とりあえず自分のプログラムをこのコンソールが立ち上がっているところにダウンロードします。
とりあえず、まずはgitでhttps経由でcloneしてみます。
gitコマンドの使い方は、あまりに文献が豊富なのでここでは説明しませんが、オレオレサーバからhttps経由でcloneしてみます。
無論、別にhttpsでgitじゃなくてもいいんですけど、私が構築してあるgitのbareなリポジトリはgitbucketを利用させていただいている関係でhttpd経由でアクセスするお約束なんですが、そのhttpdがhttps経由でしかgitbucketにアクセスさせない定義になっているというだけの理由です。
あとで触れますがgitである必要性は全くありませんがともあれ説明手順が楽なので一通りこの前提で説明します。

1) オレオレサーバなのでhttps経由の場合は証明書が証明になってねぇよと怒られるので、gitさんに検証をしないで黙って持って来いとお願いする設定にします。
$ git config --global http.sslVerify false
2) オレオレサーバからデプロイしたいプロジェクトをcloneします。
3) cloneしたディレクトリにおります。
4) deployします。
$ gcloud app deploy

以上で終了です。
たったこんだけ。
app.yamlを書き忘れていても3)の段階で書いちゃえばOK。Cloud-shellからはemacsもvimも使えますので宗教論争も無縁です。え?edですか? それはないみたいですね。

んー。gitって何それ?という方に朗報です。
実はscpもsftpもwgetもcurlもCloud-shellから使えるんです。
ですので、開発したプロジェクト一式をzipかなんかで圧縮して、それをCloud-shell上でダウンロードして、展開するだけでいいわけです。
書庫の展開にはunzipもtarも、その他めぼしいところはそろっています。

方法はどうあれ、ソースをgetして展開してdeployしておしまい。
ちょっと前までが信じられないほど極めてシンプルです。

自分の管理下にあるサーバにSDKだのなんだの、得体のしれないものを一切インストールする必要がありません。Cloud-shell上に一式そろっています。

わしの環境じゃあSDKの実行にゃあpython2.7以上が必要じゃけえのう、OSのパッケージ管理システムから外してmake installせんならんけえのう、とか細かいことは何も考えずにデプロイできます。

一度デプロイしちゃえばこっちのものなので、あとはgit cloneしたり tar zxvfしたディレクトリをrm -frしちゃってください。まあ、記念に残しといてもいいですけど。

いやあ、httpsをしゃべれてプログラムも実行できるんですからインスタンス時間が28時間まで無料なGAEってホントにまいっちゃいますね。

で、何をdeployしたのかというと、アクセスすると約7千件あるデータベースの中から四字熟語を1つだけあなたに提案する「提案型四字熟語供給システム」です。大げさでいいでしょ。
インタフェイスはJSONです。供給されるのは四字熟語と、その読み。
どこからでも使えるようにオリジン間リソース共有に対応しています。
一日一語で覚えてゆきましょう。

以上です。
こんな記事をお読みいただいてありがとうございました。

2017年5月20日土曜日

Visual Studio 2017でPushCommand.ExecutePushCommand

週末なのでMicrosoft Visual Studio 2015を2017に更新することにしました。
保守案件がありそうな2008やそれ以前のを残して2012以降をばっさりと切り捨ててすっきりです。

同時にUnityも5.6にしたらAdMobが動かない。。。
開発環境を更新したのですから当然何かあるとは思っていましたが、まずUnity側で事案発生。まあ、所詮誰も遊んでくれないゲームアプリで利用しているだけなので更新することもないでしょうから当分こちらは放置です。

2017はこの段階では別段何事もなさそうだったので、早速Cities: SkylinesのMODを今度発売されたMass Transit DLC用に機能追加をしてテストして無事リリース。
早速早期対応ありがとう(意訳)なコメントをいただいて、照れくさくござる。

ここまでは順調だったのですが、テストを完了してローカルでコミットされていたソース群をオレオレサーバにpushしようとして開発環境移行時多発事案の発生であります。
リモート リポジトリへのブランチのプッシュ中にエラーが発生しました: Git failed with a fatal error.
fatal: unable to access 'https://xxx/yyy.git/': SSL certificate problem: self signed certificate in certificate chain
数年前から趣味で作ったソフト群はサーバ上に設置したgitbucketという大変スバラシイソフトウェア経由で管理しており、それへのアクセスはhttpsを経由して行っていたのですが、先日までの2015では特に叱られもしませんでした。
2017からちゃんと対応するようにしたのでしょうか、オレオレ証明書なんか知らねーよとおむずかりです。

これはまあ、言われた通りにすればいいので、オレオレ認証局の証明書をconfigに追加するか、そもそも証明書のチェックをさせないかのどちらかで対応可能です。
  1. オレオレ認証局の証明書をconfigに追加する場合
    証明書はderじゃだめでpemじゃないとダメな様子です。
    https://oreoreというサーバを証明するca_oreore.derという証明書があったとして、opensslでder形式からpem形式に変換するには以下の構文になります。
    openssl x509 -in ca_oreore.der -inform DER -out ca_oreore.pem -outform PEM
    ここでできたca_oreore.pemを .git/config に、以下を追記してあげます。

    [http "https://oreore/"]
    sslCAInfo = X:/path/to/ca_oreore.pem


    お気づきかと思いますが、ドライブレターがついています。
    ついていないと、標準インストールの場合、
    C:\Program Files (x86)\Microsoft Visual Studio\2017\[エディション名\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\mingw32
    という気が遠くなるような深いパスがrootとなってしまいます。
    素敵な仕様ですネ。
    また、バックスラッシュ(\)ではなくスラッシュで記述したほうがよろしいかと思います。また、"https://oreore/"を省いてもいいのですが、それだとサーバ毎に証明書を設定することはできません。
  2. 証明書をガン無視させたい場合
    .git/configに下記の行を追記します。
    [http]
    sslVerify = false
まあ、ここまでは良かったんですが、いざpushしようとするとさらにおむずかりのようで、コンソールに書きのメッセージがお出ましになられました。
リモート リポジトリへのブランチのプッシュ中にエラーが発生しました: Git failed with a fatal error.
    PushCommand.ExecutePushCommand
こっちは先ほどと違って、何を言ってるのかわかりません。
今現在、記事にしている最中ですが現時点でもさっぱり訳が分かっていません。

PushCommand.ExecutePushCommandで検索すると、2017添付のgitを最新版に更新したら直っただとかopenssl系のdllが混在していただとかいろいろ記事はあるのですが、それらすべてを試しても何の解決にもなりません。

加えてサーバ側のgitリポジトリのアクセス許可や実行ユーザを再度確認したりVisual Studioを再インストールしたり、修復したり、などと試していて、これだけで土曜がつぶれてしまいました。

さらに直接gitコマンドでpushを試みたところ、さらにわけのわからないエラーが。
リモート側に存在しないpackファイルをunpackしようとして存在しない(ないんだからないわな)からって大激怒してるんです、keepだけ残して。
もう本気で意味不明でごわります。

リモートリポジトリからcloneしなおして、再度commit, pushを行っても同様の結果ですし、サーバ側のgitのバージョンは1.8、PC側が2.13ということで、バージョンの違いではないかと考えてサーバ側からpcをmountしてpushしても同様に怒られるし、ほとほと困じ果てました。
ふとコミットを一度取り消し、コミットメッセージを変更してコミットしてpushしたら。。。通りました。

いったいなんなんだ!!
それがしも大激怒です。

テスト用リポジトリを作成し、通らなかったときとまったく同じコミットメッセージをつけてコミットすると、今度は何事もなく通るじゃありませんか。
ますます意味不明です。

git fsckしても問題ないし、cloneはできるし、何がどうなってるのかさっぱりわかりません。

とても恥ずかしいことをしている気がするので、ここにご報告する次第です。