- 投稿日:2019-10-08T18:26:52+09:00
Railsチュートリアル 第3章<復習>
第3章の復習メモです。
個人的に重要と思ったことを書きます。
調べたことや、知っていたことも含めて書きます。Webページの作成
Railsで、Webページ作成に最低必要なのは、以下の3つ。
- URLのルーティング
- 1に対応するコントローラ及び、アクションの作成
- 2に対応するビューの作成
以下のコマンドを実行すると、上記3つを自動生成してくれる。
$ rails generate controller <コントローラ名> <アクション名1> <アクション名2> <アクション名xx>
- ルーティングについて
- config/routes.rbファイルにルーティングが追記される。
- コントローラについて
- 慣習的に、コントローラ名はキャメルケース(頭だけ大文字)で記載する。
- 生成されるコントローラは、スネークケース(単語間を_でつないだ形)になる。
- アクション名は全て小文字にする。また、いくつ書いても良い。
- ビューについて
- コントローラのアクション毎、ビューが生成される。
切り戻しについて
コマンドを打ち間違えて、変なファイルを作ってしまった場合、
元の状態に戻すためのコマンドが用意されている。
- コントローラを戻す
$ rails destroy controller <モデル名> <アクション名1> <アクション名2>
- モデルを戻す
$ rails destroy model <モデル名>
- DBへの反映を1つ戻す
$ rails db:rollback
- DBへの反映を全部戻す
$ rails db:migrate VERSION=0テストについて
$ rails testで、テストを実行できる。
テストコードは、あらかじめ生成されている物もある。
また、Guardを使ってテストを自動化できるみたい。
詳しく理解するのはまたの機会に。Gitについて
git push origin <ブランチ名>で、GitHub上のブランチにPUSHされる。
GitHubにブランチが存在しない場合、新規作成される。最低限、3章まではやろうと思っていたので、目標は達成しました。
4章以降についても、できれば続けていきたいと思います。
- 投稿日:2019-10-08T18:17:25+09:00
空のディレクトリをgithubに上げる
- 投稿日:2019-10-08T17:57:55+09:00
gitでcloneときに使用するSSHキーを指定する方法
結論
一発
$ ssh-agent $(ssh-add 秘密鍵のパス; git clone リモートリポジトリ)参照
How to specify the private SSH-key to use when executing shell command on Git?
- 投稿日:2019-10-08T17:53:15+09:00
指定したPathのファイルのみStashする方法
指定したPathのファイルのみStashする方法
検索してもヒットしなかったので、gitのhelpで見つけました。
git stash push -m "message" -- filepath/to/stash今回のこのやり方はこのコマンドの出力結果から確認できます。
git stash --help
... git stash [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet] [-u|--include-untracked] [-a|--all] [-m|--message <message>] [--] [<pathspec>...]] ... push [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [-m|--message <message>] [--] [<pathspec>...] Save your local modifications to a new stash entry and roll them back to HEAD (in the working tree and in the index). The <message> part is optional and gives the description along with the stashed state. For quickly making a snapshot, you can omit "push". In this mode, non-option arguments are not allowed to prevent a misspelled subcommand from making an unwanted stash entry. The two exceptions to this are stash -p which acts as alias for stash push -p and pathspecs, which are allowed after a double hyphen -- for disambiguation. When pathspec is given to git stash push, the new stash entry records the modified states only for the files that match the pathspec. The index entries and working tree files are then rolled back to the state in HEAD only for these files, too, leaving files that do not match the pathspec intact. If the --keep-index option is used, all changes already added to the index are left intact. If the --include-untracked option is used, all untracked files are also stashed and then cleaned up with git clean, leaving the working directory in a very clean state. If the --all option is used instead then the ignored files are stashed and cleaned in addition to the untracked files. With --patch, you can interactively select hunks from the diff between HEAD and the working tree to be stashed. The stash entry is constructed such that its index state is the same as the index state of your repository, and its worktree contains only the changes you selected interactively. The selected changes are then rolled back from your worktree. See the "Interactive Mode" section of git-add(1) to learn how to operate the --patch mode. The --patch option implies --keep-index. You can use --no-keep-index to override this. ...以前は
git stash save -m "message" -- filepath/to/stashで出来たような気がしましたが、仕様が変わってしまったのでしょうか。
追記(2019/10/08)
コメントをいただき、
git commit save
はdeprecatedになっているそうです。save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>] This option is deprecated in favour of git stash push. It differs from "stash push" in that it cannot take pathspecs, and any non-option arguments form the message.
- 投稿日:2019-10-08T14:31:19+09:00
EGitが使いやすすぎた
EGit
EclipseからGitを使うやつです
これが地味に楽で便利なんですわ
できること一覧
eclipseでgitのパースペクティブを開きましょう
できること一覧
- リポジトリをクローン
- クローンしたプロジェクトをプロジェクトエクスプローラから編集していく
- ローカルでブランチを作成
- ステージング
- ブランチのヒストリーを見る
- コミット及びプッシュ
- ヒストリーからコミットを複数選択してスカッシュ
- リベース
- 強制プッシュ(変更の強制)
- 差分を確認
- 競合解消
...全部じゃん
別でTortoiseGitとかGitBashとか使わんでも困らんくらいいろいろできますね
しかもGUIなんで見やすい。
GitBashに慣れてる自分的には快適です!
Gitについて地味に不安を抱えている人が多い雰囲気を感じたら、こういったできること一覧だけでなく
それぞれの操作がどういう意味なのか
なにができるのか
いつ使えばいいのか
どういう利点と欠点があるのかとかまとめてみたいなって思ってます!
今回はEGitスゲー回でした
- 投稿日:2019-10-08T11:54:30+09:00
心配性が始めるgit管理(確認/修正をするgitコマンド集)
2019/10/09追記
- 頂いたコメントから コミットそのものをミスった -> コミット取り消しに追記
- 同項に注意事項を追記はじめに
今年の3月に大学を卒業し、4月からアプリを作る会社に入社した者です。
iOSアプリを作るエンジニアしてます。Androidアプリも勉強してます。超心配性です。
仕事で当然Gitを使う訳ですが、、、これが新米エンジニアには難しい。
入社直後、.gitignoreの設定をミスってしまい、FilesChanged
が7000を超えるトンデモPRを生み出したことがあります。(その後.gitignoreの設定を直したら、今度はなぜか.xcodeprojファイルがぶっ壊れて...と修正に丸々1日潰しました )それ以来、超超心配性な性格も相まって
「.gitignoreの設定反映されてないかな...」
「このままpushしても大丈夫かな...コミット履歴ミスってないかな...」
「mergeのブランチ間違えてないかな...」
と必要以上の心配をすることがあります。その度に調べるのは大変なので、何かを確認/修正するgitコマンドを中心に紹介します。
随時更新したいです。何かが心配な時に使うコマンド
.gitignoreがちゃんと働いているか心配
ignoreされたファイルを表示、
$ git status --ignored On branch develop (中略) Ignored files: (use "git add -f <file>..." to include in what will be committed) .DS_Store Carthage/ Pods/ #... #ignoreされたファイルどのファイルがステージングされてるか心配 -> 一覧を見る
$ git ls-files<img width="327" alt="スクリーンショット 2019-10-08 11.39.10.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/203273/59749482-6cf1-70fe-4a20-fe020b7b92c6.png"> .gitignore Podfile Podfile.lock README.md hogeProject/HogeViewController.swift (略)ステージングされたファイルの一覧
merge元のブランチとmerge先のブランチが合っているか心配
feature
ブランチで編集中に、develop
ブランチに変更が加わり、feature
ブランチにもその変更を反映したいとき
「あれ?featureブランチでmerge叩けばいいんだっけ? 」
ミスってもgit revert
とかすればいいんですが。初心者心配性エンジニアはそれを知っててもmerge前に1回心配します。$ git checkout feature Switched to branch 'feature' $ git merge develop --no-commit Automatic merge went well; stopped before committing as requestedマージコミットが作られないけどdevelopブランチの変更が取り込まれた状態になります。
ワーキングツリーを確認してcommitすればちゃんとmergeされた状態になるし、間違えてたらgit merge --abort
すれば良さそうです。addの前に変なファイルがaddされたりしないか心配
$ git add --dry-run <addする予定のファイル> add 'addする予定のファイル' # 実際にaddされるわけではないpushの前に今いるブランチは間違えてないか、push先のブランチは間違えてないか心配
$ git push -n <リモート名> <プッシュ先ブランチ> To https://github.com/hogehoge/fugafuga.git 123456..7890ab local_branch -> remote/branch # 実際にpushされるわけではない要は前述の
--dry-run
と同じです何かをミスった時に使うコマンド
たとえ 超超超心配性 でも、「ミスっても○○すれば直るから大丈夫だもんね!」というお気持ちになれれば心強いもの。
コミットコメントをミスった -> 直前のコミットを編集
viが開かれ、コミットメッセージを編集できる
$ git commit --amendコミットそのものをミスった -> コミット取り消し
$ git reset (オプション) HEAD~
reset
コマンドはオプションとresetするコミットの指定方法によって色々できます
オプション
--soft
commitのみ取り消し--mixed
commit, add取り消し(オプションなしの場合もこれ)--hard
または--merge
そもそもの変更ごと取り消しどこまで戻すか
HEAD
最新コミットまで戻る(最後のコミット後に変更した内容だけreset)HEAD~
またはHEAD^
またはHEAD@{1}
コミット1つだけresetHEAD~~~
またはHEAD^^^
(n個~や^をつける)またはHEAD@{n}
またはHEAD~n
コミットn個reset
※~
と^
にも一応違いがあるようですが、resetする分にはほとんど違いがないはずです。。。 https://qiita.com/chihiro/items/d551c14cb9764454e0b9(2019/10/09追記、コメントありがとうございます )
HEAD
のエイリアスとして@
が使えるので、上記のHEAD
を@
として置き換えても可です
git reset
もミスった -> reset取り消し$ git reset --hard ORIG_HEAD作成するブランチ名をミスった -> ブランチ名変更
$ git branch -m <変更前のブランチ名> <変更後のブランチ名>マージをミスった -> マージ取り消し
$ git merge --abortコミットするブランチを間違えた -> cherry-pick
(移動先のブランチに移動してから) $ git cherry-pick <移動元ブランチでのハッシュ値>マージしたらコンフリクトした(マージをキャンセルする場合)
$ git merge --abortさいごに
gitの知識と失敗の経験が身についてきたら心配性も緩和されていくと思うので、要勉強です
失敗するたびに更新して行きたいですね
自分の心配性が極端なのは自覚してますが、一息ついて確認するのも大事だと思いますよ。。。お気持ち
sourcetreeとかgitkrakenとかのgitクライアントを使えばレポジトリの状況が見えやすくなるから心配性も緩和されることに最近気づきました。。。
- 投稿日:2019-10-08T11:50:20+09:00
[Git] 月ごとのコミット数を出力する
- 投稿日:2019-10-08T11:22:21+09:00
git メモ
- 投稿日:2019-10-08T10:53:36+09:00
githubのssh認証が一生うまくいかない話@win10
2019.10.07
講義で必要があっていままで避けていたssh認証でgithubの認証をすることにしたけど滅茶苦茶苦労したのでここにその経緯を書いておこうと思う.
(結局は色んなサイトのまとめになってしまうとは思うけど)
かなり時間がかかったため,記憶と履歴を掘り返しながら書いている.
多少の記憶違いは悪しからず.発生した条件
- windows10
- openssh ver7.7
はじめにやったこと.
- 鍵をつくる
- 公開鍵をコピーする
- githubに登録する
- configを作成しなおす
基本的なwindowsでの認証鍵の作り方はここを参考に
お前らのSSH Keysの作り方は間違っている
あとここも詳しかった
GitHubでssh接続する手順1つ目の壁 ~public key登録してるんやが~
で,.sshフォルダにid_rsaとid_rsa.pubを作成し,githubで鍵を登録した.
できたぞ!!とgit clone を実行しようとしたCloning into 'AAA AAA'... Warning: Permanently added the RSA host key for IP address 'xxx.xxx.xxx.xxx' to the list of known hosts. 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.あかんかった.
取り敢えずopenssh publickey permission deniedとかで調べているとこの辺が出てくるのでトライしたけど全部結果は変わらなかった
この時調べて出てきたのはこの辺り
- Gitで”Permission denied (publickey).” が出たときのメモ
- git cloneしようとした時でたエラーと戦った話
- 【git エラー解決策】Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. が出た時の解決方法
まあ当たり前だけどよく確認しましょうって話よね.
んで最後にだいたいを実行して接続確認をする.>>> ssh -T git@github.com Hi xxxxxxxxx! You've successfully authenticated, but GitHub does not provide shell access.こいつはうまくいっていた.
けどやっぱりcloneしようとすると失敗する.更に調べていくと次のワードにぶつかった.
ssh-add, ssh-agent
ソース
新しい SSH キーを生成して ssh-agent に追加するssh-agentにkeyを登録しなければならないらしい
よーし光が見えてきたぞ,と実行に移す.2つめの壁 ~ssh-agentってなんやねん~
そもそもssh-agentないですよって言われた.
なかなか解説が見当たらなくて苦労したけど,そこもひっくるめて簡単に言えば
OpenSSHのバージョンが低かったらしい.
(後から思えば,本当にここが悪かったのかなあ?)
とにかく,ssh-agentとssh-addを使うことができなかった.
状態は
- ssh -T git@github.comは返ってくる.
- sshを用いたgit cloneはpermission denied(public key)のまま
以下のコマンドでssh接続のデバッグ表示もすることができる.
>>> ssh -Tv git@github.comこのデバッグの時に表示されたアラートが,バージョンアップしたら消えたので,OpenSSHの7.7より8.0のがRSAの鍵の強度が高いらしい.
使ってたOpenSSHのバージョン
OpenSSH 7.7p1入れ直したOpenSSHのバージョン
OpenSSH 8.0p1
OpenSSH DL元インストールに有用だった参考サイト
Windows Server 2019 および Windows 10 用 OpenSSH のインストール
Windows10にssh-agentをインストールこの辺りからWindowsPowerShellを使って作業し始めた.
やっていることは,
パッケージダウンロード→path設定→powershellでインストールと起動
の流れ.
ここのクライアント側の作業も参考にした
WindowsにOpenSSHをインストールするバージョンアップして,git_bashを立ち上げ,最後にやったことは以下
ssh-keygen -t rsa -b 4096 -C "your_email@example.com" ssh-agent -s ssh-add ~/.ssh/id_rsaサイトによっては,二行目をeval $(ssh-agent -s)にすると書いてあるが,win10の場合evalのカッコ内だけ入力すれば大丈夫.
雑多な情報を集めた記事になってしまった.許してほしい....|:3ミ
まとめ
- win10でssh認証をしたい場合
- ssh-keygenで鍵をつくる
- ssh-agentを起動する
- ssh-addに認識させる
- githubに鍵を登録する
という作業が必要.
場合によっては,ssh-addやssh-agentがない場合があるので,その場合は適宜インストール作業する必要がある.追記
この状態では,端末を閉じるとまたエラーが出るので,
現在,gitbashを起動し,eval `ssh-agent -s` ssh-add ~/.ssh/id_rsaをやり直している.
(今度直そう…)
- 投稿日:2019-10-08T09:54:38+09:00
gitignore_grobalを使おう 他
gitignore_grobalを使おう
参考:
https://qiita.com/elzup/items/4c92a2abdab56db3fb4e.gitigonoreはプロジェクトで共有すべきものなので
個人的なもの、環境的なものは書くべきでない。ブランチ移動したときに漏れたりもするので、
別に分けて書いておいたほうがいい。git addする時、git statusするときにも聞いてくるので
参考その2:
https://github.com/github/gitignoreここに一般的に.gitignore対象になるものが
まとめてあるgit addしたあとやり直す時
git reset ファイル名
でステージング解除できるので
基本その後編集して、ステージングをやり直す。git addは基本、commit直前に
個人的に、git addはcommitする直前にやろう。
commit前の目視確認も、git diff
でやりやすいし、dotfilesを導入
ドットファイル増えたし、
これを機に入れてみました。参考:
https://qiita.com/okamos/items/7f5461814e8ed8916870kugyu10のdotfiles:
https://github.com/kugyu10/dotfiles
- 投稿日:2019-10-08T04:20:08+09:00
ベアリポジトリにプッシュすると勝手にデプロイされる仕組み
何番煎じかわからないけれど…
すぐ試せるように手順だけ書きます。
概要
- bareRepo.git
- 中央リポジトリ
- 差分情報だけ、ファイルはない
- publishedRepo
- デプロイ先ディレクトリ
- 直接さわらない
- localRepo
- 作業用ディレクトリ
- ここで作業して中央リポジトリにプッシュする
手順
$ mkdir ~/testdir $ cd ~/testdir $ git init --bare --shared bareRepo.git $ touch bareRepo.git/hooks/post-receive $ chmod +x bareRepo.git/hooks/post-receive $ vim bareRepo.git/hooks/post-receive以下の内容を記述します。
bareRepo.git/hooks/post-receive#!/usr/bin/env bash cd ~/testdir/publishedRepo git --git-dir=.git pull$ git clone bareRepo.git publishedRepo $ git clone bareRepo.git localRepo $ cd localRepo $ echo Hello, world! > README.md $ git add README.md $ git commit -m "Initial commit" $ git push origin master $ cd ../publishedRepo $ cat README.mdpublishedRepoでは直接作業していませんが、Hello, world!と表示されます。