ドシロウトがherokuのアカウント取得してGitとHeroku CLIをインストールして、デプロイするまで。 　あるいは、なでしこ３のプログラムがherokuで動いたぁ～♪　という話。 発端 　前回の記事で、なでしこさんでLINE Bot作れるようにしたいなぁっていうことを書いたんですけど、ローカルやGoogle Colab上で作れたとしても、どっかにホスト出来なきゃダメですよねー。 　まあ、Node.jsが使えて、なでしこ３がインストール出来るサーバーがあれば、無問題なわけですが、流行りはサーバーレスだからね。よくわかりませんが； 　LINE Messaging APIご本家のチュートリアルではheroku押しみたいなので（？）herokuがいいかなとゆう。だけど、herokuでなでしこさんは動かせるのかな？　ってことでやってみた！ アカウントの作成とインストール 　そもそもherokuって何よ？　とゆう説明はありません（できません；） 　なでしこ３のPC版(cnako3)は入っている前提です。（当然Node.jsも） Herokuのアカウント作成 　日本語だから大丈夫～☆ 　とばかりに、必要事項（赤い*が付いてるとこ）を埋める。 　苗字、名前、メールアドレス。普通ですね。 　役職？！　てなるけど、「趣味でのご利用」ってのがあるのでそれにする。 　主な開発言語は、なでしこ３はNode.jsで動いてますから、「Node.js」を選択ですね。 　そして、「私はロボットじゃありません」にチェックして、「無料アカウント作成」 　すると、herokuさんからメールが来るんですけど・・・英語じゃん！( ；∀；) 　でっでもまあ、よくあるやつですよ。URLをクリックして、本人確認する的な。 　クリックすると、パスワードの入力画面になります。アルファベット、数字、記号全部が含まれてないとダメだからめんどくさい（なんて言ってちゃ今の時代ダメですね。スミマセン＞＜） 　パスワードを入力して、無事アカウント取れました。・・・が！ Page Not Found Our apologies, but we couldn't find that page. Is it possible that you found a bad link? 　なんて？！ 　ページが見つかりませんってどうゆうことなの？！？！（ＴｏＴ） 　しかし、再びherokuさんのログイン画面を開いてメールとパスワード入力したら、ふつーにログイン出来ました！　一安心☆ 　でも、また英語だ・・・英語のページだ・・・利用規約っぽい。Google翻訳さん助けて！ 　・・・・・・Accept。 　で、ようやく「Welcome to Heroku」な画面となりました。 　ここで、新しいアプリを作成したり出来るみたいだね。でででも英語だ・・・ツラい・・・ Gitのインストール 　英語のページですけど簡単です！ Heroku CLIのインストール 　日本語ページがあるので安心です☆ 　ていうか、このHeroku スターターガイドはかなり親切なので、このとうりに学んでいけば、基本的な使い方はバッチリ（たぶんね） 　herokuさん、ドキュメントは日本語あるのに、操作画面は日本語化出来ないんですかね・・・ ローカルでの準備 　とりあえず分かりやすく、デスクトップに「nako3」フォルダを作って、そこで作業することにします。 　えっ、mkdirなんてしりませんよよよょｗ 　ふつーに新規作成→フォルダで作ったよｗｗｗ 作ったフォルダに移動して、そこにpackage.jsonを作る。 cd desktop/nako3 npm init -y 　こんなのできました。 package.json { "name": "nako3", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "keywords": [], "author": "", "license": "ISC" } 　nameは自動でフォルダ名が入って作られますが、好きに変えてだいじょぶっぽい。 　licenseは、変えたければ変える。 用意するファイル テストプログラム 　とりあえず、Expressサーバーをお試ししてみます。 　まあ、ほとんどなでしこ３マニュアルのサンプルどうりなんですけれどね。 　ただ、Herokuさんのポートは、こっちの決め打ちではなく、あちらさんで設定しているPORTという環境変数を読んで上げなきゃいけないようで、PORT=「PORT」の環境変数取得で取得し、一応、手元でお試しする時のために、取得出来なかったらPORT＝8888みたいにしています。 Hallo.nako3 !「plugin_express.js」を取り込む。 PORT=「PORT」の環境変数取得。 もし、(PORT＝null)または(PORT＝空)ならば、PORT＝8888。 PORTでWEBサーバ起動した時には 　　「{PORT}でサーバ起動しました」と表示。 　　# ルーティング設定。 　　「/」へWEBサーバGETした時には 　　　　# サーバからWEBブラウザへ出力 　　　　「<h1>こんにちは、なでしこさん！</h1>」をWEBサーバ出力。 　　ここまで ここまで 動作確認 cnako3 Hallo.nako3 　を実行して、 * [WEBサーバ(なでしこ+Express)] (debug) | 以下のURLで起動しました。 +- [URL] http://localhost:8888 8888でサーバ起動しました [GET] / 　て出て、ブラウザでhttp://localhost:8888を開いたら、「こんにちは、なでしこさん！」と表示されたらＯＫ☆ .gitignore 　gitの管理対象外にするファイルだそうです。 　npmでインストールしたパッケージは、package.jsonのdependenciesで依存関係が定義されていて、それを参照して必要なライブラリがダウンロードされるんで、ライブラリの実体はいらないんだって（！） 　のでnode_modulesは管理対象外にしていい、っていうかしろってことラシイ。 　.gitignore node_modules/ 　他にはlog​ファイルとか​tmp​ディレクトリとかを指定したりするそうです。 　フォルダを指定する時は、(ディレクトリ)/。ファイルには正規表現も使えるっぽい。 package.json 　てことはですよ。package.jsonのdependenciesに依存関係が定義されてさえすればいいってコト？！ 　いやー、コレで、なでしこをどうやって入れたらいいんだ問題は解決ですよ（喜） 　なでしこは、公式ページのインストール方法を見ると、-gを付けてグローバルインストールすることになっています。だから自分とこの環境ではどっからでも使えるんだけど、アップロードして使うには、他のモジュール同様作業フォルダに入れてやらなきゃダメなんじゃ？　って思ってたんです。 　でも、-gを外して特定のフォルダにインストールしようとすると、エラーなって失敗しちゃいます。 　--prefixでフォルダ指定して入れることは出来るんだけど、そうすると、package.jsonに入りません。ツラい・・・ 　と、無知ゆえに色々悩んで色々変なことやらかしましたけどね、もしかして、手作業でdependencies追加するだけで良くね？　ってコトに気が付いたので追記します。 "dependencies": { "nadesiko3": "^3.2.25"　　// バージョン3.2.25は、2021/9/6現在です } 　で、こうなりました。 package.json { "name": "nako3", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "keywords": [], "author": "", "license": "ISC", "dependencies": { "nadesiko3": "^3.2.25" } } 　「"license": "ISC"」の後に「,」を追加するの忘れず！ 　JSONさんが間違ってるよ！　とエラーになってしまいます（しまいました；） 　そのせいで、やっぱダメかも？　と、ムダに時間を費やしてしまったのは内緒；；； Procfile 　アプリの起動時に実行するコマンドを明示的に宣言するファイルです。 　<process type>: <command>と言う書式で、「アプリに Web サーバーが含まれている場合は、その Web サーバーをアプリの ​web​ プロセスとして宣言する必要があります」とゆうことなので、process typeはweb。 　web:の後に、動作確認の時のとうりを記載すればＯＫ。 web: cnako3 Hallo.nako3 できたので、いよいよデプロイ！ Heroku CLIにログイン heroku login 　英語なんて知らねーよと、読まずにぼーっとしてたらダメです。 　なんか止まってると思ったら、キー押せと書いてあったｗ 　キーを押すとブラウザが開くので、Loginボタンを押します。 　メアドとかパスワードとか入れる画面になった場合は入れます。 アプリケーションを作成 　これは、herokuさんのページからでも出来ることだろうけど、基本GUIがいい人だけど、英語なんだもん； 　どっちみち英語なら、こっちの方が早いってゆうか？ heroku apps:create (アプリ名) 　すると、URLが表示されるので、とりあえずメモります。メモらなくてもぜんぜんだいじょぶだったんだけど、気持ち的にｗ 　ナゾ文字の羅列じゃ無くて、ちゃんとアプリ名の入ったURLなんですね。 　無料なのに、しゅごい！ https://(アプリ名).herokuapp.com/ | https://git.heroku.com/(アプリ名).git 　アプリ名・・・とりあえずnadesiko3にしたら、しゅっと通ったんですがね、後から知った所によると、他の人が使ってるアプリ名は使えないんだって。 　まあ、URLがナゾの番号じゃなくて、ちゃんとアプリ名になってるのだから、むべなるかなですが・・・ワタシなんかがnadesiko3を使ってしまって、なんかすまない（汗） デプロイ heroku.bat git init git add . git commit -m "(コメント)" git push -u heroku master 　この一連は、バッチファイルにしておくと超ラクです♪ エラー出る場合 fatal: 'heroku' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. 　新しくアプリを作成したら、その名前のリモートがアプリに合わせて設定されるって書いてあるんだけど、どうも出来てないコトがあるみたいなんだよね。 git remote -v 　してみて、何も出なかったら、手動で追加します。 heroku git:remote -a （アプリ名） 　以下のように表示されたらＯＫ☆ set git remote heroku to https://git.heroku.com/(アプリ名).git 　もっぺんgit remote -vして、確認してみます。 heroku https://git.heroku.com/(アプリ名).git (fetch) heroku https://git.heroku.com/(アプリ名).git (push) 　こう表示されたらＯＫ☆ 　今度はgit push -u heroku master出来る筈。 お試し heroku open 　ブラウザが開いて、「こんにちは、なでしこさん！」と表示されます☆ 　できた！！　やったね！！！ ※「dyno 時間を節約するため、30 分間何も操作が行われないと、無料アプリケーションは自動的にスリープモードに切り替わります」・・・とゆうことで、復帰して表示されるまで、少々時間が掛かる場合があります。 まとめ 　herokuで、ちゃんとなでしこ３のプログラムを動かせることが分かりました。 　LINE Botを始め、色々楽しめそうじゃないですか♪ 　がんばる！ 　・・・ところでherokuってなんて読むんですかね。「へろく」？ 　でも、「へーろく」って読まさるよね～ｗ 　だって、herokuにログインするとユーザー名が表示される右上のメニューアイコン、完全に忍者ですよね？　忍者平六さんですよね？？？ 　とゆうわけで、ワタシは平六さんって呼んでいますｗｗｗ

ブランチとマージ 【復讐】Gitのデータの持ち方 Gitでは、変更差分ではなくスナップショットでデータを管理する。 リポジトリの中で、の3つのファイルでデータを保管している。 ・圧縮ファイル…ファイルの中身を圧縮したもの。（git addにより作成される） ・ツリーファイル…git addした時のスナップショットを記録する。ファイルの中身と、圧縮ファイル名をマッピングする。 ・コミットファイル…ツリーファイル、作成者、日付、コミットメッセージ、親コミットが記録される。 ツリーファイルでスナップショットを記録し、コミットファイルでツリーファイルを指定していることで、コミットはスナップショットを記録していることになる。 まとめると… Gitではコミットでスナップショットを記録して、コミットのparent（親コミット情報）でコミットを時系列順に辿れるようにしている。 ブランチとは 並行して複数機能の開発をするための仕組み。 ブランチを使って分岐して開発をすることで、他のメンバーの行なった変更が、自分の開発には影響を与えないで済む。 ブランチの仕組み ブランチ：コミットファイルを指し示すポインタ（コミットIDを記録したポインタ） HEAD：現在自分が作業しているブランチを指し示すポインタ masterブランチ：Gitのデフォルトのブランチ名 コミットを行うと、ブランチが指し示すコミットファイルが最新のコミットファイルに変わる。 branch　（ブランチを確認・新規追加・変更・削除する） //今あるブランチの一覧を表示する $ git branch //リモートリポジトリも含め、今あるブランチの一覧を表示する $ git branch -a //ブランチを新規追加する（ブランチの切り替えは行わない） $ git branch ブランチ名 //今いるブランチを変更する $ git branch -m ブランチ名 //ブランチを削除する（masterにマージされていない変更が残っている場合は削除しない） $ git branch -d ブランチ名 //ブランチを強制削除する $ git branch -D　ブランチ名 checkout　（ブランチを切り替える） //既存のブランチへ切り替える $ git checkout 既存のブランチ名 //ブランチを新規作成して切り替える $ git checkout -b 新ブランチ名 merge　（変更を統合する） 他の人の変更内容を、自分のブランチに取り込む。 $ git merge ブランチ名　（ローカルブランチの場合） $ git merge　　リモート名/ブランチ名　（リモートブランチを参照する場合） 例 $ git merge origin/master //リモートリポジトリ「origin」のmasuterブランチの内容を、自分の作業中のブランチに統合する mergeには3種類ある ・Fast foward：早送りになるマージ ブランチが枝分かれしていなかったときは、ブランチのポインタを前に進めるだけ。 ・Auto Merge：基本的なマージ ブランチが枝分かれしているときは、作業中のブランチをベースに、mergeしたブランチの変更分を取り込んだ内容をスナップショットとして、マージコミットという新しいコミットが作成される。（parentを2つ持つことになる） ・Conflict 同じファイルの同じ行に対して、複数人が異なる編集をおこなった場合。 コンフリクトを解決する コンフリクトが発生したファイルのコンフリクト箇所には、以下のように表示される。 <<<<<<< HEAD　（現在の変更） あいうえお ======= かきくけこ >>>>>>> feature　（入力側の変更） //HEAD：現在の自分の作業ブランチの内容 //feature：mergeしてきたブランチの内容 コンフリクト解消手順 最終的に残したい内容へ、ファイルの内容を書き換える。 << == >>の記述を削除する。 コンフリクトを起こさないために 複数人で同じファイルを変更しない pullやmergeする前に、変更中の状態をなくしておく。（commitやstashをした上でpullやmergeを行う） pullする際は、pullするブランチに移動してからpullを実行する。 ブランチの利用方法の基本 masterブランチでは開発せず、リリース専用のブランチとする。 開発はトピックブランチを作成して進める。 →こうすることで、masterブランチを常に最新の状態に、リリースしている状態と同じに保つことができる。 参考教材

ローカルリポジトリでの操作 init　（リポジトリを新規作成する） .gitディレクトリが作成される。 // カレントディレクトリにローカルリポジトリを作成 $ git init //指定したディレクトリにローカルリポジトリを作成 $ git init ~/sample Initialized empty Git repository in /Users/******/.git/ clone　（リモートリポジトリのコピーを作成する） GitHubの「Clone or download」より、コピーしたいリポジトリのURLをコピーしておく。 //コピーを保存したいディレクトリに移動しておく $ git clone コピーしたURL status　（ワークツリーやステージの状態を確認する） //現在の状態を確認 $ git status On branch master nothing to commit, working tree clean add　（変更をステージに追加する） ステージがある理由はコミットする変更を準備する為。記録したい変更のみをステージに追加し、一部の変更のみコミットすることが出来る。 git addコマンドの裏側で起こっていることは以下の通り。 ①addしたファイル内容を圧縮したファイルが、リポジトリに作成される。 ②インデックスに、ファイル名と圧縮ファイルの内容をマッピングした情報が記載される。 //指定したファイルの変更をステージに追加する $ git add ファイル名 //すべてのファイルの変更をステージに追加する $ git add . commit　（変更を記録する） //gitのテキストエディタにてコミットメッセージを入力し、変更を記録 $ git commit //エディタを立ち上げることなく、メッセージ付きで変更を記録 $ git commit -m "メッセージ" //エディタが立ち上がり、変更内容をエディタ上で確認することができる $ git commit -v diff　（変更差分を確認する） git diff : ワークツリーとステージの変更差分が表示される git diff --staged : ステージとローカルリポジトリの変更差分が表示される //git addする前の変更分 $ git diff $　　git diff ファイル名 //git addした後の変更分 $ git diff --staged log　（ログ） リポジトリにあるリビジョンを確認する。（最新の変更から順に表示される） $ git log 表示される内容は、以下の通り。 ・リビジョン番号（英数字のハッシュ値） ・コミットしたユーザー名＜メールアドレス＞ ・コミットした日時 ・コミットメッセージ //一行で表示する $ git log --oneline //特定ファイルの変更差分のみ表示する $ git log -p index.html //表示するコミット数を制限する $ git log -n コミット数 rm　（ファイルを削除する） //ローカル（ワークツリー）からも削除する //そもそもファイルが要らなくなった場合 $ git rm ファイル名 //gitの記録からのみファイルを削除し、ローカルにはファイルを残す //例：パスワードの載っているファイルを、誤ってgitにあげてしまった $ git rm --cached　ファイル名 　（バージョン管理しないファイルをGitの管理から外す） .gitignoreファイルに記録する。 例：パスワードを記録した機密ファイル/チーム開発には必要ないファイル/自動生成されるファイル //.gitignoreファイルへの書き方 ・指定したファイルを除外 index.html ・ルートディレクトリを指定 /root.html ・ディレクトリ以下を除外 ディレクトリ名/ GitHubとやり取りする remote add　（ローカルリポジトリとリモートリポジトリを紐づける） GitHubのリモートリポジトリの「Code」をクリックし、表示されるURLをコピーしておく。 ターミナルにて、git initを実行したディレクトリに移動する。 下記コマンドを実行してリモートリポジトリと紐付けしておくことで、今後URLを指定せずともショートカット名前で指定することができる。（ショートカット名にはoriginをよく使う） //紐づける（複数登録することも可能） $ git remote add リモートのショートカット名 コピーしたリポジトリアドレス　 remote　（紐づいているリモートリポジトリを確認する） //登録したリモートのショートカット名を表示（複数登録している場合は複数表示される） $ git remote //対応するURLも表示(fetchとpushの2つ表示される) $ git remote -v リモート名 コピーしたリポジトリアドレス (fetch) リモート名 コピーしたリポジトリアドレス (push) パーソナルアクセストークンの発行 pushする際、GitHubのユーザー名とパーソナルアクセストークンでの認証が必要となる。 GitHub → Settings → Developper settings → Personal access tokens　→ Generate new token より、パーソナルアクセストークンを発行しておく。 ・Note：任意の名前を設定する ・Expiration：有効期間を任意で設定する ・Select scopes：このアクセストークンの所有者に許可する操作にチェックを入れる（全てチェック） ※GitHubにpushする度にこのアクセストークンが必要となるので、必ずコピーしておく。 失くした場合は再発行する。 push　（ローカルの内容をリモートに反映させる） $ git push リモート名 master //初回のみ // -u をつけると、次回以降「git push」のみでorigin masterにpushできる $ git push -u origin master fetch　（リモートから情報を取得する①） リモートリポジトリから、ローカルリポジトリの中のリモート専用の場所（remotes/リモート/ブランチ）へ情報を取得する。 ※fetchのみではワークツリーへは反映しない。 //リモートリポジトリから、ローカルリポジトリへ情報を取得する $ git fetch リモート名 //取得してきたリモートリポジトリの内容を、ワークツリーへ取り込む $ git merge リモート名/ブランチ名 pull　（リモートから情報を取得する②） リモートリポジトリから、ローカルリポジトリの中のリモート専用の場所（remotes/リモート/ブランチ）へ情報を取得し、ワークツリーへ取り込むまでを一つのコマンドで行う。 ※fetchとmergeを一度に行う。 $ git pull リモート名　ブランチ名 pullの注意点 自分が今いるブランチに、pullしてきたブランチの内容が統合される。 例：$ git pull origin hogeを実行する場合 →自分が現在作業しているのがhogeブランチであれば問題ないが、自分がmasterブランチに居るとすると、masterブランチにhogeブランチが統合されてしまう。 変更を元に戻す checkout （ワークツリーでの変更を元に戻す） ステージの状態を取得し、その情報でワークツリーの内容を上書きする。 //特定のファイルを元に戻す $ git checkout -- ファイル名(スペースが必要) //ディレクトリごと元に戻す $ git checkout -- ディレクトリ名 //全変更を取り消す $ git checkout --. reset HEAD （ステージした変更を元に戻す） リポジトリから最新のコミットを取得し、その情報でステージの内容を上書きする。 ※ステージから取り消すだけなので、ワークツリーのファイルには影響を与えない。 ※ワークツリーのファイルからも変更を取消したい場合は、git reset HEADをした後にgit checkoutを行う。 //特定のファイルを元に戻す $ git reset HEAD ファイル名 //ディレクトリごと元に戻す $ git reset HEAD ディレクトリ名 //全変更を取り消す $ git reset HEAD . amend　（直前のコミットをやり直す） 今のステージの状態で、コミットを上書きする。 ※リモートリポジトリへpushしたものは、やり直してはいけない。新しくコミットを作って間違えた内容を修正する。 例：コミットしたけど、一つ修正するのを忘れていた //コミットしたい内容で、git addを済ませておく $ git commit --amend //commitした時のコミットメッセージが立ち上がり、書き直すことができる 参考教材

ローカルリポジトリでの操作 init　（リポジトリを新規作成する） .gitディレクトリが作成される。 // カレントディレクトリにローカルリポジトリを作成 $ git init //指定したディレクトリにローカルリポジトリを作成 $ git init ~/sample Initialized empty Git repository in /Users/******/.git/ clone　（リモートリポジトリのコピーを作成する） GitHubの「Clone or download」より、コピーしたいリポジトリのURLをコピーしておく。 //コピーを保存したいディレクトリに移動しておく $ git clone コピーしたURL status　（ワークツリーやステージの状態を確認する） //現在の状態を確認 $ git status On branch master nothing to commit, working tree clean add　（変更をステージに追加する） ステージがある理由はコミットする変更を準備する為。記録したい変更のみをステージに追加し、一部の変更のみコミットすることが出来る。 git addコマンドの裏側で起こっていることは以下の通り。 ①addしたファイル内容を圧縮したファイルが、リポジトリに作成される。 ②インデックスに、ファイル名と圧縮ファイルの内容をマッピングした情報が記載される。 //指定したファイルの変更をステージに追加する $ git add ファイル名 //すべてのファイルの変更をステージに追加する $ git add . commit　（変更を記録する） //gitのテキストエディタにてコミットメッセージを入力し、変更を記録 $ git commit //エディタを立ち上げることなく、メッセージ付きで変更を記録 $ git commit -m "メッセージ" //エディタが立ち上がり、変更内容をエディタ上で確認することができる $ git commit -v diff　（変更差分を確認する） git diff : ワークツリーとステージの変更差分が表示される git diff --staged : ステージとローカルリポジトリの変更差分が表示される //git addする前の変更分 $ git diff $　　git diff ファイル名 //git addした後の変更分 $ git diff --staged log　（ログ） リポジトリにあるリビジョンを確認する。（最新の変更から順に表示される） $ git log 表示される内容は、以下の通り。 ・リビジョン番号（英数字のハッシュ値） ・コミットしたユーザー名＜メールアドレス＞ ・コミットした日時 ・コミットメッセージ //一行で表示する $ git log --oneline //特定ファイルの変更差分のみ表示する $ git log -p index.html //表示するコミット数を制限する $ git log -n コミット数 rm　（ファイルを削除する） //ローカル（ワークツリー）からも削除する //そもそもファイルが要らなくなった場合 $ git rm ファイル名 //gitの記録からのみファイルを削除し、ローカルにはファイルを残す //例：パスワードの載っているファイルを、誤ってgitにあげてしまった $ git rm --cached　ファイル名 　（バージョン管理しないファイルをGitの管理から外す） .gitignoreファイルに記録する。 例：パスワードを記録した機密ファイル/チーム開発には必要ないファイル/自動生成されるファイル //.gitignoreファイルへの書き方 ・指定したファイルを除外 index.html ・ルートディレクトリを指定 /root.html ・ディレクトリ以下を除外 ディレクトリ名/ GitHubとやり取りする remote add　（ローカルリポジトリとリモートリポジトリを紐づける） GitHubのリモートリポジトリの「Code」をクリックし、表示されるURLをコピーしておく。 ターミナルにて、git initを実行したディレクトリに移動する。 下記コマンドを実行してリモートリポジトリと紐付けしておくことで、今後URLを指定せずともショートカット名前で指定することができる。（ショートカット名にはoriginをよく使う） //紐づける（複数登録することも可能） $ git remote add リモートのショートカット名 コピーしたリポジトリアドレス　 remote　（紐づいているリモートリポジトリを確認する） //登録したリモートのショートカット名を表示（複数登録している場合は複数表示される） $ git remote //対応するURLも表示(fetchとpushの2つ表示される) $ git remote -v リモート名 コピーしたリポジトリアドレス (fetch) リモート名 コピーしたリポジトリアドレス (push) パーソナルアクセストークンの発行 pushする際、GitHubのユーザー名とパーソナルアクセストークンでの認証が必要となる。 GitHub → Settings → Developper settings → Personal access tokens　→ Generate new token より、パーソナルアクセストークンを発行しておく。 ・Note：任意の名前を設定する ・Expiration：有効期間を任意で設定する ・Select scopes：このアクセストークンの所有者に許可する操作にチェックを入れる（全てチェック） ※GitHubにpushする度にこのアクセストークンが必要となるので、必ずコピーしておく。 失くした場合は再発行する。 push　（ローカルの内容をリモートに反映させる） $ git push リモート名 master //初回のみ // -u をつけると、次回以降「git push」のみでorigin masterにpushできる $ git push -u origin master fetch　（リモートから情報を取得する①） リモートリポジトリから、ローカルリポジトリの中のリモート専用の場所（remotes/リモート/ブランチ）へ情報を取得する。 ※fetchのみではワークツリーへは反映しない。 //リモートリポジトリから、ローカルリポジトリへ情報を取得する $ git fetch リモート名 //取得してきたリモートリポジトリの内容を、ワークツリーへ取り込む $ git merge リモート名/ブランチ名 pull　（リモートから情報を取得する②） リモートリポジトリから、ローカルリポジトリの中のリモート専用の場所（remotes/リモート/ブランチ）へ情報を取得し、ワークツリーへ取り込むまでを一つのコマンドで行う。 ※fetchとmergeを一度に行う。 $ git pull リモート名　ブランチ名 pullの注意点 自分が今いるブランチに、pullしてきたブランチの内容が統合される。 例：$ git pull origin hogeを実行する場合 →自分が現在作業しているのがhogeブランチであれば問題ないが、自分がmasterブランチに居るとすると、masterブランチにhogeブランチが統合されてしまう。 remote show　（リモートの詳細情報を確認する） $ git remote show リモート名 remote rename/remote rm（リモートの変更・削除を行う） //リモート名の変更 $ git remote rename　旧リモート名　新リモート名 //リモートの削除 $ git remote rm リモート名 変更を元に戻す checkout （ワークツリーでの変更を元に戻す） ステージの状態を取得し、その情報でワークツリーの内容を上書きする。 //特定のファイルを元に戻す $ git checkout -- ファイル名(スペースが必要) //ディレクトリごと元に戻す $ git checkout -- ディレクトリ名 //全変更を取り消す $ git checkout --. reset HEAD （ステージした変更を元に戻す） リポジトリから最新のコミットを取得し、その情報でステージの内容を上書きする。 ※ステージから取り消すだけなので、ワークツリーのファイルには影響を与えない。 ※ワークツリーのファイルからも変更を取消したい場合は、git reset HEADをした後にgit checkoutを行う。 //特定のファイルを元に戻す $ git reset HEAD ファイル名 //ディレクトリごと元に戻す $ git reset HEAD ディレクトリ名 //全変更を取り消す $ git reset HEAD . amend　（直前のコミットをやり直す） 今のステージの状態で、コミットを上書きする。 ※リモートリポジトリへpushしたものは、やり直してはいけない。新しくコミットを作って間違えた内容を修正する。 例：コミットしたけど、一つ修正するのを忘れていた //コミットしたい内容で、git addを済ませておく $ git commit --amend //commitした時のコミットメッセージが立ち上がり、書き直すことができる 参考教材

はじめに 学習するに至った経緯 未経験からエンジニアへの転職を目指し、プログラミングを勉強中。Git/GitHub/GitHubDesktopの使い方を理解しているところと理解していないところがごちゃ混ぜになっている事が判明。 自身の理解の整理と言語化による認識の深化による備忘録として記載。 Gitとは 『Git』とは、CUI型の分散管理システムで、プログラム編集前と後のバージョン管理や、チームでシステム構築やプロジェクトを共同で行うためのデータ管理作業ができる機能。 ※ 履歴や管理をすることを「リポジトリ」と呼び、リモートで共有するリモートリポジトリ、手元のマシン上に配置するローカルリポジトリの2つに分類される。 Sourcetreeとは 『SourceTree』とは、Atlassian社が提供するGitの分散管理システムツール操作を効率的に扱うGUIで、GUIとはユーザー画面上で視覚的に操作ができる機能。 参考サイト 開発用アプリケーションのインストール、設定「Gitを操作するアプリケーション Sourcetreeのインストール」 SourceTreeとは何？導入までの3ステップと7つの基本操作も紹介

状況・エラー文 はじめて$ git commitコマンドを使う際、コミットメッセージを登録するためのエディタが開かない。 ターミナルには以下のエラーメッセージ。 $ git commit hint: Waiting for your editor to close the file... code --wait: code: command not found error: There was a problem with the editor 'code --wait'. Please supply the message using either -m or -F option. 原因・解決策 code: command not foundとあるので、vscodeのPathが原因と思われる。　 vscodeを開いて設定を行う。 コマンドパレッド（Shift+Command+p)より、シェルコマンド　PATH内にcodeコマンドをインストールしますを選択してインストールすると、解決した。 注 error: unable to start editorとなる場合は、configの設定が必要。 $ git config --global core.editor 'code --wait' 参考記事

起きたこと 先日、GitHubのIDを変更したら、僕の本名がGitHub上に大公開されてしまいましたw 本件の対処と調査の記録を書きます^^ 以下記事と同じことが起きていました。 - Gitで本名が公開されて焦る。【最初にやっておきたい設定】 - githubで本名が暴露してしまった件 原因 コミットのAuthorが漢字の本名になっていた OSのユーザー名を漢字の本名に設定していた。 gitconfigのuser.nameは、デフォルトだとOSのユーザー名になる。 上記2つから、GitのコミットのAuthorが漢字の本名になっていました。 実際に.gitconfigを確認すると、以下のようになっていました。 [user] name = 本名 email = shlia34@users.noreply.github.com この時点で、Gitのコミットには本名が書かれてしまってるわけです。リポジトリをクローンして、git logなどで覗かれると名前がバレます。 GitHubのIDを変更したことによって、IDとnoreplyアドレスが切り離された もともとGitHubが提供してくれているnoreplyアドレスを使用していました。 shlia34@users.noreply.github.comというアドレスでGitにも登録してましたが、shira79にGitHubのIDを変更したため、一致しなくなりました。 Gitのコミットに紐づくアドレスとGitHubに登録してるアドレスが一致する場合、GitHubのアバター・ユーザー名を表示するという仕様らしいです。 (※詳しくは記事末尾の「番外編（なりすましについて）」で触れます。) つまり、今までは一致していたアドレスがIDの変更にとって一致しなくなり、GitHubアカウントではなくGitの情報が表示され今回の現象が起きたということになります。 対応 まずは、.gitconfigを編集して、名前を適当に、アドレスは今回のIDと対応するよう、変更しました。これで今後のコミットは大丈夫です。 次に、過去のコミットの名前とアドレスを変更したいと思います。 僕のコミットは全て僕個人のリポジトリでしたので、以下のコマンドでコミット履歴を変更してからgit push --forceをかましました。(無理やり感が強いですが） GitのCommitユーザを修正する方法 Qiita git filter-branch -f --env-filter "GIT_AUTHOR_NAME='shira'; \ GIT_AUTHOR_EMAIL='shira79@users.noreply.github.com'; \ GIT_COMMITTER_NAME='shira'; \ GIT_COMMITTER_EMAIL='shira79@users.noreply.github.com';" HEAD git push --force origin master 対応は以上です。 番外編（なりすましについて） Gitのコミットに紐づくアドレスとGitHubに登録してるアドレスが一致する場合、GitHubのアバター・ユーザー名を表示するという仕様らしいです。 (ただ正式な記載は見つけられなかったです＞＜) 僕は気づいてしまったんです... ホームディレクトリの.gitconfigのメールアドレスを誰かがGithubアカウントに登録しているメールアドレスに書き換えると以降の自分のすべてのコミットをその誰かのアカウントが行ったとGithub上では表示されることに... なりすまし防止！Githubへの署名付きコミット Qiita .gitconfigを書き換えることでなりすましが成立するのではと思い、友人に許可をもらった上で実験しました^^ 手順は以下になります。 git cloneからのgit logでcommitに紐づくメールアドレスを確認 .gitconfigのuserブロックのemailを取得したアドレスに変更 コミット&プッシュする 実際のリポジトリ : https://github.com/shira79/git-narisumasi 上記コミットのうち、Verifiedタグがついているものは本人のコミットですが、それ以外は僕がなりすましたコミットになります。 Verifiedタグは署名付きのコミットの場合に表示されます。署名付きの場合、本人であることを保証します。GPGまたはS/MIMEを使うことで署名をすることができます。 GitHub Docs コミットに署名する なりすましを防ぐためには、署名付きでコミットしましょうということになります。とはいえ署名なしコミットであればは問題なくできますしGitHubも変わらずなりすましたかのような表示のままです。 すなわち、以下のように整理できるかと思います。 署名付きコミット → 本人であることを保証する 署名なしコミット → 本人かどうかわからない（名乗っているだけ） ちなみにGitHubのリポジトリのブランチの設定画面から、署名済みコミットしか許容しないというオプションもあったりします^^ 感想 名前を晒したところでそんなに困らない 少なくとも僕になりすまそうと思う人はいない 参考リンク 7.4 Git のさまざまなツール - 作業内容への署名 Git コミット署名の検証を管理する GitHub Docs なりすまし防止！Githubへの署名付きコミット Qiita Git でコミット作成者を偽装する方法／署名付きコミットでの対策 Qiita Gitで本名が公開されて焦る。【最初にやっておきたい設定】 githubで本名が暴露してしまった件 GitのCommitユーザを修正する方法 Qiita https://github.com/shira79/git-narisumasi