Git 作業別まとめ

更新

ブランチを切って、リモートブランチ作成

// リモートリポジトリーの確認
$ git remote -v

// 新しくブランチを作成
$ git branch [ブランチ名]

// 作ったブランチにチェックアウト
$ git checkout [ブランチ名]

// 手元のリポジトリをリモートリポジトリにプッシュ
$ git push [リモートリポジトリの名前] [ブランチの名前]

// ブランチの追跡設定
$ git branch --set-upstream-to=[リモートリポジトリの名前]/[追跡したいリモートブランチ] [手元のブランチ]

ブランチを切って、リモートブランチ作成(ショートVer.)

// ブランチを切ってそこにチェックアウト
$ git checkout -b [ブランチ名]

// 手元のリポジトリをリモートリポジトリにプッシュ(追跡設定つき)
$ git push -u [リモートリポジトリの名前] [ブランチの名前]

コミットからプッシュまで

// 編集したファイルのステージング
$ git add .

// メッセージつきコミット
$ git commit -m 'コミットメッセージ'

// リモートリポジトリにプッシュ
$ git push

マージからリポジトリの削除(GitHUB Flow)

// masterにチェックアウト
$ git checkout master

// マージ
$ git merge --no-ff [ブランチ名]

// マージした内容をリモートリポジトリにプッシュ
$ git push

// 作業の終了したブランチを削除
$ git branch -d [ブランチ名]

設定

クローン

// リポジトリをクローンしたいディレクトリに移動して
$ git clone [複製元]

VS Code Formatter

VS Codeのデフォルトでは、HTML JSのフォーマッターは、入っているようです。
その他の言語には、各言語に対応したフォーマッターを追加してあげないといけません。

以下に追加したフォーマッターをメモとして、残しておきます。

適宜、追記します。

Nuxt.js 12.3から、コンポーネントのインポート不要

Nuxt.jsの勉強の為に create-nuxt-app して、index.vue を見てみたら、import せずに logo.vue が呼び出されていたので、不思議に思い調べて見たところ、Nuxt.js 2.13からコンポーネントをインポートしなくても勝手に /components から探してきてくれる仕様になってるとのことでした。

https://nuxtjs.org/api/configuration-components

この設定は、nuxt.config.js の components を true にするだけです。

VS Codeの使い方メモ

Autoprefixer

VS CodeのAutoSaveをafterDelayで使用する場合、AutoprefixerのFormat On Saveにすると保存される度にカーソルが末尾に移動してしまい不便なので、Autoprefixerは、手動でコマンドパレット(shift + command + P)から使います。
SassのコンパイラーをEasy Sassではなく、Autoprefix機能のあるLive Sass Compileにするのも手かもしれません。

Work Space

VS CodeのWork Spaceには、編集するDirを直接設定する。複数ある場合、個々のDirを指定する。

EassySassの出力先

親のDirを指定するとEassySassの出力先が指定のパスと合わないのでエラーになってしまう。

EasySass出力先:sass/css(workspaceに指定されたDir/sass/cssに出力)

パネルの出し方

command + J

VS CodeでMarkdownのプレビュー

サイドバイサイドにプレビューを表示

[Command]+[K]→[V]

同一エディタに別タブとしてプレビューを表示

[Shift]+[Command]+[V]

エンコーディングを指定して表示する

開いたファイルで文字化けが発生していたら、画面下部にあるステータスバー右側にエンコーディング情報が表示されているので、クリックする。
画面上部に[アクションの選択]から[エンコード付きで再度開く]をクリック、エンコードを選択して再度開く。

随時追記

VS Code プラグイン markdownlintで、同じ名前の見出しをつけると注意される

VS Codeにプラグインmarkdownlintを入れました。
同じ見出しをつけるとこのルールにより注意を受けてしまいます。

でも、複数の親見出しの中に同じ名前の子見出しをつけたいこともあると思います。
こんな場合。

# 果物
    ## みかん
        ### 色
        ### 個数
    ## りんご
        ### 色
        ### 個数

このケースですと、色と個数に警告が出ます。
同じ名前を付けられない訳ではないのですが、警告の対象になって、気持ちが悪いです。

この警告を回避するためには、VS Codeのsetting.jsonに以下を設定します。

"markdownlint.config": {
    "MD024": {
        "siblings_only": true
    }
}

WordPress:REST API with Smart Custom Field

REST API

以前は、プラグインが必要だったREST APIですが、現行のWordPress5のcoreには、初めからREST APIが入っているようです。
今回、繰り替えしのフィールドが必要だったため、カスタムフィールドを登録するプラグインはSmart Custom Fieldを使用します。

カスタム投稿タイプとカスタムフィールドをREST APIに出力

カスタム投稿タイプをREST APIに出力するには、カスタム投稿タイプ作成時にREST APIに出力する設定が必要です。

function create_post_type() {
  $supports = [ 
    'title', // title
    'editor', // editor
  ];
  register_post_type( 'fruits', // 例:果物の場合
    array(
      'label' => '果物',
      'public' => true,
      'has_archive' => false,
      'menu_position' => 7,
      'supports' => $supports,
      'show_in_rest' => true, //rest api での取得有効にする
      'rest_base' => 'fruits' // rest api での取得名  /wp-json/wp/v2/fruits
    )
  );
}
add_action( 'init', 'create_post_type' );

REST APIの結果を確認してみましょう。

https://your-domain.com/wp-json/wp/v2/fruits

次にSmart Custom Fieldの値をREST APIに出力する設定を行います。
仮にSmart Custom Fieldに設定した名前が以下とします。

fruits_color テキストが入ります。
fruits_image idが入ります。

functions.phpに以下のコードを入力します。

// rest apiにカスタムフィールドを出力
add_action( 'rest_api_init', 'slug_register_fruits' );
function slug_register_fruits() {
  register_rest_field( 
    'fruits',   //フィールドを追加したいcustom投稿タイプを指定(先ほど登録したカスタム投稿タイプslugを指定)
    'fruits_meta',  // rest-apiに追加するキー
    array(
      'get_callback' => function( $object, $field_name, $request ) {
        // 出力したいカスタムフィールドのキーをここで定義
        $meta_fields = array(
          'fruits_color',
          'fruits_image',
        );
        $meta = array();
        foreach ( $meta_fields as $field ) {
          // バリデーションを一切してないので注意
          $meta[ $field ] = get_post_meta( $object['id'], $field, false ); // 第3引数はfalse、Smart Custom Fieldの繰り替えし機能を使うため
        }
        return $meta;
      },
      'update_callback' => null,
      'schema'          => null,
    )
  );
}

ここで注意して欲しいのが17行目のget_post_meta関数の第3引数です。
Smart Custom Fieldの繰り返しの機能を利用すると、繰り返されたグループの値は、カスタムフィールドに配列で格納されます。
そのため、第3引数にfalseを渡して、値を配列として受け取ります。
第3引数がtrueだと、繰り返されたグループの値が取得できません。

REST APIの出力結果を確認してみましょう。
カスタムフィールドの値が出力されているのが確認できると思います。

https://your-domain.com/wp-json/wp/v2/fruits

参考

wordpress rest-apiでカスタムフィールドを出力する際に処理結果を整形したい
https://qiita.com/kinshist/items/cd9f74af7db7c80746a1

React RouterのBrowserRouterがbuildの時、使えない

症状 create-react-appを使って、プロジェクトを作成・開発して、npm startした時は、正しくコンポーネントが描画されるのですが、npm run buildすると何も描画されず、真っ白な画面しか表示され … “React RouterのBrowserRouterがbuildの時、使えない” の続きを読む

症状

create-react-appを使って、プロジェクトを作成・開発して、npm startした時は、正しくコンポーネントが描画されるのですが、npm run buildすると何も描画されず、真っ白な画面しか表示されない現象に出くわしました。
その上、build時にはエラーは出ず、successしてしまうので原因の見当がつかず困りました。

環境

package.jsonのdependenciesは以下の通り。

"history": "^4.9.0",
"react": "^16.8.4",
"react-dom": "^16.8.4",
"react-redux": "^5.0.6",
"react-router-dom": "^5.0.0",
"react-router-hash-link": "^1.2.1",
"react-router-redux": "^5.0.0-alpha.9",
"react-scripts": "^2.1.8",
"redux": "^4.0.1",
"redux-logger": "^3.0.6",
"redux-thunk": "^2.3.0"

原因

ページの遷移にReact Routerを使っていたのですが、React Router V4からbuildする時には、BrowserRouterが使えないようで、これが原因でした。

この情報がなかなか見つけられず、骨が折れました。
解決できたのは、React学習用に買ったReact入門 React・Reduxの導入からサーバサイドレンダリングによるUXの向上まで にあったTipsに「GitHub PageにAppを公開する際は、BrowserHistoryだと動かない」という内容の記事を見つけて、試しにHashRouterに変更してbuildしたら動いたという幸運にめぐまれました。

React入門 にあったTipsをもう少し詳しく説明するとnpm startした時は、サーバが立ち上がり、どのようなURLのリクエストでもindex.htmlを返してくれる機能があるが、GitHub Pageではそのような対応をしてくれないため、Hash Historyを利用して、URLに「#」をつけて、ルートにあるindex.htmlを返すようにするということです。

このせいか、React Routerの仕様もBrowserRouterを使っていると機能しないようになっているのかもしれません。(本当のところは、わかりませんが。)

BrowserRouter使ってbuildしたい

HashRouterを使うとURLに「#」が入ってしまうのが、やっぱり気になります。少しだけ調べたのですが、Next.jsを使ってサーバーサイドレンダリングをする。もしくは、buildをreact scriptではなくwebpackを使ってバンドルしhistoryApiFallback を webpack.config.js に追加する方法があるようですが、まだ試していません。試した時は、また記事にしたいと思います。

参考ページ

Sublime3でReactを書く時のシンタックスハイライト設定

Win: Press Ctrl+Shift+P / Mac: Cmd+Shift+P installと入力、「Package control: Install Package」を選択 Babelと入力、「Babel-Sn … “Sublime3でReactを書く時のシンタックスハイライト設定” の続きを読む

  • Win: Press Ctrl+Shift+P / Mac: Cmd+Shift+P
  • installと入力、「Package control: Install Package」を選択
  • Babelと入力、「Babel-Snippets」を選択
  • Sublimeのメニューから「View > Syntax > Babel > Javascript」を選択

Git学習基礎まとめ

Gitを使った開発に慣れるまでの学習方法にとてもよくまとまっています。 上記記事/便利なサイトや書籍のgitをはじめからていねいにを一巡します。手を動かしながら読み進めるとgitの概要をつかみます。 gitコマンド まと … “Git学習基礎まとめ” の続きを読む

Gitを使った開発に慣れるまでの学習方法にとてもよくまとまっています。

上記記事/便利なサイトや書籍のgitをはじめからていねいにを一巡します。
手を動かしながら読み進めるとgitの概要をつかみます。

gitコマンド まとめ

基本

リッポジトリの作成

$ git init

ステージング

変更したファイルをstageする

$ git add ファイル名

全てのファイルをstageする

$ git add .

初回コミット前の git add を取り消す

$ git rm --cached [ファイル名]

最新のコミットの状態に戻す

$ git reset HEAD [ファイル名]

rm –cacheとresetの違い
https://proengineer.internous.co.jp/content/columnfeature/6969#53

staging areaにある変更内容がコミットメッセージとともにリポジトリに反映

このとき、stage されていたファイルの内容とコミットメッセージは「コミットオブジェクト」としてリポジトリ内に保存される。

コミット

コミットメッセージ付きコミット

$ git commit -m 'コミットメッセージ'

直前のコミットメッセージの修正

$ git commit --amend

変更したファイルを全てコミットする

$ git commit .

直前のコミットを現在stagingした内容で「やりなおし」

git commit --amend

間違ったコミットを取り消す

コミットだけを取り消す(ローカルのワークディレクトリの内容は変更しない)

$ git reset --soft

特定のコミットまで戻す

$ git log //戻す対象のハッシュ値を調べる
commit ************************

$ git reset --hard ハッシュ値
revert

revertは、不要なコミットログを残したまま戻るため、メンバーを混乱させてしまう可能性があります。

git revert [コミットid]

ローカルのワークディレクトリの内容も含め、コミットを取り消す

$ git reset --hard

直前の間違ったコミットを取り消す

$ git reset --soft HEAD^

「HEAD^」は、直前のコミットという意味を表すオプション

ファイルへの変更の取り消し

$ git checkout --

https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E5%9F%BA%E6%9C%AC-%E4%BD%9C%E6%A5%AD%E3%81%AE%E3%82%84%E3%82%8A%E7%9B%B4%E3%81%97#_%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%B8%E3%81%AE%E5%A4%89%E6%9B%B4%E3%81%AE%E5%8F%96%E3%82%8A%E6%B6%88%E3%81%97

ここで理解しておくべきなのが、`git checkout — [file]`は危険なコマンドだ、ということです。 あなたがファイルに加えた変更はすべて消えてしまいます。変更した内容を、別のファイルで上書きしたのと同じことになります。そのファイルが不要であることが確実にわかっているとき以外は、このコマンドを使わないようにしましょう。

ファイルの削除+「ファイルを削除したよ」という情報を stage

$ git rm [ファイル名]

ログの確認

$ git log

qで抜け出す

ファイルの移動とその変更内容をstage

$ git mv [ファイル名] [移動先Dir/ファイル名]

ブランチ

新規ブランチ作成

$ git branch [ブランチ名]

分岐元を指定して新規ブランチを作成

$ git branch [新規ブランチ名] [分岐元ブランチ名]

ブランチを切り替える

$ git checkout [ブランチ名]

ログフォーマット化 (git graphで表示)

$ git config --global alias.graph "log --graph --date-order --all --pretty=format:'%h %Cred%d %Cgreen%ad %Cblue%cn %Creset%s' --date=short"

ブランチを削除

$ git branch -d [ブランチ名]

ブランチの確認

$ git branch

ブランチを切ってそこにチェックアウト

$ git checkout -b [ファイル名]

ブランチを戻りたいコミットに移動

$ git reset --hard [移動先コミットid]

マージ

マージ

$ git merge [ブランチ名]

Fast-foward以外でマージ

$ git merge --no-ff [ブランチ名]

マージしたときに競合が発生した場合には、手動でマージする

  1. ファイルを手動で修正
  2. git add <修正したファイル>として「競合を直したよ」と Git に伝える
  3. 全部直したら git commit でマージコミットを完成させる

今いるブランチが「履歴上のどこから分岐したのか」という過去を改変する

リモートリポジトリに新しいブランチを複製

$ git push [リモートリポジトリの名前] [手元のブランチ]:[リモートに作りたいブランチ]

手元のリポジトリでのブランチの名前とリモートリポジトリのブランチの名前が同一の場合

git push [リモートリポジトリの名前] [ブランチの名前]

リモートのブランチの削除

git push [リモートリポジトリの名前] (ここになにも書いてない):[リモートのブランチ]

fetch してマージ

git pull

分岐元から今までに行ったコミットの変更内容を、新しい分岐元からひとつずつイチから適用しなおしてくれる。

git rebase [ブランチ名]

bare repositoryを作る

作業ディレクトリなしで、リポジトリだけを複製する

git clone --bare [複製元] [複製される先]

作業ディレクトリ付きでリポジトリを複製

$ git clone [複製元] [複製される先]

追跡する ブランチを、ローカルに作成

$ git branch [手元のブランチの名前] [追跡したいリモートブランチの名前]

remote リポジトリを設定

$ git remote add [リモートリポジトリの名前] [リモートリポジトリの場所]

リモートリポジトリに存在するコミットやブランチを手元に持てくる

git fetch [リモートリポジトリの名前]

ブランチの追跡設定

$ git branch --set-upstream-to=[リモートリポジトリの名前]/[追跡したいリモートブランチ] [手元のブランチ]

リモートリポジトリーの確認

方法1
$ git remote -v
方法2
$ git remote show -n origin

git push の取り消し

運用ポリシー

master ブランチにコミットするものは「リリースするもの」だけ、ということにしましょう。開発途中のものをコミットするのは、「development」というブランチにします。そして、作業は development からトピックブランチを切って行います。

言い方を変えると、なにか作業をするときには development ブランチから topic ブランチを切って行います。そして、その作業が終わったら、develop ブランチでそのトピックブランチを merge します。これを繰り返して、development ブランチの状態が「リリースできるもの」になったら、master ブランチから development ブランチを merge します。

  • master が指してるコミットは、必ず 「最新のリリース」 である
  • development が指しているコミットは、「最新の開発版」である
  • 各トピックブランチが指しているコミットは、「作業途中の状態」である

すでにリリースしてしまったものに不具合が見つかったときにそれを緊急で修正しなければならないときには、master ブランチから hotfix ブランチを切って、ここで修正した内容を master ブランチに merge すること
そして、この緊急対応が無事にリリースされたなら、hotfix が取り込まれた master ブランチを development にマージすることにしましょう。このように運用することで、開発版にも、リリース版での修正を反映することができます。