HOGEを検索かけたいんだけど、HOGETIONは明らかに違う単語だから除外したいって時ありますよね

できなかったこと

git grep -e HOGE --and -v HOGETION

--andは-eと一緒じゃないと使えないらしい

解決方法

git grep -e HOGE --and --not -e HOGETION

---

ちょっと詰まった

会社でGitlab CIはいじっていたのだが、Circle CIに初めて手をつけてみた。

で、基本のサンプルなど読みながら勉強していたのだが、
タギングとパッケージ公開それぞれのサンプルは多々あったものの
タギングとパッケージ公開を一緒に行っている簡単なサンプルが見つからなかったので落ち着いた方法を載せておく。
調べ方が悪かっただけな気もする。

やりたいこと

• github上にあるnpmプロジェクトをCircleCIでCIしたい
• masterにマージされたときだけタギングしたい
• タギングされたらnpmにパッケージを公開したい

方法1: タギングとパッケージ公開を一連で行う。

一番素直に書くとこうなる。シンプルでわかりやすい。

• タギングしたときにワークフローが無限ループしてしまうのを防ぐのに、 npm versionするときのメッセージに[ci skip]を入れてやる。
• ${github_email}と${npm_token}は環境変数から渡してやる。

必ずpatchリリースになってしまう点に目を瞑ればこの方法が一番シンプル。

.circleci/config.yml

version: 2.1

executors:
  default:
    docker:
      - image: circleci/node:10.15

commands:
  restore_modules:
    steps:
      - restore_cache:
          keys:
            - v1-npm-deps-{{ checksum "package-lock.json" }}
            - v1-npm-deps-
  save_modules:
    steps:
      - save_cache:
          key: v1-npm-deps-{{ checksum "package-lock.json" }}
          paths:
            - node_modules

jobs:
  setup:
    executor: default
    steps:
      - checkout
      - restore_modules
      - run: npm install
      - save_modules
  test:
    executor: default
    steps:
      - checkout
      - restore_modules
      - run:
          name: Test
          command: npm test
      - store_artifacts:
          path: coverage
  tag_and_publish:
    executor: default
    steps:
      - checkout
      - restore_modules
      - run:
          name: Push a new tag
          command: |
            git config --global user.name  "EnKen"
            git config --global user.email "${github_email}"
            npm version patch -m "v%s tagged [ci skip]"
            git push --tags origin master
      - run:
          name: Publish to npm
          command: |
            echo "//registry.npmjs.org/:_authToken=${npm_token}" > ~/project/.npmrc
            npm publish

workflows:
  main:
    jobs:
      - setup
      - test:
          requires:
            - setup
      - tag_and_publish:
          requires:
            - test
          filters:
            branches:
              only: master #masterブランチでだけ実行

方法2: タギングとパッケージ公開を別々のワークフローで行う。

基本的なやることは変わらないが、
「masterにマージ -> テスト -> タギング」までを一連のワークフローで実施し、
パッケージ公開はタギングをトリガーに別のワークフローで実施する方法。

.circleci/config.yml

version: 2.1

executors:
  default:
    docker:
      - image: circleci/node:10.15

commands:
  restore_modules:
    steps:
      - restore_cache:
          keys:
            - v1-npm-deps-{{ checksum "package-lock.json" }}
            - v1-npm-deps-
  save_modules:
    steps:
      - save_cache:
          key: v1-npm-deps-{{ checksum "package-lock.json" }}
          paths:
            - node_modules

jobs:
  setup:
    executor: default
    steps:
      - checkout
      - restore_modules
      - run: npm install
      - save_modules
  test:
    executor: default
    steps:
      - checkout
      - restore_modules
      - run:
          name: Test
          command: npm test
      - store_artifacts:
          path: coverage
  push_tag:
    executor: default
    steps:
      - checkout
      - restore_modules
      - run:
          name: Push a new tag
          command: |
            git config --global user.name  "EnKen"
            git config --global user.email "${github_email}"
            npm version patch -m "v%s tagged [ci skip]"
            git push --tags origin master
  publish_package:
    executor: default
    steps:
      - checkout
      - restore_modules
      - run:
          name: Publish to npm
          command: |
            echo "//registry.npmjs.org/:_authToken=${npm_token}" > ~/project/.npmrc
            npm publish

workflows:
  main:
    jobs:
      - setup
      - test:
          requires:
            - setup
      - push_tag:
          requires:
            - test
          filters:
            branches:
              only: master
  publish:
    jobs:
      - setup:
          filters:
            tags:
              only: /^v.*/
            branches:
              ignore: /.*/
      - publish_package:
          requires:
            - setup
          filters:
            tags:
              only: /^v.*/
            branches:
              ignore: /.*/

• publishのワークフローではfilters記述でbranchesのトリガーをすべて無視し、 tags(vで始まるやつだけ)のトリガーでのみ動作するように記述する。
• publish_packageのジョブだけでなくsetupのジョブにも同じtagsの記述が条件を記述しないとトリガーが作動してくれない点に注意。

若干面倒くさいが、この方法であればminorやmajorバージョンを上げたい場合、
ローカルで手動タギングする運用が可能である。

npm version minor -m "%s tagged [ci skip]"

という感じで[skip ci]をメッセージに入れてバージョンを上げれば、
pushした際にmainのワークフローを実行せず、publishだけ行うことができる。

結論

ということで、今回はパッケージ公開の柔軟さから方法２の方法を選択した。
ワークフローがループする問題の対処法が[ci skip]しか思いつかなかったのだが、
もうちょっとスマートな方法あったりするんだろうか。

会社でGitlab CIはいじっていたのだが、Circle CIに初めて手をつけてみた。

で、基本のサンプルなど読みながら勉強していたのだが、
タギングとパッケージ公開それぞれのサンプルは多々あったものの、
タギングとパッケージ公開を一緒に行っている簡単なサンプルが見つからなかったので落ち着いた方法を載せておく。
調べ方が悪かっただけな気もする。

やりたいこと

• github上にあるnpmプロジェクトをCircleCIでCIしたい
• masterにマージされたときだけタギングしたい
• タギングされたらnpmにパッケージを公開したい

方法1: タギングとパッケージ公開を一連で行う。

一番素直に書くとこうなる。シンプルでわかりやすい。

• タギングしたときにワークフローが無限ループしてしまうのを防ぐのに、 npm versionするときのメッセージに[ci skip]を入れてやる。
• ${github_email}と${npm_token}は環境変数から渡してやる。

必ずpatchリリースになってしまう点に目を瞑ればこの方法が一番シンプル。

.circleci/config.yml

version: 2.1

executors:
  default:
    docker:
      - image: circleci/node:10.15

commands:
  restore_modules:
    steps:
      - restore_cache:
          keys:
            - v1-npm-deps-{{ checksum "package-lock.json" }}
            - v1-npm-deps-
  save_modules:
    steps:
      - save_cache:
          key: v1-npm-deps-{{ checksum "package-lock.json" }}
          paths:
            - node_modules

jobs:
  setup:
    executor: default
    steps:
      - checkout
      - restore_modules
      - run: npm install
      - save_modules
  test:
    executor: default
    steps:
      - checkout
      - restore_modules
      - run:
          name: Test
          command: npm test
      - store_artifacts:
          path: coverage
  tag_and_publish:
    executor: default
    steps:
      - checkout
      - restore_modules
      - run:
          name: Push a new tag
          command: |
            git config --global user.name  "EnKen"
            git config --global user.email "${github_email}"
            npm version patch -m "v%s tagged [ci skip]"
            git push --tags origin master
      - run:
          name: Publish to npm
          command: |
            echo "//registry.npmjs.org/:_authToken=${npm_token}" > ~/project/.npmrc
            npm publish

workflows:
  main:
    jobs:
      - setup
      - test:
          requires:
            - setup
      - tag_and_publish:
          requires:
            - test
          filters:
            branches:
              only: master #masterブランチでだけ実行

方法2: タギングとパッケージ公開を別々のワークフローで行う。

基本的なやることは変わらないが、
「masterにマージ -> テスト -> タギング」までを一連のワークフローで実施し、
パッケージ公開はタギングをトリガーに別のワークフローで実施する方法。

.circleci/config.yml

version: 2.1

executors:
  default:
    docker:
      - image: circleci/node:10.15

commands:
  restore_modules:
    steps:
      - restore_cache:
          keys:
            - v1-npm-deps-{{ checksum "package-lock.json" }}
            - v1-npm-deps-
  save_modules:
    steps:
      - save_cache:
          key: v1-npm-deps-{{ checksum "package-lock.json" }}
          paths:
            - node_modules

jobs:
  setup:
    executor: default
    steps:
      - checkout
      - restore_modules
      - run: npm install
      - save_modules
  test:
    executor: default
    steps:
      - checkout
      - restore_modules
      - run:
          name: Test
          command: npm test
      - store_artifacts:
          path: coverage
  push_tag:
    executor: default
    steps:
      - checkout
      - restore_modules
      - run:
          name: Push a new tag
          command: |
            git config --global user.name  "EnKen"
            git config --global user.email "${github_email}"
            npm version patch -m "v%s tagged [ci skip]"
            git push --tags origin master
  publish_package:
    executor: default
    steps:
      - checkout
      - restore_modules
      - run:
          name: Publish to npm
          command: |
            echo "//registry.npmjs.org/:_authToken=${npm_token}" > ~/project/.npmrc
            npm publish

workflows:
  main:
    jobs:
      - setup
      - test:
          requires:
            - setup
      - push_tag:
          requires:
            - test
          filters:
            branches:
              only: master
  publish:
    jobs:
      - setup:
          filters:
            tags:
              only: /^v.*/
            branches:
              ignore: /.*/
      - publish_package:
          requires:
            - setup
          filters:
            tags:
              only: /^v.*/
            branches:
              ignore: /.*/

• publishのワークフローではfilters記述でbranchesのトリガーをすべて無視し、 tags(vで始まるやつだけ)のトリガーでのみ動作するように記述する。
• publish_packageのジョブだけでなくsetupのジョブにも同じtagsの記述が条件を記述しないとトリガーが作動してくれない点に注意。

若干面倒くさいが、この方法であればminorやmajorバージョンを上げたい場合、
ローカルで手動タギングする運用が可能である。

npm version minor -m "%s tagged [ci skip]"

という感じで[skip ci]をメッセージに入れてバージョンを上げれば、
pushした際にmainのワークフローを実行せず、publishだけ行うことができる。

結論

ということで、今回はパッケージ公開の柔軟さから方法２の方法を選択した。
ワークフローがループする問題の対処法が[ci skip]しか思いつかなかったのだが、
もうちょっとスマートな方法あったりするんだろうか。

経緯
gitの変更点の削除を行う際にCan't find Huskyエラーでgit checkout .できないの一環としてプロジェクトにある .git/hooksというディレクトリを削除したが、Git hooksってなんだかは詳しく分かっていなかった為、今回少しだけ掘り下げてみることにしました。

Git Hooksとは

チーム開発時にバージョン管理のルールを決めていても意図関係なくルールを破ってしまったという事態を防ぐために、予めGitコマンドなどのアクションを走らせる前と後にちゃんとルールを守れているかを監視する機能

Hook自体はクライアントサイドとサーバーサイドの２種類がある

クライアントサイド
コミットやマージなどクライアント側で操作するやつ

サーバーサイド
プッシュされたコミットを受け取るなどの操作

デフォルトのスクリプトは以下の階層に用意されている
.git/hooks

$ ls .git/hooks
applypatch-msg.sample           post-update.sample              pre-commit.sample               pre-rebase.sample               update.sample
commit-msg.sample               pre-applypatch.sample           pre-push.sample                 prepare-commit-msg.sample

デフォルトスクリプトの紹介

pre-commit

コミットメッセージが入力される前に実行される。

prepare-commit-msg

コミットメッセージエディターが起動する前に実行される。

commit-msg

コミットメッセージエディター起動時に実行される。

pre-push

pushを実行する前にクライアントで実行される。

pre-receive

pushを受信したらサーバーサイドで実行される。

post-receive

pushが完了したらサーバーサイドで一度だけ実行される。

はじめに

未来電子テクノロジー
でインターンをしています、Sotaです。
プログラミング初心者であるため、内容に誤りがあるかもしれません。
もし、誤りがあれば修正するのでどんどん指摘してください。
この記事は、gitを使う上で重要なコミットのツリーを確認する方法を書いていきます。

git log

git log コマンドを使うことで今までのコミットを見ることができます。

✗ git log 

commit ed29ec593f8f2283e429861e4acd0565493c0acb
Author: shikanoko0-0 <fragrantolive0.0k@gmail.com>
Date:   Tue May 21 18:02:39 2019 +0900

    my name

commit 9af5aa66ec167ed54e9a4ebf27c3dcd6da4dce87
Author: reporobot <60ebe73fdad8ee59d45c@cloudmailin.net>
Date:   Mon May 20 23:40:27 2019 -0400

    Rebuilt index with carolinewangz

しかしこのままでは、コミットツリーがどのような構造になっているか、理解が非常に難しいです。
そこで、git log　にオプション --graph をつけます。

✗ git log --graph

* commit 9438ab11e429db88588209fac2db4f74f9f14a04
| Author: reporobot <60ebe73fdad8ee59d45c@cloudmailin.net>
| Date:   Tue May 21 05:09:16 2019 -0400
| 
|     Rebuilt index with shikanoko0-0
|    
*   commit 28d5786f3372bfc6a63edd9f8c85870bbbdcc937
|\  Merge: 9af5aa6 ed29ec5
| | Author: RepoRobot <reporobot@users.noreply.github.com>
| | Date:   Tue May 21 05:09:14 2019 -0400
| | 
| |     Merge pull request #29338 from shikanoko0-0/add-shikanoko0-0
| |     
| |     Merging PR from @shikanoko0-0
| |   
| * commit ed29ec593f8f2283e429861e4acd0565493c0acb
|/  Author: shikanoko0-0 <fragrantolive0.0k@gmail.com>
|   Date:   Tue May 21 18:02:39 2019 +0900
|   
|       my name
|  

とこのようにコミットツリーが表示され、非常に理解しやすくなります。
終了したいときは q をタイプすれば、終了できます。
その他のツリーを見やすくするオプションを紹介します。
--oneline
　一行表示
--decorate=(short|full|no)
　ブランチ名の表示形式
--date=(relative|local|default|iso|rfc|short|raw)
　日付表示

まとめ

git log --graph を使うことでコミットツリーを簡単に確認できます。
自分はよく使うので、aliasでlgraphコマンドとして設定を作りました。

 git config --global alias.lgraph 'log --graph --oneline --decorate=short --date=short'

rebaseの手順

git checkout [branch]
git rebase master

最新のbranchにPullした後、作業中のbranchにCheckoutします。
その後、master branchにrebaseします。
問題がないと、rebaseできます。
でも、人生は甘くないので、conflictや色んなエラーメッセージが出ます。

conflictが発生する時、解決方法

git status         　　　    //conflictされたファイルを確認

git add [修正したファイル]    //修正したファイルをaddする
git rebase --continue       //もう一度、rebaseする

git status         　　　   //conflictされたファイルを確認
git push                   //問題がないとpushする

こんな流れで、conflictされたファイルを修正しながら、rebaseします。
ファイルを修正して、問題がないとpushします。

pushしてエラーが発生した時、解決方法

git push
! [rejected]          branch -> branch (non-fast-forward)

問題がないはずなのに[non-fast-forward]という理由でrejecteされました。
そういう時は、強制Pushをすると解決できます。

git push -f [branch]

なぜ、強制Pushをしますか？

master   C0--C1--C2--C3--C6--C4(1)--C5(1)   
                      \  
branch                 C4--C5

簡単に言うと、普通の状態なら、作業branchとmaster branchの共通コミットとmaster branchのコミットまで全部コピーするので、エラーが出ます。

状況

• git clone git@github.com:username/repo_name.gitをしようとしたら以下のエラーが出る。

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.

• リポジトリは絶対にある。
• 公開鍵も登録した。
• なぜ...

解決策

こちらのサイトに助けていただきました。

• Githubに接続できない時の対処法

SSHで接続する際にデフォルトで読みにいく秘密鍵のパスは「~/.ssh/id_rsa」「~/.ssh/id_dsa」「~/.ssh/identity」のいずれかです。それ以外のパスで置いても読み込まれません。

公開鍵に名前を付けていたので、鍵を読みに行ってくれていなかったということでした。.ssh/configのファイルを作成して以下をファイル内に記述。

Host github github.com
  HostName github.com
  IdentityFile ~/.ssh/#秘密鍵のファイル名
  User git
  Port 22

これでいけるか...!

ssh接続テストをしてみた。
ssh -T git@github.com

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for '秘密鍵のpath' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "秘密鍵のpath": bad permissions
git@github.com: Permission denied (publickey).

残念。
秘密鍵のパーミッションがヤバイとのことなので、ファイルのプロパティーから変更。(書き込みをできないようにした)

これで接続成功しました。
ちなみにコマンドラインからパーミッションを変更したい場合、windowsだとchmodがなくてicaclsというコマンドらしい。