- 投稿日：2020-03-18T23:34:40+09:00
Githubでのプログラム修正の流れ その2
はじめに
今回は下記の記事の続きです。
ブランチの作成までやってみようと思います。
Githubでのプログラム修正の流れ その1今回の記事に出てくる言葉
用語 意味 リポジトリ ファイルやディレクトリの
変更履歴を保管しておくものローカルリポジトリ 自分のPC上にあるリポジトリ リモートリポジトリ インターネット上に存在するリポジトリ
GitHubとかbitbucket等コミット ファイルの修正や追加をローカルリポジトリに
変更履歴として記録することプッシュ ファイルの修正や追加をリモートリポジトリに
変更履歴として記録することブランチ 変更履歴の流れを分岐して記録していく物。
masterブランチという大元があり、そこからブランチ（枝）が分かれている、、、というイメージ。修正する機能ごとにブランチを作り、プログラム修正が完了したらmasterブランチに反映する。リモートリポジトリにファイルを反映する
下記の画像の①、②を実行してみましょう。今回はファイルを新規作成したためコメントを「Initial commit」としています。ファイルを修正した場合は、「Fix ~」と書いたり、機能を新規作成した場合は「Add ~」と書いたりします。
上記の手順で作業を行えば、「Publish reposiitory」を押下することで、GitHub(リモートリポジトリ)に新規作成したファイルがアップされます。
集団で開発する際には、リポジトリを公開する必要があるためkeep this codeのチェックは外しておきましょう。
GitHubでの確認
GitHubにアクセスして、リポジトリを確認してみましょう。→GitHub
ページの左側に先ほど反映したリポジトリが表示されていると思います。
新規のプロジェクトを立ち上げる際は、こういった手順でディレクトリ、ファイルをプッシュしましょう。ファイル修正の事前作業
ファイルを修正する際には、事前にブランチを切っておきましょう。今回は適当にブランチ名をつけましたが、実際に開発に携わる場合は「fix 機能名」とか「add 機能名」とかにした方がいいです。
今回はここまで
次回は実装編です。
- 投稿日：2020-03-18T17:30:46+09:00
git checkoutコマンドのbオプションとBオプションの違い
git checkoutコマンド
git checkoutコマンドは皆様何かとお使いかと思います。
自身も新規ブランチのチェックアウト時に、下記のようなコマンドを打つことがあります。
この場合は-bオプションです。
(リモートのfeature/hogehogeブランチを、ローカルのfeature/hogehogeとしてチェックアウト)% git checkout -b feature/hogehoge origin/feature/hogehoge Branch 'feature/hogehoge' set up to track remote branch 'feature/hogehoge' from 'origin'. Switched to a new branch 'feature/hogehoge'ただ、既にローカルに
feature/hogehogeブランチが存在していた場合、% git checkout -b feature/hogehoge origin/feature/hogehoge fatal: A branch named 'feature/hogehoge' already exists.というエラーが発生します。
これはその名の通り、同名のブランチが既に存在しているため発生するエラーですが、
大文字の-Bオプションを使用することで、上記エラーが発生することなく、
強制的にブランチのチェックアウトをすることが出来ます。
(強制的にするので使いどころ誤ると大変ですが・・・)
下記のような感じです。% git checkout -B feature/hogehoge origin/feature/hogehoge Branch 'feature/hogehoge' set up to track remote branch 'feature/hogehoge' from 'origin'. Switched to and reset branch 'feature/hogehoge'シェルスクリプト内で
git checkoutをする必要がある場合等、
強制的にチェックアウトしたい場合は有用かと思います。短いですが以上です。
どなたかの助けになれば幸いです！
- 投稿日：2020-03-18T11:47:28+09:00
Shopifyのテーマをローカル環境で開発する
TL;DR
Shopifyのテーマ開発をローカル環境でやったお話です。
きっかけ
今回初めてShopifyを操作することになり独自テーマを管理画面上で操作するのはデグレや予期せぬバグが出そうで怖い...と感じ、
ちゃんとローカル環境で開発して、Gitでテーマ管理しなきゃだめだなと思ったのがきっかけです。
実際に作ったスターターキットはこちら=>https://github.com/ikuo00uk/shopify-theme-starter概要
今回はShopifyのTheme Kitを使いテーマ開発しました。
theme kitで出来ることはこちら
複数環境へのテーマアップロードができる
高速でテーマのアップロードとダウンロードができる
ローカルファイルをウォッチして変更した差分をShopify環境へ自動アップロードできる
Windows、Linux、macOS で動かすことができる
（参考：https://shopify.github.io/themekit/）高速と書いてありますが、１テーマのアップロード・ダウンロードは数分かかります..つらい
やったこと
まずはテーマキットをダウンロード
brew tap shopify/shopify brew install themekithomebrewを使いますので未インストールの方はインストールしてくださいね
Shopifyの管理画面でプライベートアプリを作る
Shopify管理画面のアプリ管理から「プライベートアプリを管理」を選択して、新規でプライベートアプリを作成してアプリ名、緊急連絡用開発者メールを入力します。
これでプライベートアプリが完成
その後、Admin API権限のTheme templates and theme assetsをRead and writeにしてください。
これがないとテーマの書き込みができないので忘れずに
本番テーマを取得する
プライベートアプリ上のパスワードと、ストアドメインをコマンドライン上からたたきテーマを取得します。
theme get --list -p=[your-password] -s=[you-store.myshopify.com]そうするとテーマ名とテーマIDが取得できますので、以後このテーマIDを使って開発をしていきます。
theme get -p=[your-password] -s=[you-store.myshopify.com] -t=[your-theme-id]
getコマンド、もしくはダウンロードコマンドで指定したテーマをローカルにダウンロードできます。あとはこのファイルを操作して開発していけばOK。
ちなみにテーマをダウンロードすると、config.ymlが取得できるのですが、開発時はこのファイルを見てストアへの反映・変更しているみたいです。config.ymldevelopment: store: "ストア名" password: "パスワード" theme_id: "テーマID"実際に開発、反映
theme open
ローカルで変更したファイルのプレビューを確認できます。
theme watch
ローカルで変更したファイルを監視し、リアルタイムにshopifyの環境にアップロードします。
複数人開発だとなかなか怖いコマンドです。スターターキットの作成
ここまでである程度ローカルで操作して、ファイルをアップロードできることが分かったので、これをgit管理にします。
1.秘匿情報のenv化
まずパスワードやストア情報などの秘匿情報をenv化します。
shopifyのopenコマンドでは変数を引き渡せるのですが、公式情報を見ると、
--vars flag provides a path to a file for loading variables
つまりローカルに.envファイルを作成し秘匿情報は書くようにして、config.ymlはそこを見るように。もちろん.envはgitignoreenv.exampleSTORE_NAME = "ストア名" STORE_PASSWORD = "ストアパスワード" THEME_ID = "開発テーマID" PROD_THEM_ID = "本番テーマID"config.ymldevelopment: store: ${STORE_NAME} password: ${STORE_PASSWORD} theme_id: ${THEME_ID} production: store: ${STORE_NAME} password: ${STORE_PASSWORD} theme_id: ${PROD_THEME_ID}2.npmscript化
毎回テーマコマンドを打つのもめんどくさいので、watchやダウンロードなどコマンドをnpm script化しました。
↓のような感じ
"deploy:dev" : "theme deploy --vars env/.env --env=development",そして完成したのがこちら=>https://github.com/ikuo00uk/shopify-theme-starter
所感
とりあえず土台の土台ができた感じなので、このスターターキットをリッチにしていければ良いなと。。
初めてのShopifyなので、もっとこうしたほうが良い等あれば教えて下さい
- 投稿日：2020-03-18T01:31:27+09:00
挫折しないdotfiles運用
きっかけ
今まで何度かdotfiles運用をおこなったことがあるのですが、理解が中途半端で運用が煩雑でそのたびに挫折してきました。
しかし、下記記事に出会ったことで今までが嘘のように理解することができたので今のうちに記事にしてしまおうと思いました。
少しでもこの記事でdotfiles運用で挫折する人が減るといいなーと思います。
優れた dotfiles を設計して、最速で環境構築する話 - Qiita
最強の dotfiles 駆動開発と GitHub で管理する運用方法 - Qiita対象
dotfiles運用に憧れてるけど、うまくいかない人
私のdotfiles
snyt45/dotfiles
※日々育成中・・・「挫折しない」dotfiles運用
挫折の要因
自分の場合は、以下のようなことがよくありました・・・
ひとつ言えるのは、運用イメージつまり運用の流れが理解できていなかったのは挫折の大きな要因かなと思います。
とりあえずGitHubでドットファイルをホスティングしておいてほしいときに持ってくればいいんでしょ。くらいでした。
これだと運用がうまくいかずに挫折するのは当たり前ですね。dotfilesの運用サイクル
運用でよく行うのは、「インストール(初回のみ)」「アップデート」「デプロイ」の3つになります。
初回のみインストールで.dotfilesを落としてきて、それをホームディレクトリ配下にシンボリックリンクとして展開します。
こうすることで、インストール後即座に設定が有効になります。設定に手を加えたら、変更内容をリモートリポジトリに反映させます。
別のPCで作業をするときは、アップデートでリモートリポジトリから最新の設定内容を~/.dotfilesに反映させます。
次に、デプロイで最新の設定内容を~/配下に反映させます。
dotfiles運用イメージ
運用でよく行う「インストール(初回のみ)」「アップデート」「デプロイ」の3つについては、コマンド化して定型化させることで複雑な運用をシンプルにします。
そして、重要なのがどの環境でも動くことが一番大事になります。コマンドについては次で説明します。
dotfiles運用コマンド
インストールコマンドにはシェルスクリプトを、アップデートとデプロイコマンドはmakeを採用しています。
シェルスクリプトはwindows、Macともbashで実行することを想定します。bashさえあれば、動かすことができるのでプラットフォームの差を無視することができます(あくまでも、windowsのbashはLinuxコマンドに近いwindowsコマンドを実行しているだけなので、シンボリックリンクなど一部コマンドは違う挙動になります。WSLを使えば100%Linux上で動作するので、同じ環境で動かすことができます)。
makeは昔からあるビルドツールで、Macはmakeがデフォルトで入っています。windowsもmakeをインストールさえすれば、すぐに使えるのでこれもプラットフォームの差を無視することができます。
インストール
シェルスクリプトで作ります。
下記コマンドでgithubにホスティングしてあるinstallを実行できます。
bash -c "$(curl -L raw.githubusercontent.com/snyt45/dotfiles/master/etc/install)"インストールでやっているのは、大きく2つです。
1つ目は、dotfilesをホームディレクトリにgit cloneしています。
実行前に、gitコマンドが使えるかを確認し、gitコマンドが使えればgitコマンドを使う。
gitコマンドがなければcurlまたはwgetコマンドを使うようにすることによってプラットフォームの差を無視することができます。############################################################################## # dotfilesをホームディレクトリに複製 ############################################################################## # gitコマンドが存在すれば、gitを使う if is_exists "git"; then git clone --recursive "$DOTFILES_GITHUB" "$DOTPATH" # curl または wget が存在すれば、それを使う elif is_exists "curl" || is_exists "wget"; then local tarball="https://github.com/snyt45/dotfiles/archive/master.tar.gz" if is_exists "curl"; then curl -L "$tarball" elif is_exists "wget"; then wget -0 - "$tarball" fi | tar zxv command mv -f dotfiles-master "$DOTPATH" else log_fail "curl または wget が必要です" exit 1 fi2つ目は、落としてきた~/.dotfiles/の中で
.がつくものを列挙して、シンボリックリンクを作成しています。
これによって、~/配下に.がつく.vimrcや.bashrcが配置されるので設定が反映するようになります。
また、このとき~/配下に展開したくないものは[ "$f" = ".git" ] && continueとしてシンボリックリンクを作成せずに次の処理に移るようになっています。############################################################################## # /Users/[ユーザー名] 配下にシンボリックリンク(参照)を作成 ############################################################################## # 移動 command cd ~/.dotfiles # コマンド実行時の終了ステータスが正常(0)でなければエラー if [ $? -ne 0 ]; then log_fail "not found: $DOTPATH" exit 1 fi # ドットファイルを列挙して、シンボリックリンクを作成 for f in .??* do # 一致したら、シンボリックリンクを作成せずに次の処理に移る # 不要なドットファイルを対象から除外する [ "$f" = ".git" ] && continue [ "$f" = ".DS_Store" ] && continue ln -snfv "$DOTPATH/$f" "$HOME/$f" doneデプロイ
Makefileで作ります。
~/.dotfilesに移動して使います。
make deployインストールで2つ目にやっていることのみを切り出したものです。
(ここでは、~/.dotfilesの.がつくファイルを~/配下に展開することをデプロイと呼んでいます。)Makefileの書き方があるので、見た目は変わってますがやっていることはインストール時と同じです。
# デプロイ deploy: @$(foreach val, $(DOTFILES_FILES), ln -sfnv $(abspath $(val)) $(HOME)/$(val);)アップデート
Makefileで作ります。
~/.dotfilesに移動して使います。
make updateやっていることは、git pullです。
makeコマンドにすることで運用がとても楽になります。# 更新 update: git pull origin masterこの記事で説明していないこと
dotfilesの管理・運用手法はさまざまですが、下記記事を参考にしています。
- dotfilesで管理するもの
- vimプラグインの運用
優れた dotfiles を設計して、最速で環境構築する話 - Qiita
最強の dotfiles 駆動開発と GitHub で管理する運用方法 - Qiita
- .gitignoreの運用
さいごに
この記事で紹介しているコードは全体の一部です。
実際に自分で作る方はGitHubを参考にしてもらえればと思います。
元記事をみたら一発でわかることも多いのでそちらを参照していただけると嬉しいです。一度、運用が回ればあとは設定ファイルの育成に集中ができて、どのプラットフォームでもすぐにいつもと同じ環境で作業できるという快適ライフが待っているのでぜひお試しあれ。
- 投稿日：2020-03-18T01:31:27+09:00
挫折しないdotfiles運用 〜Windows・MacOSで使える設定ファイルを目指して〜
きっかけ
今まで何度かdotfiles運用をおこなったことがあるのですが、理解が中途半端で運用が煩雑でそのたびに挫折してきました。
しかし、下記記事に出会ったことで今までが嘘のように理解することができたので今のうちに記事にしてしまおうと思いました。
少しでもこの記事でdotfiles運用で挫折する人が減るといいなーと思います。
優れた dotfiles を設計して、最速で環境構築する話 - Qiita
最強の dotfiles 駆動開発と GitHub で管理する運用方法 - Qiita対象
dotfiles運用に憧れてるけど、うまくいかない人
Windows・MacOSで使える設定ファイルを運用していきたい人私のdotfiles
snyt45/dotfiles
※日々育成中・・・「挫折しない」dotfiles運用
挫折の要因
自分の場合は、以下のようなことがよくありました・・・
ひとつ言えるのは、運用イメージつまり運用の流れが理解できていなかったのは挫折の大きな要因かなと思います。
とりあえずGitHubでドットファイルをホスティングしておいてほしいときに持ってくればいいんでしょ。くらいでした。
これだと運用がうまくいかずに挫折するのは当たり前ですね。dotfilesの運用サイクル
運用でよく行うのは、「インストール(初回のみ)」「アップデート」「デプロイ」の3つになります。
初回のみインストールで.dotfilesを落としてきて、それをホームディレクトリ配下にシンボリックリンクとして展開します。
こうすることで、インストール後即座に設定が有効になります。設定に手を加えたら、変更内容をリモートリポジトリに反映させます。
別のPCで作業をするときは、アップデートでリモートリポジトリから最新の設定内容を~/.dotfilesに反映させます。
次に、デプロイで最新の設定内容を~/配下に反映させます。
dotfiles運用イメージ
運用でよく行う「インストール(初回のみ)」「アップデート」「デプロイ」の3つについては、コマンド化して定型化させることで複雑な運用をシンプルにします。
そして、重要なのがどの環境でも動くことが一番大事になります。コマンドについては次で説明します。
dotfiles運用コマンド
インストールコマンドにはシェルスクリプトを、アップデートとデプロイコマンドはmakeを採用しています。
シェルスクリプトはwindows、Macともbashで実行することを想定します。bashさえあれば、動かすことができるのでプラットフォームの差を無視することができます(あくまでも、windowsのbashはLinuxコマンドに近いwindowsコマンドを実行しているだけなので、シンボリックリンクなど一部コマンドは違う挙動になります。WSLを使えば100%Linux上で動作するので、同じ環境で動かすことができます)。
makeは昔からあるビルドツールで、Macはmakeがデフォルトで入っています。windowsもmakeをインストールさえすれば、すぐに使えるのでこれもプラットフォームの差を無視することができます。
インストール
シェルスクリプトで作ります。
下記コマンドでgithubにホスティングしてあるinstallを実行できます。
bash -c "$(curl -L raw.githubusercontent.com/snyt45/dotfiles/master/etc/install)"インストールでやっているのは、大きく2つです。
1つ目は、dotfilesをホームディレクトリにgit cloneしています。
実行前に、gitコマンドが使えるかを確認し、gitコマンドが使えればgitコマンドを使う。
gitコマンドがなければcurlまたはwgetコマンドを使うようにすることによってプラットフォームの差を無視することができます。############################################################################## # dotfilesをホームディレクトリに複製 ############################################################################## # gitコマンドが存在すれば、gitを使う if is_exists "git"; then git clone --recursive "$DOTFILES_GITHUB" "$DOTPATH" # curl または wget が存在すれば、それを使う elif is_exists "curl" || is_exists "wget"; then local tarball="https://github.com/snyt45/dotfiles/archive/master.tar.gz" if is_exists "curl"; then curl -L "$tarball" elif is_exists "wget"; then wget -0 - "$tarball" fi | tar zxv command mv -f dotfiles-master "$DOTPATH" else log_fail "curl または wget が必要です" exit 1 fi2つ目は、落としてきた~/.dotfiles/の中で
.がつくものを列挙して、シンボリックリンクを作成しています。
これによって、~/配下に.がつく.vimrcや.bashrcが配置されるので設定が反映するようになります。
また、このとき~/配下に展開したくないものは[ "$f" = ".git" ] && continueとしてシンボリックリンクを作成せずに次の処理に移るようになっています。############################################################################## # /Users/[ユーザー名] 配下にシンボリックリンク(参照)を作成 ############################################################################## # 移動 command cd ~/.dotfiles # コマンド実行時の終了ステータスが正常(0)でなければエラー if [ $? -ne 0 ]; then log_fail "not found: $DOTPATH" exit 1 fi # ドットファイルを列挙して、シンボリックリンクを作成 for f in .??* do # 一致したら、シンボリックリンクを作成せずに次の処理に移る # 不要なドットファイルを対象から除外する [ "$f" = ".git" ] && continue [ "$f" = ".DS_Store" ] && continue ln -snfv "$DOTPATH/$f" "$HOME/$f" doneデプロイ
Makefileで作ります。
~/.dotfilesに移動して使います。
make deployインストールで2つ目にやっていることのみを切り出したものです。
(ここでは、~/.dotfilesの.がつくファイルを~/配下に展開することをデプロイと呼んでいます。)Makefileの書き方があるので、見た目は変わってますがやっていることはインストール時と同じです。
# デプロイ deploy: @$(foreach val, $(DOTFILES_FILES), ln -sfnv $(abspath $(val)) $(HOME)/$(val);)アップデート
Makefileで作ります。
~/.dotfilesに移動して使います。
make updateやっていることは、git pullです。
makeコマンドにすることで運用がとても楽になります。# 更新 update: git pull origin masterこの記事で説明していないこと
dotfilesの管理・運用手法はさまざまですが、下記記事を参考にしています。
- dotfilesで管理するもの
- vimプラグインの運用
優れた dotfiles を設計して、最速で環境構築する話 - Qiita
最強の dotfiles 駆動開発と GitHub で管理する運用方法 - Qiita
- .gitignoreの運用
さいごに
この記事で紹介しているコードは全体の一部です。
実際に自分で作る方はGitHubを参考にしてもらえればと思います。
元記事をみたら一発でわかることも多いのでそちらを参照していただけると嬉しいです。一度、運用が回ればあとは設定ファイルの育成に集中ができて、どのプラットフォームでもすぐにいつもと同じ環境で作業できるという快適ライフが待っているのでぜひお試しあれ。