20191008のGitに関する記事は11件です。

Railsチュートリアル 第3章<復習>

第3章の復習メモです。
個人的に重要と思ったことを書きます。
調べたことや、知っていたことも含めて書きます。

Webページの作成

Railsで、Webページ作成に最低必要なのは、以下の3つ。

  1. URLのルーティング
  2. 1に対応するコントローラ及び、アクションの作成
  3. 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章以降についても、できれば続けていきたいと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

空のディレクトリをgithubに上げる

何がしたかったか

結果を保存するディレクトリを空の状態でgithubに上げたかった

gitは空のディレクトリを管理できない

解決法

空のディレクトリに.gitkeepを追加する

touch path_to_dir/.gitkeep
git add path_to_dir/.gitkeep
git commit
git push remote master
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

gitでcloneときに使用するSSHキーを指定する方法

結論

一発

$ ssh-agent $(ssh-add 秘密鍵のパス; git clone リモートリポジトリ)

参照

How to specify the private SSH-key to use when executing shell command on Git?

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

指定した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.
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

EGitが使いやすすぎた

EGit

EclipseからGitを使うやつです

これが地味に楽で便利なんですわ

できること一覧

eclipseでgitのパースペクティブを開きましょう

できること一覧


  • リポジトリをクローン
  • クローンしたプロジェクトをプロジェクトエクスプローラから編集していく
  • ローカルでブランチを作成
  • ステージング
  • ブランチのヒストリーを見る
  • コミット及びプッシュ
  • ヒストリーからコミットを複数選択してスカッシュ
  • リベース
  • 強制プッシュ(変更の強制)
  • 差分を確認
  • 競合解消

...全部じゃん

別でTortoiseGitとかGitBashとか使わんでも困らんくらいいろいろできますね

しかもGUIなんで見やすい。

GitBashに慣れてる自分的には快適です!

前に書いたGitBash基本コマンド一覧

Gitについて地味に不安を抱えている人が多い雰囲気を感じたら、こういったできること一覧だけでなく
それぞれの操作がどういう意味なのか
なにができるのか
いつ使えばいいのか
どういう利点と欠点があるのか

とかまとめてみたいなって思ってます!

今回はEGitスゲー回でした

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

心配性が始めるgit管理(確認/修正をするgitコマンド集)

2019/10/09追記

- 頂いたコメントから コミットそのものをミスった -> コミット取り消しに追記
- 同項に注意事項を追記

はじめに

今年の3月に大学を卒業し、4月からアプリを作る会社に入社した者です。
iOSアプリを作るエンジニアしてます。Androidアプリも勉強してます。

超心配性です。

仕事で当然Gitを使う訳ですが、、、これが新米エンジニアには難しい。
入社直後、.gitignoreの設定をミスってしまい、FilesChangedが7000を超えるトンデモPRを生み出したことがあります。(その後.gitignoreの設定を直したら、今度はなぜか.xcodeprojファイルがぶっ壊れて...と修正に丸々1日潰しました :innocent: )

それ以来、超超心配性な性格も相まって
「.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ブランチにもその変更を反映したいとき
スクリーンショット 2019-10-08 11.39.10.png

「あれ?featureブランチでmerge叩けばいいんだっけ? :thinking:
ミスっても 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つだけreset
  • HEAD~~~またはHEAD^^^(n個~や^をつける)またはHEAD@{n}またはHEAD~n コミットn個reset
    ~^にも一応違いがあるようですが、resetする分にはほとんど違いがないはずです。。。 https://qiita.com/chihiro/items/d551c14cb9764454e0b9

(2019/10/09追記、コメントありがとうございます :bow: :bow: )
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の知識と失敗の経験が身についてきたら心配性も緩和されていくと思うので、要勉強です
失敗するたびに更新して行きたいですね :innocent:
自分の心配性が極端なのは自覚してますが、一息ついて確認するのも大事だと思いますよ。。。

お気持ち

sourcetreeとかgitkrakenとかのgitクライアントを使えばレポジトリの状況が見えやすくなるから心配性も緩和されることに最近気づきました。。。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[Git] 月ごとのコミット数を出力する

月ごとのコミット数を調べるときに使えます。

CI導入前のコスト算出に使いました。

リポジトリのディレクトリで下記を実行します。

month=("01" "02" "03" "04" "05" "06" "07" "08" "09" "10" "11" "12")
for m in "${month[@]}"
do
  echo "2019-$m\t"$(git log --date=iso --pretty=format:"[%ad] %h %an : %s" | grep 2019-"$m" | wc -l)
done

2重ループにすれば複数年でもチェックできそうです。

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

git メモ

cmd

コマンド 内容
clone リモートリポジトリをマウント
remote -v リモートリポジトリ確認
branch ブランチ作成
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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とかで調べているとこの辺が出てくるのでトライしたけど全部結果は変わらなかった
この時調べて出てきたのはこの辺り

まあ当たり前だけどよく確認しましょうって話よね.
んで最後にだいたいを実行して接続確認をする.

>>> 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

をやり直している.
(今度直そう…)

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

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/7f5461814e8ed8916870

kugyu10のdotfiles:
https://github.com/kugyu10/dotfiles

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ベアリポジトリにプッシュすると勝手にデプロイされる仕組み

何番煎じかわからないけれど…

すぐ試せるように手順だけ書きます。

概要

  • 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.md

publishedRepoでは直接作業していませんが、Hello, world!と表示されます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む