それマグで!

知識はカップより、マグでゆっくり頂きます。 takuya_1stのブログ

習慣に早くから配慮した者は、 おそらく人生の実りも大きい。

gitでリモートブランチをローカルブランチにチェックアウトする。(githubプルリクを手元にコピー

リモートにあるブランチをローカルに持って来たい

たとえば、github のプルリクなど、リモートのgit branch から自分の手元に、同じものを取り出したいときがあります。

git のリモートブランチを確認します。

git branch -a | \grep remote

たとえば、次のようにほしいブランチ名を確認します。

takuya@i$ git branch -a | \grep remote  | grep add
  remotes/origin/add_table_column
  remotes/origin/add_notify
  remotes/origin/createAddUpdateModel

これで、必要なリモートブランチ名を確認出来ました。github のプルリクをブランチベースでやっていると、プルリクに表示されてます。

git のリモートブランチが見つからない場合、

リモートブランチの名前が見つからないときは、次のように fetch します。

git fetch 

リモートブランチの名前が見つからないなんて、そんなことを起きるの?と疑問を感じるかもしれません。リモートブランチはfetch しない限り出てきません。gitは分散レポジトリなのでリモートブランチの更新を取り出す必要があります。

ローカルブランチ名を指定して、リモートブランチをコピー・チェックアウトします。

次のように、リモートブランチを取り出し、ローカルブランチの名前を付けます。別の名前も可能ですが、同じ名前にしておくのが無難だと思います。

takuya@$ git checkout -b  add_notify origin/add_notify

Branch 'add_notify' set up to track remote branch 'add_notify' from 'origin'.
Switched to a new branch 'add_notify'

これで、リモートブランチをローカルに取り出してソースコードを見ながら、実験できますね。

同じ名前を使うのであれば、次のように省略することも可能です。

git checkout -b origin/add_notify

というか、省略した此方を一般的に記事で紹介されるのではないでしょうか。ただこちらはローカルとリモートの対応がわかりづらく、ミスを誘発しやすいので最初は localと remote origin の両方を指定したほうがいいのかもしれません

さらなる短縮化が出来て

もちろん、さらなる短縮化が出来て、無意識のうちにこれを使ってる可能性があります。私もこれです。

Branch 'add_notice' set up to track remote branch 'add_notice' from 'origin'.
Switched to a new branch 'add_notice'

checkout のメッセージをよく読むと、
remote branch の add_notice が origin にあるのでそこから、追跡してブランチをセットアップするよ。(Branch 'add_notice' set up to track remote branch 'add_notice' from 'origin'.) と書いてありますね。つまり、このメッセージが出てきたらOK、省略したcheckout でもちゃんとoriginから取り出せたことが解るようです。

参考資料

Git - リモートブランチ

systemd の タイマーは enable してもstart をしないと動かない

systemd でタイマーを作ってみたんですよ。タイマーが動かないので悩んでたんです。

systemd でタイマーを作って、enableして見たんだけど。動かないんですよ。

タイマーを作る手順

  • service 作って
  • timer 作って service を起動する
  • start してチェック
  • enable する。

という手順なんだけど、start コマンド実行が大事。 timer はstart しないと動かないとか盲点でした。

dig するだけのサービスを試しに laravel で作ってみて、それでタイマーを動かすことに。

takuya@:~$ ln -sr  laravel_checkip.service /etc/systemd/system/
takuya@:~$ ln -sr  laravel_checkip.timer    /etc/systemd/system/

サービスファイルをチェックする。

takuya@:~$ sudo systemctl start laravel_checkip.service

サービスをenableにして、タイマーをenable にする。

takuya@:~$ sudo systemctl enable laravel_checkip.service
takuya@:~$ sudo systemctl enable laravel_checkip.timer

状態を確認する。

タイマーはenable してもそのままでは動かない。

takuya@:~$ sudo systemctl list-timers --all
NEXT      LEFT          LAST      PASSED       UNIT                         ACTIVATES
n/a       n/a             n/a          n/a          laravel_checkip.timer        laravel_checkip.service

8 timers listed.

start すると動き出す。

なんでかわからんけど start すると 動き出した。enable だけでいいと思ってたけど記憶違いだったらしい

takuya@:~$ sudo systemctl start  laravel_checkip.timer

動き出した。

takuya@:~$ sudo systemctl list-timers --all
NEXT          LEFT         LAST       PASSED       UNIT                                  ACTIVATES
Wed 2019-09-18 21:01:56 JST  56min left   n/a         n/a               laravel_checkip.timer        laravel_checkip.service

8 timers listed.
takuya@:~$

systemd でタイマー作るときは start timer を忘れない。

SystemCtrlのタイマーを作るときは、この手順をする。

takuya@:~$ sudo systemctl enable  laravel_checkip.service
takuya@:~$ sudo systemctl enable  laravel_checkip.timer
takuya@:~$ sudo systemctl start  laravel_checkip.timer

laravel のmodel を 外部から使う

laravel の Eloquent のモデルを別のプロジェクトからぱぱっと使う。

Consoleとかあるし、API作れば実現はできる。でも既存のものと組み合わせるときは、DBを直接書き換えたほうが早い時がある。

本当はプロジェクトの外部から直接触るのは良くないと思うし、プロジェクト側にAPIを作ったり、メンテナンス用のコマンドをプロジェクト内部につくったり、メンテナンス用のデータ復旧をMigration や Fixtgure / UnitTestと同様に作るべきなんだろうけど。

<?php
  /// laravel の Eloquent を外部から使う設定

// 必要なものをロード
  require_once __DIR__.'/vendor/autoload.php';
// DB の接続情報をいれる
  $capsule = new Illuminate\Database\Capsule\Manager();
  $capsule->addConnection([
                            "driver"   => "sqlite",
                            "database" => __DIR__."/database/database.sqlite",
                          ]);
  $capsule->setAsGlobal();
  $capsule->bootEloquent();

  ///
  /// AccessLogs モデルを保存してみる。
  require_once __DIR__.'/app/Model/AccessLogs.php';
  $al = new  App\Model\AccessLogs();
  $al->body = "Hello from  External World ";
  $al->save();

名前空間の解決

<?php
// 必要なものをロード
  require_once __DIR__.'/vendor/autoload.php';

今回は、$PROJECT_HOME/sample.php においたのでこのように書いている。

ただしくは、次のautoloadをlaravel で使っているのでこれを使う。(詳しくは laravel/public/index.php を見ればわかる。

<?php
$PROJECT_PATH/vendor/autoload.php

DB の解決

必要なロードが出来たので、DBを使うための初期設定をする。

ここでの目標は bootEloquent(); を実行することです。

<?php

// DB の接続情報をいれる
  $capsule = new Illuminate\Database\Capsule\Manager();
  $capsule->addConnection([
                            "driver"   => "sqlite",
                            "database" => __DIR__."/database/database.sqlite",
                          ]);
  $capsule->setAsGlobal();
  $capsule->bootEloquent();

最後にモデルをロードして利用する。

laravel で作っている model を 明示的にロードして、new して save する。

<?php
  /// AccessLogs モデルを保存してみる。
  require_once __DIR__.'/app/Model/AccessLogs.php';
  $al = new  App\Model\AccessLogs();
  $al->body = "Hello from  External World ";
  $al->save();

これですべて解決する。