ブログの動機 うっかりして、会社のPCでプライベートのGitにコミットしてしまうと、authorやcommiterが会社のものになってしまいます！ その度にauthorやcommiterを修正するのですが、肝心のコマンドが直ぐに思い付かずググっていました。。。もう二度とググりたくないと誓い、自分用のメモとしてまとめます。 gitコミットログを確認 $ git log --pretty=full commit 186543f9bece44383ab973dc0253946bf09b159f Author: 会社の <会社の@example.com> Commit: 会社の <会社の@example.com> commit message2 commit 25ddf087cfe17f7f71c1fd273eed931b39c71a4b Author: 自分の <自分の@example.com> Commit: 自分の <自分の@example.com> commit message1 authorのみ変更 git rebase -i <修正したいコミットの一個前のコミットハッシュ> 例えば、commit message2のauthorを変更するなら １． git rebase -i 25ddf087cfe17f7f71c1fd273eed931b39c71a4b で修正したい対象のpick -> edit ２． git commit --amend --author="自分の<自分の@example.com>" ３． git rebase --continue authorとcommitter両方変更する git configを修正 configを正しい状態に設定する。 local configを確認する方法： git config --local --list $ git config --local user.name 自分の $ git config --local user.email 自分の@example.com ログを修正 1.git rebase -i <commit hash> 2.git commit --amend --reset-author これを実行することで、一発でcommiterとauthorが修正できる 3.git rebase --continue 4.git log --pretty=full で正しく修正されたのを確認 これで正しく修正できた 補足 一番最初のコミットを修正する際は、 git rebase -i --root <commit hash> でやります。
うっかりして、会社のPCでプライベートのGitにコミットしてしまうと、authorやcommiterが会社のものになってしまいます！ その度にauthorやcommiterを修正するのですが、肝心のコマンドが直ぐに思い付かずググっていました。。。もう二度とググりたくないと誓い、自分用のメモとしてまとめます。
author
commiter
$ git log --pretty=full commit 186543f9bece44383ab973dc0253946bf09b159f Author: 会社の <会社の@example.com> Commit: 会社の <会社の@example.com> commit message2 commit 25ddf087cfe17f7f71c1fd273eed931b39c71a4b Author: 自分の <自分の@example.com> Commit: 自分の <自分の@example.com> commit message1
git rebase -i <修正したいコミットの一個前のコミットハッシュ> 例えば、commit message2のauthorを変更するなら
git rebase -i <修正したいコミットの一個前のコミットハッシュ>
commit message2
１． git rebase -i 25ddf087cfe17f7f71c1fd273eed931b39c71a4b で修正したい対象のpick -> edit ２． git commit --amend --author="自分の<自分の@example.com>" ３． git rebase --continue
configを正しい状態に設定する。 local configを確認する方法： git config --local --list
git config --local --list
$ git config --local user.name 自分の $ git config --local user.email 自分の@example.com
1.git rebase -i <commit hash> 2.git commit --amend --reset-author これを実行することで、一発でcommiterとauthorが修正できる 3.git rebase --continue 4.git log --pretty=full で正しく修正されたのを確認
これで正しく修正できた
一番最初のコミットを修正する際は、 git rebase -i --root <commit hash> でやります。
git rebase -i --root <commit hash>
Gitでbranchを切ろうとしたら「fatal: Not a valid object name: 'master'.」とエラーが出たときの対処法 おそらく、gitでこれからプログラム管理しようとしたときに出くわすエラーだと思います。 エラーの内容としては、 「masterブランチで、何もコミットされてないからmasterすらないよ」って言われてる感じです。 「え？なにそれ！？」みたいな感じでしたが、ひとまずネットで検索してみると コミットすればいいよ的なことが書いてあったので、コミットしてみることに。 なので何でもいいのでコミットすればオッケーです。 ターミナル $ git commit -m "Initial commit" そしたら、コミット処理が始まるのでそれが終わり次第、 ターミナル $ git branch example * master example 以上で、無事ブランチを切ることができました！
おそらく、gitでこれからプログラム管理しようとしたときに出くわすエラーだと思います。
エラーの内容としては、 「masterブランチで、何もコミットされてないからmasterすらないよ」って言われてる感じです。
「え？なにそれ！？」みたいな感じでしたが、ひとまずネットで検索してみると コミットすればいいよ的なことが書いてあったので、コミットしてみることに。
なので何でもいいのでコミットすればオッケーです。
$ git commit -m "Initial commit"
そしたら、コミット処理が始まるのでそれが終わり次第、
$ git branch example * master example
以上で、無事ブランチを切ることができました！
はじめに ※@Yametaro氏リスペクト、ワイ記法でお送りいたします。 こんにちは。 Git使い始めの頃、筆者が犯してしまった過ちを告白します。 筆者は前プロジェクトではテキトーにSVNを使っていましたが、Gitプロジェクトに移行して、結構な過ちを犯してしまいました。 反面教師としてお使いください。 過去に戻るで 過去のワイ 「Gitか……クソややこしいから嫌いなんよ……」 ワイ 「SVNでええやん、なんか簡単ぽいし※」 ※SVNなら理解できていたとは言っていない ワイ 「まずさぁ……」 ワイ 「git pull origin masterってなんやねん」 ワイ 「まずmasterは最新ソースコードの保管所みたいなもんやな。originは……まぁリモートのことやろ。完全に理解した」 ワイ 「んで、肝心のgit pullは……」 ワイ 「何々……git fetchとgit mergeを組み合わせたコマンド……」 ワイ 「mergeってなんやねん。怖いわ。なんかせっかく作ったのとか全部上書きされてしまいそうやん？」 ワイ 「怖いし後にしとこ」 ？？？ 「……て……」 ワイ 「ん？」 ??? 「待て！！！！」 ワイ 「誰や！？」 ??? 「ワシは……Git神!!!」 ワイ 「うわ！！！リー○ス・トー○ルズやんけ！！！」 Git神 「違う！！！Git神だ！！！！」 ワイ 「だからそれリーナ……」 Git神 「違うと言っておろうが！」 Git神 「Git神はGit神なのだ。決して創造神ではない」 ワイ 「なんか見た目同じなんやけどなぁ……まあええわ。で、何しに来たの？」 Git神 「貴様のような無知蒙昧な愚民でもGitﾁｮｯﾄﾃﾞｷﾙように教えに来た」 ワイ 「暴言のキレが凄い」 ワイ 「まあええわ……せっかくやし教えてくれたまえよ」 Git神 「なんで上から目線なんだ貴様」 git pull (origin master)は積極的に Git神 「git pullは怖がらなくていいぞ」 ワイ 「でもなんかせっかく作ったのとか全部上書きされてしまいそうで怖いやん？ 特に同じファイルに更新があったって分かってる場合とか。手戻りしてしまいそうやわ」 Git神 「Gitを舐めるな」 Git神 「Gitを舐めるな」 git_wo_nameruna.py print("Git神 「Gitを舐めるな」") ワイ 「……くどいわ！」 Git神 「まぁGitはﾁｮｯﾄ凄いってことだ」 Git神 「Gitはお前が変更してるところ……ﾁｮｯﾄ専門的な言い方をすると"hunk"……つまり、変更している箇所の断片的なカタマリみたいなものだな。そのカタマリ単位で干渉してない限り、"merge" したときになんやかんやええ感じにお前の作ったコードに反映してくれる。要するに、ﾁｮｯﾄ近いところの更新程度なら干渉しないってことだな。かなりピンポイントで同じ箇所を更新していない限り大丈夫だ。」 Git神 「もう一度繰り返すぞ。なんやかんやええ感じに反映してくれる」 ワイ 「なんやかんやええ感じに！？」 Git神 「なんやかんやええ感じに」 ワイ 「とはいえ、同じところ……その、同じhunkをみんなでいじってたら？」 Git神 「そのときは……まぁ頑張って手で直して」 ワイ 「ええ……」 Git神 「そのときはどこが干渉してるかGit側が教えてくれるから、なんやかんやええ感じに『お前が』直すのだ」 ワイ 「怖い」 Git神 「大丈夫、実際やってみたらそこまで難しくはない。あとファイル名が変更されているとかそういうことがあってもGitは割と上手い感じに拾ってくれるのだ。今の段階だととにかく適当にやってみるのがよい」 Git神 「むしろ最新のmasterを頻繁に反映する癖をつけておかねば、いざってときに滅茶苦茶手元の状態が遅れてて整合性取るのに苦労することが結構あるから、意識的にpullすべきなのだ」 Git神 「あと現場によってはmergeじゃなくてrebaseしたほうが良いとか、git pull origin developの方が良いとか色々あると思うけど、この記事では細かいところには立ち入らぬ。許せ」 ワイ 「誰に向かって言ってんねや(お約束)」 こまめなcommitは良い、雑なcommitは許されない ワイ 「ちょっと疲れたな……ん？なんや上司殿。『緊急対応優先して欲しい』やって？ かしこまり」 ワイ 「今の作業は……うん、今の状態だと全く動かんけどcommitしとくか、commitはこまめにって言うしな」 ワイ 「そもそもgitは個人個人のlocalで管理して作業できるのが魅力なんや、ワイは分かってる。適当にcommitしても許されるんや。」 Git神 「んなわけねーだろ！！！！！！！」 ワイ 「ｸﾞﾜｰｯ！！！！！！！！！(緊急回避)」 ワイ「え、今本気で殴りかかってきた……？？」 Git神 「当たり前だ！！！！貴様の都合でcommitログを汚すな！！！！」 ワイ 「えぇ……だって個々人のローカル環境で分散できるのがgitの魅力で、最終的にpushしてmergeするなら、個々のcommitとか割とどうでもええやん……」 現在のワイ 「↑これ本気で思ってたで……今思うとゾッとするで……」 Git神 「なんで中途半端に知識あるのだ貴様は……それはそうとダメ絶対！！！commitログは一生残る！」 Git神 「しかも『どの作業でどういう変更があったか』は、Gitであってもブランチ単位やプルリクエスト単位で見ることはあるが、『どこかに切り戻す』っていう前提で見ると、やっぱりcommit単位でみることになるのだ」 Git神 「commitをこまめに、かつ毎回きっちり動く状態でしておくことで、"cherry-pick" や "revert"などのとっても便利な機能が使えるし、何より……」 Git神 「良いcommitログは、あとから他の開発者が履歴を見て、それだけで開発の参考になるのだ」 ワイ 「commitログってあの生物進化の系統樹みたいなやつやろ？ あれわけわからんから怖いねん」 Git神 「生物進化の系統樹みたいになるのはブランチの分岐が記録されてるからで、commitそのものとはあまり関係ないのだが……まぁ、大丈夫だ」 Git神 「いつか貴様も系統樹を見てニヤつく優秀な生物学者のごとく、自分が立ち上げたプロジェクトのGitログを見て、それがいかに複雑でも『美しい……』とか呟くようになるから」 ワイ 「なりたくない……」 Git神 「とにかく、だ。今回みたいに『作業を中断して』というときは『stash(スタッシュ)』を使うんやな。それこそゲームで言うところの一時セーブみたいな機能や」 ワイ 「頑張りまスタッシュ」 Git神 「」 ワイ 「」 今のワイによる補足 「Gitのログはシンプルな方が良いっていう観点でrebaseやらsquashを多用して無理やりキレイにする、っていうのは個人的にはあまり好きじゃないで。よっぽど更新内容が軽微だったり無意味なものならともかく、基本的にログは複雑なままでもええと思う。もちろんOSSとして公開前提なら別やけど、クローズな開発現場やったら、例えば迂闊なミスでCI段階でテストが落ちてしまったとして、その修正後、ログをキレイにするために工数かけるのってアホらしいと思うのよね。まぁこれはあくまでも個人の意見として聞いてくれや」 ワイ 「……ハッ、なんか未来が見えた！！！！！」 Git神 「大丈夫か貴様」 ワイ 「……なんや……未来が流れ込んでくる……！？」 Git神 「大丈夫か……？ 貴様ーーーーーーーーーーーッ！！！！」 現在のワイに戻る 現在のワイ 「ふぅ……」 現在のワイ 「ここまで書いて思ったけど」 最新のmasterをpullすることに謎の抵抗があった stashの代わりにcommitしてた 現在のワイ 「このふたつの過ちが大きすぎて他が思いつかへん……」 現在のワイ 「特に2番目はもし今の現場でするやつがおったら今すぐ会議室に連れ込んでGit教え込むレベルやわ……」 現在のワイ 「Gitは神のツールや。怖がらず使い倒すことで真価を発揮する」 現在のワイ 「--force ってつける強制系のコマンドは危険なことが多いけど、それ以外は取り返しつくことがほとんどやからな。失敗しまくって覚えたらええ」 現在のワイ 「間違ったcommitしたり、commitのコメント間違ったり。そういった失敗をどう直すかって考えてる中でだんだんと使い方が分かってくるんや」 現在のワイ 「そう、失敗しないことが一番の失敗なんや」 現在のワイ 「ええこと言ったから終わるで」 Git神 「特にオチないのか貴様……」 ついでに 「Gitでここが困った！」的なまとめって結構需要ありそうな気がするんですが、Gitって「理解してる人」と「なんとなくで使い続けてる人」に二極化するツールな気がしてて、いずれにせよ「ここが困った」って具体的に言うのって難しい気がするんですよね。 前者の場合、あらゆる「困った」はいつの間にか勉強して解決済みですし、後者の場合「何が困ってるか」が分からない状態だったりしますし。 Gitって、本気で使い倒そうとすると滅茶苦茶多機能ですからね。 何かそういった初心者あるある事例持ってる方いらっしゃいましたら是非お気軽にコメントしてくださいね。 ではまた。
※@Yametaro氏リスペクト、ワイ記法でお送りいたします。
こんにちは。
Git使い始めの頃、筆者が犯してしまった過ちを告白します。 筆者は前プロジェクトではテキトーにSVNを使っていましたが、Gitプロジェクトに移行して、結構な過ちを犯してしまいました。 反面教師としてお使いください。
過去のワイ 「Gitか……クソややこしいから嫌いなんよ……」
ワイ 「SVNでええやん、なんか簡単ぽいし※」 ※SVNなら理解できていたとは言っていない
ワイ 「まずさぁ……」
ワイ 「git pull origin masterってなんやねん」
ワイ 「まずmasterは最新ソースコードの保管所みたいなもんやな。originは……まぁリモートのことやろ。完全に理解した」
ワイ 「んで、肝心のgit pullは……」
ワイ 「何々……git fetchとgit mergeを組み合わせたコマンド……」
ワイ 「mergeってなんやねん。怖いわ。なんかせっかく作ったのとか全部上書きされてしまいそうやん？」
ワイ 「怖いし後にしとこ」
？？？ 「……て……」
ワイ 「ん？」
??? 「待て！！！！」
ワイ 「誰や！？」
??? 「ワシは……Git神!!!」
ワイ 「うわ！！！リー○ス・トー○ルズやんけ！！！」
Git神 「違う！！！Git神だ！！！！」
ワイ 「だからそれリーナ……」
Git神 「違うと言っておろうが！」
Git神 「Git神はGit神なのだ。決して創造神ではない」
ワイ 「なんか見た目同じなんやけどなぁ……まあええわ。で、何しに来たの？」
Git神 「貴様のような無知蒙昧な愚民でもGitﾁｮｯﾄﾃﾞｷﾙように教えに来た」
ワイ 「暴言のキレが凄い」
ワイ 「まあええわ……せっかくやし教えてくれたまえよ」
Git神 「なんで上から目線なんだ貴様」
Git神 「git pullは怖がらなくていいぞ」
ワイ 「でもなんかせっかく作ったのとか全部上書きされてしまいそうで怖いやん？ 特に同じファイルに更新があったって分かってる場合とか。手戻りしてしまいそうやわ」
Git神 「Gitを舐めるな」
print("Git神 「Gitを舐めるな」")
ワイ 「……くどいわ！」
Git神 「まぁGitはﾁｮｯﾄ凄いってことだ」
Git神 「Gitはお前が変更してるところ……ﾁｮｯﾄ専門的な言い方をすると"hunk"……つまり、変更している箇所の断片的なカタマリみたいなものだな。そのカタマリ単位で干渉してない限り、"merge" したときになんやかんやええ感じにお前の作ったコードに反映してくれる。要するに、ﾁｮｯﾄ近いところの更新程度なら干渉しないってことだな。かなりピンポイントで同じ箇所を更新していない限り大丈夫だ。」
Git神 「もう一度繰り返すぞ。なんやかんやええ感じに反映してくれる」
ワイ 「なんやかんやええ感じに！？」
Git神 「なんやかんやええ感じに」
ワイ 「とはいえ、同じところ……その、同じhunkをみんなでいじってたら？」
Git神 「そのときは……まぁ頑張って手で直して」
ワイ 「ええ……」
Git神 「そのときはどこが干渉してるかGit側が教えてくれるから、なんやかんやええ感じに『お前が』直すのだ」
ワイ 「怖い」
Git神 「大丈夫、実際やってみたらそこまで難しくはない。あとファイル名が変更されているとかそういうことがあってもGitは割と上手い感じに拾ってくれるのだ。今の段階だととにかく適当にやってみるのがよい」
Git神 「むしろ最新のmasterを頻繁に反映する癖をつけておかねば、いざってときに滅茶苦茶手元の状態が遅れてて整合性取るのに苦労することが結構あるから、意識的にpullすべきなのだ」
Git神 「あと現場によってはmergeじゃなくてrebaseしたほうが良いとか、git pull origin developの方が良いとか色々あると思うけど、この記事では細かいところには立ち入らぬ。許せ」
ワイ 「誰に向かって言ってんねや(お約束)」
ワイ 「ちょっと疲れたな……ん？なんや上司殿。『緊急対応優先して欲しい』やって？ かしこまり」
ワイ 「今の作業は……うん、今の状態だと全く動かんけどcommitしとくか、commitはこまめにって言うしな」
ワイ 「そもそもgitは個人個人のlocalで管理して作業できるのが魅力なんや、ワイは分かってる。適当にcommitしても許されるんや。」
Git神 「んなわけねーだろ！！！！！！！」
ワイ 「ｸﾞﾜｰｯ！！！！！！！！！(緊急回避)」
ワイ「え、今本気で殴りかかってきた……？？」
Git神 「当たり前だ！！！！貴様の都合でcommitログを汚すな！！！！」
ワイ 「えぇ……だって個々人のローカル環境で分散できるのがgitの魅力で、最終的にpushしてmergeするなら、個々のcommitとか割とどうでもええやん……」
現在のワイ 「↑これ本気で思ってたで……今思うとゾッとするで……」
Git神 「なんで中途半端に知識あるのだ貴様は……それはそうとダメ絶対！！！commitログは一生残る！」
Git神 「しかも『どの作業でどういう変更があったか』は、Gitであってもブランチ単位やプルリクエスト単位で見ることはあるが、『どこかに切り戻す』っていう前提で見ると、やっぱりcommit単位でみることになるのだ」
Git神 「commitをこまめに、かつ毎回きっちり動く状態でしておくことで、"cherry-pick" や "revert"などのとっても便利な機能が使えるし、何より……」
Git神 「良いcommitログは、あとから他の開発者が履歴を見て、それだけで開発の参考になるのだ」
ワイ 「commitログってあの生物進化の系統樹みたいなやつやろ？ あれわけわからんから怖いねん」
Git神 「生物進化の系統樹みたいになるのはブランチの分岐が記録されてるからで、commitそのものとはあまり関係ないのだが……まぁ、大丈夫だ」
Git神 「いつか貴様も系統樹を見てニヤつく優秀な生物学者のごとく、自分が立ち上げたプロジェクトのGitログを見て、それがいかに複雑でも『美しい……』とか呟くようになるから」
ワイ 「なりたくない……」
Git神 「とにかく、だ。今回みたいに『作業を中断して』というときは『stash(スタッシュ)』を使うんやな。それこそゲームで言うところの一時セーブみたいな機能や」
ワイ 「頑張りまスタッシュ」
Git神 「」
ワイ 「」
今のワイによる補足 「Gitのログはシンプルな方が良いっていう観点でrebaseやらsquashを多用して無理やりキレイにする、っていうのは個人的にはあまり好きじゃないで。よっぽど更新内容が軽微だったり無意味なものならともかく、基本的にログは複雑なままでもええと思う。もちろんOSSとして公開前提なら別やけど、クローズな開発現場やったら、例えば迂闊なミスでCI段階でテストが落ちてしまったとして、その修正後、ログをキレイにするために工数かけるのってアホらしいと思うのよね。まぁこれはあくまでも個人の意見として聞いてくれや」
ワイ 「……ハッ、なんか未来が見えた！！！！！」
Git神 「大丈夫か貴様」
ワイ 「……なんや……未来が流れ込んでくる……！？」
Git神 「大丈夫か……？ 貴様ーーーーーーーーーーーッ！！！！」
現在のワイ 「ふぅ……」
現在のワイ 「ここまで書いて思ったけど」
現在のワイ 「このふたつの過ちが大きすぎて他が思いつかへん……」
現在のワイ 「特に2番目はもし今の現場でするやつがおったら今すぐ会議室に連れ込んでGit教え込むレベルやわ……」
現在のワイ 「Gitは神のツールや。怖がらず使い倒すことで真価を発揮する」
現在のワイ 「--force ってつける強制系のコマンドは危険なことが多いけど、それ以外は取り返しつくことがほとんどやからな。失敗しまくって覚えたらええ」
現在のワイ 「間違ったcommitしたり、commitのコメント間違ったり。そういった失敗をどう直すかって考えてる中でだんだんと使い方が分かってくるんや」
現在のワイ 「そう、失敗しないことが一番の失敗なんや」
現在のワイ 「ええこと言ったから終わるで」
Git神 「特にオチないのか貴様……」
「Gitでここが困った！」的なまとめって結構需要ありそうな気がするんですが、Gitって「理解してる人」と「なんとなくで使い続けてる人」に二極化するツールな気がしてて、いずれにせよ「ここが困った」って具体的に言うのって難しい気がするんですよね。 前者の場合、あらゆる「困った」はいつの間にか勉強して解決済みですし、後者の場合「何が困ってるか」が分からない状態だったりしますし。 Gitって、本気で使い倒そうとすると滅茶苦茶多機能ですからね。
何かそういった初心者あるある事例持ってる方いらっしゃいましたら是非お気軽にコメントしてくださいね。
ではまた。
Rails チュートリアル 3章までのエラーと対処法 ProgateでRuby, Rails, Git, HTML&CSS 終了後にスタートしました。 事前知識は大学の授業でC言語を少し扱ったくらい。 ～1章 環境構築でのエラー ProgateのRuby on Railsの環境構築の記事を見ながら進めていったとところ、rails new でフォルダが生成されず。 調べたところRails5.0以上ではNode.jsが必要なようで、インストールし解決しました。 Herokuへのデブロイ その後1.5までは順調に進められましたがHerokuへのデブロイでエラー。 $ git push heroku master で $ heroku open すると、Application errorの画面が。 heroku logsでエラーの確認をしてもよく分からず、2日ほど試行錯誤。 その後あきらめてteratailで質問を投稿したところ、Rails6でのデブロイの方法がRails5までと異なるという回答を頂きました。 そこで初めて自分がRails6を使っていることに気がつき、バージョンを指定してRails newからやり直し。Rails6でのデブロイは複雑だったのであきらめました。 Rails6でのデブロイ しかしそれでもデブロイできず。 エラー文をよく見るとApp crashとありました。それを元に色々調べると、postgresqlを使用することを、 config/database.yml で明記する必要があるようでした。 修正前 database.yml production: <<: *default database: db/production.sqlite3 修正後 database.yml production: <<: *default adapter: postgresql database: db/production.postgresql Gemfileを書き換えるだけではだめだったようです。ここのエラーが今までで一番時間がかかり、3日くらい取られてしまいました。 2,3章 2章、3章ではそこまで大きくつまづくことはありませんでしたが、Gemfile変更後にbundle installや、Herokuへデブロイする前にcommitするのを忘れるミスがかなりありました。 まとめ Progateは1周しかしておらず、かなり答えを見てしまうくらいの理解度だったのでまだRails チュートリアルは早いかと思いましたが、2週するのはめんどうだったので始めてみました。 期間は3章までで1週間くらい。今のところ少し時間がかかっていますが、1月中に終了を目標にがんばっていきます。
ProgateでRuby, Rails, Git, HTML&CSS 終了後にスタートしました。 事前知識は大学の授業でC言語を少し扱ったくらい。
ProgateのRuby on Railsの環境構築の記事を見ながら進めていったとところ、rails new でフォルダが生成されず。
調べたところRails5.0以上ではNode.jsが必要なようで、インストールし解決しました。
その後1.5までは順調に進められましたがHerokuへのデブロイでエラー。
$ git push heroku master で $ heroku open すると、Application errorの画面が。
heroku logsでエラーの確認をしてもよく分からず、2日ほど試行錯誤。 その後あきらめてteratailで質問を投稿したところ、Rails6でのデブロイの方法がRails5までと異なるという回答を頂きました。
そこで初めて自分がRails6を使っていることに気がつき、バージョンを指定してRails newからやり直し。Rails6でのデブロイは複雑だったのであきらめました。
Rails6でのデブロイ
しかしそれでもデブロイできず。
エラー文をよく見るとApp crashとありました。それを元に色々調べると、postgresqlを使用することを、
config/database.yml
で明記する必要があるようでした。
修正前
production: <<: *default database: db/production.sqlite3
修正後
production: <<: *default adapter: postgresql database: db/production.postgresql
Gemfileを書き換えるだけではだめだったようです。ここのエラーが今までで一番時間がかかり、3日くらい取られてしまいました。
2章、3章ではそこまで大きくつまづくことはありませんでしたが、Gemfile変更後にbundle installや、Herokuへデブロイする前にcommitするのを忘れるミスがかなりありました。
Progateは1周しかしておらず、かなり答えを見てしまうくらいの理解度だったのでまだRails チュートリアルは早いかと思いましたが、2週するのはめんどうだったので始めてみました。
期間は3章までで1週間くらい。今のところ少し時間がかかっていますが、1月中に終了を目標にがんばっていきます。
リモートリポジトリとのやりとり リモートリポジトリを新規ディレクトリにコピー git clone <リポジトリのURL> 上流ブランチ（デフォルトで origin レポジトリ）を現在のブランチにマージ git pull 上流ブランチを指定して現在のブランチを反映 git push -u origin <ブランチ名> 現在のブランチを上流ブランチに反映 git push ブランチの操作 ブランチのリストを表示 git branch ブランチを作成して切り替え git checkout -b <ブランチ名> ブランチを切り替え git checkout <ブランチ名> 指定したブランチを現在のブランチにマージ git merge <ブランチ名> ブランチを削除 git branch -d <ブランチ名> ローカルリポジトリでの操作 変更されたファイルを確認 git status 変更箇所を確認 git diff ファイルの追加・更新をインデックスに追加してコミット git add <ファイル/ディレクトリのパス> git commit -m "<コメント>" すべてのファイルの更新をインデックスに追加してコミット git commit -am "<コメント>"
git clone <リポジトリのURL>
origin
git pull
git push -u origin <ブランチ名>
git push
git branch
git checkout -b <ブランチ名>
git checkout <ブランチ名>
git merge <ブランチ名>
git branch -d <ブランチ名>
git status
git diff
git add <ファイル/ディレクトリのパス> git commit -m "<コメント>"
git commit -am "<コメント>"
個人開発の成果をアピールしたいならGitHub 無料でソースを非公開に管理したいならGitLab ソースを非公開に管理しつつUIもいい感じのやつ使いたいならBitBucket って感じでしょうかね。 参考 https://www.geeksforgeeks.org/bitbucket-vs-github-vs-gitlab/ https://qiita.com/hiroponz/items/c1ed4d6c10484233bf88
個人開発の成果をアピールしたいならGitHub 無料でソースを非公開に管理したいならGitLab ソースを非公開に管理しつつUIもいい感じのやつ使いたいならBitBucket
って感じでしょうかね。
https://www.geeksforgeeks.org/bitbucket-vs-github-vs-gitlab/ https://qiita.com/hiroponz/items/c1ed4d6c10484233bf88
