- 投稿日：2019-12-03T23:44:39+09:00
Debianでgit diff-highlightを使う
環境
- Debian 10
- Git
apt-get install gitでインストール済み手順
※基本的には、参考サイトの手順と同じです。
diff-highlightディレクトリに移動します。
ディレクトリ内にMakefileがあるので、makeコマンドを叩いてdiff-highlightバイナリを生成します。$ cd /usr/share/doc/git/contrib/diff-highlight $ sudo make次に、/usr/local/bin/diff-highlightに対して、シンボリックリンクを貼ります。
$ sudo ln -s /usr/share/doc/git/contrib/diff-highlight/diff-highlight /usr/local/bin/diff-highlight~/.gitconfigを編集し、以下を追加します。
[pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | lesstigでも同様にハイライトできるようにするには、
~/.tigrcを編集し、以下を追加します。set diff-highlight = true参考
- 投稿日：2019-12-03T21:31:49+09:00
.gitignoreファイルを設定した
- 投稿日：2019-12-03T20:31:51+09:00
引きこもり情報系専門生、ついにターミナルからも出なくなる ~TeraPadを添えて~
初投稿です。
タイトルが違うので初投稿です。
冗談はさておきMakeIt AdventCalendar三日目では引きこもりの僕がターミナルにも引きこもって出られなくなった話をしたいと思います。※結構ネタが含まれるのであまりそういうのが受け入れ難い人はそっとページを閉じてください
本題
エディタの話
僕は5月にプログラミングの勉強を始めたのですが、最初のエディタが学校のススメで使わされていたTeraPadだったんですね。
このエディタ、本当にシンプルで便利なので全世界のプログラマーにオススメしたいのですが、あまり長く使い続けると使い心地の良さに正気を保てなくなりそうなので気をつけてください。僕は三日でVSCodeに乗り換えました。こちらはテラパ(TeraPadの愛称)程は使い心地が良くないですが、概ね良いでしょう。
もう少しテラパについて語りたいのですが、今回はテラパの紹介ではないので割愛します。
ちなみに、筆者は今vim使ってます。理由としてはかっこいいVSCodeの機能の恩恵をあまり受けられていなかったことですね。
VSCodeは拡張機能が豊富で、正直とても便利だったのですが、僕はあまり拡張機能を使わなかった(そもそもあまりごちゃごちゃ機能を入れるのは好きじゃなかった)ので、彼はクビになりました。
一日の大半をターミナルかGithub上で過ごすので、もうvimで良くね...みたいな。
コマンドはまだ慣れてないですが、vimに変えてからはかなり快適になりました。余計な表示がなくなってスッキリしたので。問題点
８割ターミナルから出なくて良くなったので大分快適なのですが、問題点が一つだけ残っていました。
そう。Githubお前だよ。
今までGitリポジトリで作業する時はブラウザでGithub開いてリモートリポジトリ立ててローカルにgit cloneして・・・って感じで作業してました。
issueとかPR出すのにGithubいちいち開くのがめっちゃ辛い。
ローカルからリポジトリ立てられないんか？とか思ってググったらありました。hub
Githubが提供しているCLI
インストール方法はhubのREADME読んでください。
これ、めちゃくちゃ便利。
ローカルからコマンド叩くだけでリモートリポジトリ作れるしissue立てれるしPRも出せる。コマンド解説(公式のソースのoption全部読むの面倒だったので一部だけ)
リモートリポジトリ作成
$ git init $ hub create リモートリポジトリ名ディレクトリ上で
git initを叩いた後にhub createするとリモートリポジトリに登録されます。
便利過ぎか・・・？
option description -p リポジトリをプライベートで作成 -d リポジトリの上の方にあるdescriptionの設定 --remote-name リモートの名前を設定する。defaultはorigin -o 作成と同時にブラウザで開ける。僕の趣旨に反するので使わない -c 作成と同時にurlをコピーする。開発する友達いないから別にいらない リポジトリの削除
$ hub delete リモートリポジトリ名便利過ぎて500万回スター押した。
貴方の黒歴史が１行で消せます！
※でも草枯れるからパカパカ消さないでね。筆者はやらかしました。
option description -y 確認をすっ飛ばして削除できる。要注意 issue関連
$ hub issue #これでissue listを表示できる $ hub issue show issue番号 #これで各詳細を表示できる $ hub issue create
issue createするとvimが開きます。焦らないで。vimは貴方の味方です。
iを押してINSERT-MODEにしてテキストを入力しましょう。
一行目にタイトルを書き、一行改行して本文を入力します。
最後にescを押し、NORMAL-MODEに戻ったら:と入力してCOMMAND-MODEに移行してwqと入力してください。
これでissue作成完了です。
option description -l -l label名を最後につけるとlabelを指定できます-a asignできます。複数asignしたい場合は ,で繋げてください-s stateを確認できます。issueがopenなのかcloseなのか -c -c コントリビュータで指定したコントリビュータが立てたissueだけ表示sync
$ git pull; git fetch # 同等 $ hub syncaliasあまり好きじゃない僕としてはこれは凄い便利だと思いました。
alias,一回使い出すと依存しそうで怖くて使えてない。後単純に設定する気力が出ない。感想
めちゃくちゃ便利の一言に尽きる。
これで僕はターミナルに引きこもります。※下書き保存した時に"あれ？PRについて何も触れてなくね？"って気づいたけど面倒なので書きません。概ねissueと一緒です。
あとがき
初日に続き結局Gitの話になってしまってとても申し訳ないです...。(なんなら昨日もGitだし)
それぐらいGitを愛用しているということでね。
今回はhubのコマンドについて紹介しましたが、きっとn番煎じなのでもっと良い記事もたくさんあると思います。
そんな中でこの記事を最後まで読んでいただきありがとうございます。
快適なターミナル生活の一助になれたら幸いです。
明日は我がサークル最強のフルスタックエンジニアがとてもタメになる記事を書いてくれるはずですのでよかったらそちらも読んでください。※ちなみに、冒頭でTeraPadへの愛が溢れていましたがあれはフィクションです。
真面目な話、あれでコーディングするならメモ帳でコーディングするのと変わらないですね。
使いたいなら止めはしませんがオススメもしません。
- 投稿日：2019-12-03T18:55:34+09:00
マージ済のfeatureブランチを一括削除
はじめに
リモートでマージ済のブランチがローカルに溜まってしまうと邪魔になるので一括で削除できるプログラムを作成しました.
grepして一括削除!!みたいなことなら以下の記事に書いてある方法で実現可能です.featureブランチを一括削除
GitDetroit を作りました.
$ gdes do you remove feature/create_user-activate_logic ? (y/n)みたいな感じで,
feature/xxx_xxx_xxxなブランチを不要なもののみ削除することができます.
ちなみに, 上記の例では,git-detroitコマンドに対してエイリアスを作成しています.インストール
Homebrewを使用するので最初にインストールします.$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
GitDetroitは公式ではないので, 最初にtapしてからインストールします.$ brew tap dj-hirrot/git-detroit $ brew install git-detroit以上.
これだけで使用することができます.
また, 以下のコマンドでエイリアスを作成することができます.
*[cmd]にエイリアスコマンドを入力します$ $ echo "alias [cmd]='git-detroit'" >> ~/.alias
- 投稿日：2019-12-03T18:55:34+09:00
ブランチを一括削除
はじめに
リモートでマージ済のブランチがローカルに溜まってしまうと邪魔になるので一括で削除できるプログラムを作成しました.
面倒な設定なんて全く必要なく, ただインストールするだけで使用できるシンプルなヤツです.
grepして一括削除!!みたいなことなら以下の記事に書いてある方法で実現可能です.featureブランチを一括削除
GitDetroit を作りました.
$ gdes do you remove feature/create_user-activate_logic ? (y/n)みたいな感じで,
feature/xxx_xxx_xxxなブランチを不要なもののみ削除することができます.
ちなみに, 上記の例では,git-detroitコマンドに対してエイリアスを作成しています.インストール
Homebrewを使用するので最初にインストールします.$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
GitDetroitは公式ではないので, 最初にtapしてからインストールします.$ brew tap dj-hirrot/git-detroit $ brew install git-detroit以上.
これだけで使用することができます.
また, 以下のコマンドでエイリアスを作成することができます.
*[cmd]にエイリアスコマンドを入力します$ $ echo "alias [cmd]='git-detroit'" >> ~/.alias
- 投稿日：2019-12-03T18:43:02+09:00
さくらVPSでCentOS7 １１．RailsプロジェクトをGitで共同開発
はじめに
自由にテスト出来るLinuxのサーバーがほしくて、さくらVPSで構築してみました。
順次手順をアップしていく予定です。前回インストールしたRuby On Railsを共同開発できるようにGitで管理したいと思います。
目次
- 申し込み
- CentOS7インストール
- SSH接続
- Apache・PHPインストール
- MariaDBインストール
- FTP接続
- sftp接続
- phpMyAdminインストール
- 環境のバックアップ
- Ruby On Railsインストール
- RailsプロジェクトをGitで共同開発
１１．RailsプロジェクトをGitで共同開発
前回、Ruby On Railsインストール時に作成したテスト用プロジェクトHelloWorkdを共同開発できるようにGitで管理したいと思います。
共同開発用のマシンは、ローカルのWindows10のマシンにします。
構成は、こんな感じです。
共有リポジトリは、GitHub等を使う方法もありますが、今回はプロジェクトの有るさくらVPSサーバー内に作成します。Gitでは、開発マシンのソースを直接本番ソースにアップするのではなく、一度共有リポジトリにアップしたものを本番ソースから取りに行く形になります。
本番ソースも開発と同様ローカルポジトリですので、開発側がアップした変更は手動で本番ソースに取り込む必要があります。
これだと不便ですので、共有リポジトリが変更を受け取った時自動的に本番ソースが取りに行くように設定します。さくらVPSにGitインストール
インストール
$ sudo yum install git-allインストール後の設定
ユーザ名とメールアドレスを設定します
$ git config --global user.name "sakura" $ git config --global user.email sakura@kogueisya.comgitの出力をカラーリング
$ git config --global color.ui autoディフォルトエディタの設定
$ git config --global core.editor vimエイリアス設定（「checkout」を「co」に設定）
$ git config --global alias.co checkout確認
$ git config user.name sakura $ git config -l user.name=sakura user.email=sakura@kougeisya.com color.ui=auto core.editor=vim alias.co=checkout core.repositoryformatversion=0 core.filemode=true core.bare=false core.logallrefupdates=true $ cd $ cat .gitconfig [user] name = sakura email = sakura@kougeisya.com [color] ui = auto [core] editor = vim [alias] co = checkout共有リポジトリ（ベアリポジトリ）作成
さくらVPSサーバーに共有リポジトリを作成します。
共有リポジトリ用ディレクトリ作成
/optの中に「プロジェクト名.git」というフォルダを作成します。
$ sudo mkdir -p /opt/helloworld.git/-pは/optフォルダがなければ作成します。
所有者変更
フォルダの所有者を 「4．Apache・PHPインストール」で作成したWebコンテンツ操作用のグループ（webadmin）にします。
$sudo chown root:webadmin /opt/helloworld.git/ $sudo chmod 2775 /opt/helloworld.git/ -Rベアリポジトリを作成
$ cd /opt/helloworld.git $ git init --bare --share Initialized empty shared Git repository in /opt/helloworld.git/---bareは、ベアリポジトリを作成するオプション
--shareは、ベアリポジトリを複数のユーザによって共有可能にするオプション本番ソース
前回「10．Ruby On Railsインストール」で作成したHelloWorldプロジェクトにローカルリポジトリを作成し、リモートリポジトリにプッシュします。
リポジトリのセットアップ
$ cd /var/www/app/HelloWorld $ git init Reinitialized existing Git repository in /var/www/app/HelloWorld/.git/除外ファイル指定
railsコマンド実行時に作成される.gitignoreファイルにリポジトリから除外するファイルを指定するためのルールが記載されています。
このファイルに以下を追加します。$ vi .gitignore# Ignore other unneeded files. doc/ *.swp *~ .project .DS_Store .idea .secretファイルをインデックスに追加（addコマンド)
プロジェクトのファイルをコミット待ちの変更が格納される「ステージングエリア」という一種の待機場所に追加
$ git add .確認
ステージングエリアにあるファイルのリスト表示$ git statusコミット
ローカルリポジトリへの変更反映
$ git commit -m "Initalize repository"コミットメッセージの履歴参照
$ git log commit d3f7327c74c7175b75ca7d78f4a1cd576f5b6d9a Author: sakura <sakura@kougeisya.com> Date: Mon Dec 2 15:49:37 2019 +0900 Initialize repositoryリモートリポジトリにプッシュ
リモートリポジトリのアドレスに「origin」という名前を付けて記録
（「origin」にしたのは、pushやpullコマンドは実行時にリモートリポジトリ名を省略するとoriginという名前を使用する為）$ git remote add origin /opt/helloworld.gitリポジトリをプッシュ
$ git push -u origin master Counting objects: 6674, done. Delta compression using up to 2 threads. Compressing objects: 100% (6272/6272), done. Writing objects: 100% (6674/6674), 29.86 MiB | 8.65 MiB/s, done. Total 6674 (delta 909), reused 0 (delta 0) To /opt/helloworld.git * [new branch] master -> master Branch master set up to track remote branch master from origin.-uオプションは、「git push -u origin master」とすると次回から「git push」だけでpushしてくれます。
本番ソース反映の自動化
本番ソースも開発と同様ローカルポジトリですので、開発側がアップした変更は手動で本番ソースに取り込む必要があります。
これだと不便ですので、共有リポジトリが変更を受け取った時自動的に本番ソースが取りに行くように自動化します。自動化にはフックを使います。
フックは、Gitでコマンドを実行する直前もしくは実行後に特定のスクリプトを実行する為の仕組みです。フックの種類（サーバーサイド）
フック 概要 pre-receive クライアントからpushを受け取った直後に起動。
更新内容の確認が可能。post-receive push内容の適用終了後起動。
通知を行う場合に便利。update pushによる更新対称ブランチごとに起動。 共有リポジトリの中にある「hooks」の中に、フック名のスクリプトファイルを作成することで実現できます。
今回は、開発のローカルリポジトリからプッシュされ、その内容が適用された後に本番のローカルリポジトリからプルするスクリプトを実行したいので、「/opt/helloworld.git/hokks/post-receive」というスクリプトファイルを作成します。
スクリプトの内容は、本番ソースのドキュメントルートに移動し、publlを実行します。$ vi /opt/helloworld.git/hooks/post-receive#!/bin/sh cd /var/www/app/HelloWorld/ git --git-dir=.git pullスクリプトファイルを他のユーザから実行できるようにパーミッションを設定します。
$ chmod 755 /opt/helloworld.git/hooks/post-receive以上でサーバー側の設定は完了です。
開発用ローカルマシン（Windows10)の設定
各ツールのインストール
Ruby、Rails、Git等をインストールしていきます。
Rubyインストール
下記サイトからダウンロードします。
最新版の「Ruby+Devkit 2.6.5-1 (x64)」をダウンロードしました。
https://rubyinstaller.org/downloads/
ダウンロードしたファイルを実行すると下記の画面が表示されます。
「◎I accept the License」を選択し[Next>]をクリックします。
下記画面が表示されたら、チェックボックス３つともチェックをいれ、[Install]をクリックします。
下記画面が表示されたらそのまま[Next>]をクリックします。
下記画面のようにインストールが開始されますので、終わるまでしばらく待ちます。
インストールが終了すると、下記画面が表示されます。
そのまま[Finish]をクリックすると画面が閉じ、インストールが完了します。
引き続き下記の画面が開きます。
1,2,3と入力して[Enter]キーを押すとインストールが開始されます。
インストールが完了すると下記画面のように「Which components shall be installed? If unsure press ENTER []」と表示されますので、[ENTER]キーを押すと画面が閉じます。
Railsに必要なgemをインストール
SQLite3インストール
コマンドプロンプトを開き、以下を実行します。
> ridk exec pacman -S mingw-w64-x86_64-sqlite3下記画面のように「インストールを行いますか? [Y/n]」と聞いてきますので「Y」を入力します。
プロンプトに戻ったらインストール終了です。
引き続き以下のコマンドを実行します。> gem install sqlite3 --platform ruby下記画面のようにプロンプトに戻ったら完了です。
nokogiriインストール
コマンドプロンプトで以下を実行します。
> ridk exec pacman -S mingw-w64-x86_64-libxslt下記画面のように「インストールを行いますか? [Y/n]」と聞いてきますので「Y」を入力します。
プロンプトに戻ったらインストール終了です。
引き続き以下のコマンドを実行します。> gem install nokogiri --platform ruby -- --use-system-libraries下記画面のようにプロンプトに戻ったら完了です。
Node.jsインストール
下記サイトからダウンロードします。
https://nodejs.org/ja/download/
「LTS推奨版」「Windows Installer (.msi)」の「64-bit」をダウンロードしました。
ダウンロードしたファイルを実行すると下記の画面が表示されますので[Next]をクリックします。
下記画面が表示されたら「□I accept the terms in the License Agreement」にチェックを入れ[Next]をクリックします。
下記画面が表示されますので、そのまま[Next]をクリック。
下記画面もそのまま[Next]クリック。
下記画面が表示されたら「Automatically install the ・・・」にチェックをいれて[Next]をクリック。
下記画面の[Install]クリックで、インストールが開始されます。
インストールが終わるまでしばらく待ちます。
インストールが終わると下記画面が開きますので[Finish]をクリックすると画面が閉じます。
引き続き下記の画面が開きます。
「継続するには何かキーを押してください ．．．」と2回表示されますので都度[Enter]キーを押してください。
下記の画面が開き、インストールが開始されます。
下記のように「Tyoe ENTER to ext:」と表示されたら完了です。
[Enter]キーを押すと画面が閉じます。
Bundlerインストール
コマンプロンプトを開き下記のコマンドを実行します。
> gem install bundler
Gitインストール
GUIでGitが使えるTortoiseGitを使います。
画面のキャプチャは取っていませんでしたm(__)mGit For Windows
下記サイトの[Download]ボタンよりダウンロード
ダウンロードしたファイルを実行し、画面に従いインストール
https://gitforwindows.org/
TortoiseGit
下記サイトのfro 64-bit Windowsの「Download TortoiseGit 2.9.0-64.bit(~19.5Mib)」をクリックしてダウンロード
ダウンロードしたファイルを実行し、画面に従いインストール
https://tortoisegit.org/download/
メニュー等を日本語に設定
下記サイトからLanguage PacksのJapanese 64Bitの[Setup]をクリックしてダウンロード
ダウンロードしたファイルを実行し、画面に従いインストール
https://tortoisegit.org/download/
インストール後、デスクトップの適当な場所で右クリックし表示されるメニューから[TortoisGit]-[設定]を選択
開いた画面の[全般][TotoiseGit][言語(Language)]より「日本語（日本）」を選択、[OK]ボタンをクリック
以上でWIndows10の設定は完了です。クローンを作成
共有リポジトリからクローンを作成します。
作成場所は、C:\Prj\HelloWorldにします。TortoiseGitを利用してクローン作製
デスクトップ等適当な場所で右クリックし、表示されたメニューから[Gitクローン (複製)...]を選択します。
下記の設定画面が開きます
URLには以下の値を設定します。
"ssh://" + ユーザー名 + "@" + さくらVPSサーバーのアドレス + ":" + SSHポート番号 + "共有リポジトリディレクトリ"ディレクトリは、クローンを作成するフォルダ名を設定します。
ここでは、「C:\Prj\HelloWorld」にしました。
フォルダは無ければ作成されます。Putty鍵のロードにチェックを入れ、[...]をクリックし、秘密鍵を選択します。
ここで選択する秘密鍵は、「 7.sftp接続」の設定時に作成した秘密鍵ファイルです。[OK]をクリックすると、秘密鍵のパスフレーズを聞いてきますので、「 7.sftp接続」で設定したパスフレーズを入力し[OK]をクリックします。
クローン作製中
無事終了しました
フォルダ確認
動作確認
サーバーを起動してみる
コマンドプロンプトを起動し、ディレクトリの移動。
> cd \Prj\HelloWorldとりあえずサーバーを立ち上げてみたら、railsコマンドがみつからないので、「bundle install」しろと出ました。
>bundle exec rails s bundler: command not found: rails Install missing gem executables with `bundle install`「bundle install」を実行すると、派手にエラーが出ました(T0T)
>bundle install Fetching gem metadata from https://rubygems.org/. Retrying fetcher due to error (2/4): Bundler::PermissionError There was an error while trying to read from `C:/Users/sugi/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/info/mini_portile2`. It is likely that you need to grant read permissions for that path. . Retrying fetcher due to error (3/4): Bundler::PermissionError There was an error while trying to read from `C:/Users/sugi/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/info/thread_safe`. It is likely that you need to grant read permissions for that path. . Retrying fetcher due to error (4/4): Bundler::PermissionError There was an error while trying to read from `C:/Users/sugi/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/info/websocket-driver`. It is likely that you need to grant read permissions for that path. . There was an error while trying to read from `C:/Users/sugi/.bundle/cache/compact_index/rubygems.org.443.29b0360b937aa4d161703e6160654e47/info/globalid`. It is likely that you need to grant read permissions for that path.どうもファイルの読み取り権限に問題があるようです。
調べてもよくわからなかったので、ちと乱暴ですが管理者としてコマンドプロンプトを実行してみました。
再度「bundle install」したら、無事動きました。
サーバー起動に再チャレンジ。
>bundle exec rails server -b 0.0.0.0 => Booting Puma => Rails 5.2.4 application starting in development => Run `rails server -h` for more startup options Please add the following to your Gemfile to avoid polling for changes: gem 'wdm', '>= 0.1.0' if Gem.win_platform? Please add the following to your Gemfile to avoid polling for changes: gem 'wdm', '>= 0.1.0' if Gem.win_platform? *** SIGUSR2 not implemented, signal based restart unavailable! *** SIGUSR1 not implemented, signal based restart unavailable! *** SIGHUP not implemented, signal based logs reopening unavailable! Puma starting in single mode... * Version 3.12.1 (ruby 2.6.5-p114), codename: Llamas in Pajamas * Min threads: 5, max threads: 5 * Environment: development * Listening on tcp://0.0.0.0:3000 Use Ctrl-C to stopブラウザで確認。
動いているようです。
コントローラーを作成しプッシュしてみる
コントローラを作成
>bundle exec rails generate controller hello Please add the following to your Gemfile to avoid polling for changes: gem 'wdm', '>= 0.1.0' if Gem.win_platform? Please add the following to your Gemfile to avoid polling for changes: gem 'wdm', '>= 0.1.0' if Gem.win_platform? create app/controllers/hello_controller.rb invoke erb create app/views/hello invoke test_unit create test/controllers/hello_controller_test.rb invoke helper create app/helpers/hello_helper.rb invoke test_unit invoke assets invoke coffee create app/assets/javascripts/hello.coffee invoke scss create app/assets/stylesheets/hello.scssapp/controllers/hello_controller.rbにアクションメソッドindexを追加
class HelloController < ApplicationController def index render plain: 'こんにちは、世界！' end endconfig/routes.rbにルーティング設定
Rails.application.routes.draw do # For details on the DSL available within this file, see http://guides.rubyonrails.org/routing.html get 'hello/index', to: 'hello#index' endローカルサーバーを起動し動作確認
> bundle exec rails s
プッシュ
変更したファイルをさくらVPSサーバの共有リポジトリにプッシュします。
その前に、ローカルリポジトリに変更をコミットします。HelloWorldフォルダの上で右クリックし、表示されたメニューより[Gitコミット(C)->"master"...]を選択。
下記のようにコミット画面が表示されますので、「メッセージ」を入力し、追加ファイルにチェックを入れ[コミット]ボタンをクリックします。
下記画面のようにコミットが実行され、成功と表示されるとコミットは成功です。
コミットが成功したら、共有リポジトリへプッシュします。
上記画面の[プッシュ]ボタンをクリックすると下記のプッシュ画面が開きます。
[OK]をクリックし、サーバーの共有リポジトリにプッシュします。
プッシュが実行されます。
無事成功しました。
さくらVPSサーバーでの動作確認
Git確認
共有リポジトリへのプッシュ確認
$ cd /opt/helloworld.git $ git log commit 941e28b8e44d6dfcbe2ba2bdf5189cba76b92b38 Author: Kouichi Sugimoto <sugi@kougeisya.com> Date: Tue Dec 3 18:06:20 2019 +0900 Windowsからのプッシュテスト commit d3f7327c74c7175b75ca7d78f4a1cd576f5b6d9a Author: sugi <sugi@kougeisya.com> Date: Mon Dec 2 15:49:37 2019 +0900 Initialize repositoryプッシュはうまくいっているようです。
開発リポジトリから共有リポジトリにプッシュがあると、自動的に本番サーバーがプルするように設定していました。
これが動いているかログをチェックします。$ cd /var/www/app/HelloWorld $ git log commit 941e28b8e44d6dfcbe2ba2bdf5189cba76b92b38 Author: Kouichi Sugimoto <sugi@kougeisya.com> Date: Tue Dec 3 18:06:20 2019 +0900 Windowsからのプッシュテスト commit d3f7327c74c7175b75ca7d78f4a1cd576f5b6d9a Author: sugi <sugi@kougeisya.com> Date: Mon Dec 2 15:49:37 2019 +0900 Initialize repositoryhello_controller.rbが出来ているかチェック
$ cd /var/www/app/HelloWorld/app/controllers $ ls application_controller.rb concerns hello_controller.rb動作確認
本番ソースのサーバーを起動します。
$cd /var/www/app/HelloWorld $ rails server -b 0.0.0.0 => Booting Puma => Rails 5.2.4 application starting in development => Run `rails server -h` for more startup options Puma starting in single mode... * Version 3.12.1 (ruby 2.6.5-p114), codename: Llamas in Pajamas * Min threads: 5, max threads: 5 * Environment: development * Listening on tcp://0.0.0.0:3000 Use Ctrl-C to stopブラウザで確認
無事動きました。
これでGitを使った共同開発の環境が出来ました。次回
次回は、Pythonのインストールの予定です。
- 投稿日：2019-12-03T17:10:34+09:00
git add -pで分割コミットしようとするとlint-stagedでエラーになる
症状
git add -pなどして「partially staged」した状態からgit commit経由でlint-stagedをすると、エラーになった。lint-stagedのバージョンは9.2.3で確認
$ git commit husky > pre-commit (node v11.13.0) Stashing changes... [started] Stashing changes... [completed] Running tasks... [started] Running tasks for *.js [started] eslint --fix [started] eslint --fix [completed] git add [started] git add [completed] Running tasks for *.js [completed] Running tasks... [completed] Updating stash... [started] Updating stash... [completed] Restoring local changes... [started] Restoring local changes... [failed] → Command failed with exit code 128 (Unknown system error -128): git checkout-index -a Command failed with exit code 128 (Unknown system error -128): git checkout-index -af husky > pre-commit hook failed (add --no-verify to bypass)これが起こると、lintが異常終了していて以下の状態になる。
- add -pして分け分けしたdiffを持つファイルが全部add状態になる
- 一部のファイルがworkdirからなくなる (たまたま作業中のファイルに当たると悲惨?)
原因と解決策
別端末で自動ファイル更新検知と再ビルドが走っていると、それと競合することが原因の模様。
npm run serve経由で開発用httpサーバーを動かしていた。解決策はシンプルに開発用httpサーバーを都度止めてgit操作をする。ちょっと面倒だがとりあえずデータロストの心配はなくなる。
参考 & 解決策ではなかったもの
- そもそもpartially stagedなdiffをlint-stagedが扱えるようになったのはver.8以降。その基本アリゴリズムはこちらの通り。
- partially stagedなdiffとlint-stagedの組み合わせに関するバグが
lint-staged@9.5.0で修正されているそうなので、それにアップデートしてみたが、本投稿の件は解決しなかった。よく見るとエラーメッセージが違う。ちなみにこのバグは本投稿の事象のエラーメッセージ中のgit checkout-index -afで検索をかけて発見した。- エラーメッセージ中には
--no-verifyしろと書いてあるが、それをやると当然lintが通らないので回避は可能だが解決策にはならない。
- 投稿日：2019-12-03T17:06:46+09:00
【Git】SourceTree嫌いがよく使うgitコマンド
【Git】SourceTree嫌いがよく使うgitコマンド
この記事は「ちゅらっぷす Advent Calendar 2019」の3日目です。
https://qiita.com/advent-calendar/2019/churappsSourceTree嫌い
えー唐突ですが私、SourceTreeが嫌いでして。
嫌いな理由はいくつかありますが、周りと同調できないダメな人間です。
そもそもGUIに苦手意識があって予告なくUIの変更などがあるともうキレそう。というかキレてます(苦笑)基本的なコマンドばかりですが、SourceTreeを利用し続けていたら知らなかったかもしれないオプションも紹介しますので是非お付き合いください。
clone
## base branchを参照、フォルダ名はリポジトリ名依存 $ git clone リポジトリ名 ## ブランチを指定、指定のフォルダ名でcloneする $ git clone リポジトリ名 -b ブランチ名(省略時はbase_branch) フォルダ名ブランチ、フォルダ名指定オプション付きで
git cloneします。diff
## ファイル差分 $ git diff「どのファイルにどんな変更加えたっけ？」って時に使ってました。
git addする直前とかですかね。
現在ではVSCodeのプラグインで差分や履歴が一目瞭然なのであまり使う機会はなくなりました。status
## 変更点の確認 $ git status変更、削除、新規ファイルなのか見る際に利用します。
remote
## リポジトリのプッシュ先などを確認 $ git remote -v複数案件を並行で進めてる時が多いので、「これ本当に〇〇案件のリポジトリでPush先もおかしくないよな？」と不安になった際につかいます。
branch
## 現在のブランチ $ git branch ## remote含む全てのブランチ $ git branch -acheckout後に確認のために利用することが多いですかね
checkout
## ブランチの切り替え $ git checkout ブランチ名 ## ブランチを作成しつつ切り替え $ git checkout -b ブランチ名Checkoutの際に
-bオプションで、新規でローカルブランチを作成しつつCheckoutできます。commit
## 通常のコミット(add済み) $ git commit -m "動かないけどマージしたい" ## addも一緒にするcommit $ git commit -a -m "なぜか動くからリリースしようぜ"
git addが面倒なので僕はだいたい-aオプション付きでCommitします。push
## 通常 $ git push ## 新規ローカルブランチ $ git push --set-upstream origin ブランチ名新規ローカルブランチで
git pushすると--set-upstreamオプションつけろなどと怒られますね。
ちなみに後者の方でpushすると、プルリク用のURLが発行されるのでリンクにアクセスするだけでプルリク作成画面へ飛べます。便利。GUIを使わない理由
多分ですけど、「コマンドで仕事してる俺カッケェェェ」って思ってるんだと思います笑
でも正直、コマンドベースで動きをある程度覚えてからGUIツールを利用した方が理解度高まるんじゃないかなと思ってます。上記で紹介したコマンドはどれも基本的なものですが、オプションがややこしいので何か気になる点などございましたらご指摘ください。
- 投稿日：2019-12-03T15:13:58+09:00
【GitHub】ローカル環境にあるフォルダをリモートリポジトリにアップロードする際に詰まった話
はじめに
今年入社したkitaです。
GitHubへの登録は大きく分けて「GitHub側でNewボタンを押してリポジトリを作り、それをgit clone パスでローカルに持ってくる」というやり方と「ローカルでGitリポジトリを作り、それをGitHubに新規リポジトリとしてpushする」というやり方が考えられるが、今回は
ローカルでGitリポジトリを作り、それをGitHubに新規リポジトリとしてpushするでやっていこうと思う。
なぜこれをやるのか
- Webサイトを公開したかった
- GitHub Pagesで公開する課題が与えられたので
GitHubのQuick setupに表示されたコマンドライン通りにやってみる
echo "# mytest" >> README.md git init git add README.md git commit -m "first commit" git remote add origin URL git push -u origin master詰まったところ（エラー）
- コミットできない
git remote addって何？- originって何？
git pushできない原因と解決
1. コミットできない→
git addしていなかったGit管理しないとコミットできないじゃん。
コミットできない〜と嘆いていたのはこれが原因だった。2.
git remote addの意味を知らなかった逆に
git remote removeがある。リモートを追加(add)したり、削除(remove)したり出来る。3.
git remote add name URLとなっていた部分のnameがoriginだと思わなかったoriginは、GitHubがリモートリポジトリにデフォルトで付ける名前である。
リモート、橋の向こう側にいるのはorigin。
僕は複製された存在だ。4.
git pushができなかった$ git push fatal: The current branch master has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin masterメッセージにあるように、
git push --set-upstream origin masterすれば解決あと
git remote add origin URLとしたときに、別のリポジトリが存在していた。リポジトリを消す：
git remote remove originリモートリポジトリは消えない。ローカルの情報だけ。リポジトリのURL変更：
git remote set-url origin https://github.com/ユーザー名/リポジトリ名.git振り返り
まだまだGitについての理解が足りていないし、一晩寝たら忘れてしまう。
使い続けるor自分で解決できる能力を育てていく必要がある。
- 投稿日：2019-12-03T14:10:05+09:00
git submoduleのinitとupdateは同時に実行できる
コマンド。
$ git submodule update --init(すごいURLだ。。)
- 投稿日：2019-12-03T12:44:28+09:00
【GitHub】ローカル環境にあるフォルダをリモートリポジトリにアップロードする際に詰まった話
はじめに
新卒のkitagawaです。
なぜこれをやるのか
- Webサイトを公開したかった
- GitHub Pagesで公開する課題が与えられたので
公開する手順
・HTML, CSS, JavaScriptが入ったフォルダを用意する
↓
・echo "# test" >> README.md
READMEを追加。やっぱり入れておかないとダメだよね。
↓
・git initでローカルリポジトリを新規に作成。
「.git」というリポジトリを構成するディレクトリが作成される
↓
・git add .でファイル全てをGit管理。
GitHubデフォルトには「git add README.md」と書いてあるからとりあえずそれでも良い。
↓
・git commit -m "first commit"でコミットする。
↓
・git remote add originここにURL
↓
・git push -u origin master詰まったところ
- コミットできない
- git remote addって何？
- originって何？
- git pushできない
原因と解決
1. コミットできない→git add していなかった
Git管理しないとコミットできないじゃん。
コミットできない〜と嘆いていたのはこれが原因だった。2. git remote addの意味を知らなかった
逆に
git remote removeがある。リモートリポジトリを紐付けたり(add)削除したり(remove)出来る。3. git remote add name URL となっていた部分のnameがoriginだと思わなかった
originは、デフォルトのリモートリポジトリの場所(URL)の別名である。
リモート、橋の向こう側にいるのはorigin。
僕は複製された存在だ。4. git push ができなかった
差分がないからできていなかったんじゃないかな。
あとはgit remote add origin URLとしたときに、別のリポジトリが存在していた。
originのリモート情報を消す・新しいリポジトリにしたいなと思ったら
消す：git remote remove origin //GitHubのリポジトリは消えない。手元の情報だけ。
URL変更：git remote set-url originhttps://github.com/ユーザー名/リポジトリ名.git振り返り
まだまだGitについての理解が足りていないし、一晩寝たら忘れてしまう。
使い続けるor自分で解決できる能力を育てていく必要がある。
- 投稿日：2019-12-03T10:59:01+09:00
[バッチ/git] バッチをgitに上げてそれを他の人がクローンすると、なんか動きませんけどと言われる(gitにコミット時の改行の扱いについて)
もくじ
→https://qiita.com/tera1707/items/4fda73d86eded283ec4fやりたいこと
バッチを作成して、gitに上げて、他の人がそれをダウンロード(Cloneではなく)して使うとなんか文字化けしてうまく動かない、となってしまった。
ちょっと見ると、Gitにpushしてクローンしたときは、バッチファイル(に限らずテキストファイルすべて)の各行の改行コードはとくに変わらず元のままだが、zipでダウンロードすると、なぜか改行コードがunix形式(LF)になって帰ってくる。
そのバッチをダブルクリックして動かそうとしてもうまく動いてくれないので、「作ったときはうまくいったのに、他の人がダウンロードしたら動かない」ということなってしまっているっぽい。
対策
今回編み出した対策としては、下記を徹底すること。
- 日本語を使うバッチファイルは、下記で保存する
- SJIS
- 改行コード=CR+LF
- バッチファイルを使うときは、リポジトリをzipダウンロードして使わない。Cloneして使う。
後日追記で、最終的にはこうした、というのを書いた。このぺージの下の方を参照
そうする理由
2段階ある。
git側の理由
設定によるようだが、gitの標準設定では、
テキストファイルをコミットとpush、逆にチェックアウト(Clone)したときは、内部で
- コミット時に CRLF -> LF
- チェックアウト時に LF -> CRLF
がされている。
zipでダウンロードしたときは、その1番のほうだけ実施されて、2番の元に戻す処理の方が実施されないままダウンロードされるっぽく、LFになったままで帰ってきてしまう。
※gitの設定で、改行コードを変換しないように変えることができるっぽい。(こちら参照)
が、gitの標準がこれをやる方なのであれば、個人的にあまり設定は変えたくないと思う。コマンドプロンプト側の理由
- 現状のWindowsのコマンドプロンプトでは、Unix形式の改行コード(LF)はうまく動いてくれない(LFで改行してると、改行として認識しないっぽい。日本語のある時だけ？)(こちら参照)
- UTF8でBOMありにすると、BOMのせいでバッチの1行目がうまく実行されない。
- 改行はCR+LFにしておかないと、コマンドプロンプトではうまく動かない(日本語なければうまくいくかも？)
- また、utf-8でCRLF、BOMなしで問題なく動くかと思ったが、試したところうまく動かないケースがある。下記参照。
echo 日本語の文字列とやると、うまく動かなかった。utf-8、BOMなし、CRLFでうまく動かないケース.batchcp 65001 echo あいうえお echo あいうえお echo かきくけこ echo かきくけこ echo 会い上御 echo 会い上御 pauseまた、下の備考にあるように、ファイル名の日本語も文字化けする。
だから
バッチがうまくうごかなくなる。
個人的に、コメントに日本語を使うことや、echoで日本語を出力することは排除できないと思うので、上に書いた対策としたい。備考
手元作業したフォルダ、cloneしてきたフォルダ、zipダウンロードしてきたフォルダを比較すると、こんな感じになった。(docとかsrcフォルダ、readme.mdは関係なし)
追記
改行コードはgitの設定によってそういう動きをしていた
ここまでで見てきた
CR+LFがLFになってしまう、などの動きは、gitの設定によるものと思われる。
→作業用PCにて、設定変更のためのコマンドgit config --global core.autocrlf falseを実行すると、改行コードが勝手にLFになるのは回避できることが分かった。なので、
- core.autocrlf を falseにしておく
- バッチをコミットするときにCRLFで保存しておく
を守れば、「改行がLFであるがためにバッチが動かない」は回避できる。
ただ、BOMがついていると、バッチの1行目をうまく実行できない件は回避できないので、最終的に下記のようになると思われる。
★最終的な対策
バッチファイルをgitにコミット/プッシュして使いたい場合、文字コード関連はこのようにしておけばよいと思われる。
- git環境構築時
git config --global core.autocrlf falseを実行して、自動でCRLF変換されないようにする- コミット/プッシュ実施時
- コメント以外に日本語を使わない
- バッチファイルを下記の設定で保存する
(バッチファイル自身にUTF-8を使いたい場合)
- utf-8
- BOMなし
- CR+LF
- バッチファイルを下記の設定で保存する
(バッチファイル自身にSJISを使いたい場合)
- SJIS
- CR+LF
★最終的に得た教訓
バッチファイルは...
- 改行コードがLFだと動かない。
- 文字コードがutf-8だと動かない時がある。(詳しい条件は不明)
- BOMありutf-8だと、1行目に化けた文字が入ってうまく動かない。
gitの環境は...
- 適切に初期設定しておかないと、思わぬ動きをする。
- 例えば、core.autocrlf がtrueだとコミット時に勝手に改行コードが変わる。(対策は上参照)
- 関連メンバーで設定を同じにしておく必要アリ。
参考
バッチファイルを UTF-8 で書く
→バッチは改行=LFでは動かない、とある。
https://itpc.blog.fc2.com/blog-entry-193.htmlコミット時に CRLF -> LF。チェックアウト時に LF -> CRLF。
→そういう変換が、自動でかかっているらしい。
https://qiita.com/shuhei/items/2da839de8803cb335f86改行コード LF で日本語を含むバッチファイルの動作がおかしい件
→LF(+多分UTF8?)のときの動きを詳しく試しておられる。
https://miau.hatenablog.com/entry/20100929/1285768041
- 投稿日：2019-12-03T09:51:31+09:00
GitリポジトリのライブラリをAndroidアプリから参照する
Gitのリポジトリのライブラリを参照する方法
色々調べてトライしたけれど、ブランチ指定した場合にうまく動作するのがこの方法だったのでメモ
他の方法はmaster指定しかうまく動かなかった・・・詳細は以下のソースコードをみてください。
[ライブラリのリポジトリ]
https://github.com/tokuyama-san/MyLibrarybuild.gradle(Module)apply plugin: 'com.android.library' apply plugin: 'kotlin-android' apply plugin: 'kotlin-android-extensions' apply from: 'maven.gradle' ←ここを追加 android { compileSdkVersion 29 defaultConfig { minSdkVersion 28 targetSdkVersion 29 versionCode 1 versionName "1.0" testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner" consumerProguardFiles 'consumer-rules.pro' } buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } } } dependencies { implementation fileTree(dir: 'libs', include: ['*.jar']) implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version" implementation 'androidx.appcompat:appcompat:1.1.0' implementation 'androidx.core:core-ktx:1.1.0' testImplementation 'junit:junit:4.12' androidTestImplementation 'androidx.test.ext:junit:1.1.1' androidTestImplementation 'androidx.test.espresso:espresso-core:3.2.0' }maven.gradledef versionName = "0.9.1beta" def repo = new File(rootDir, "repository") apply plugin: 'maven' apply plugin: 'kotlin-android' apply plugin: 'kotlin-android-extensions' uploadArchives { repositories { mavenDeployer { repository url: "file://${repo.absolutePath}" pom.version = "${versionName}" // version pom.groupId = 'toku.san.mylibrary' // グループ名 pom.artifactId = 'MyLibrarySDK' // ライブラリ名 } } }[アプリのリポジトリ]
https://github.com/tokuyama-san/MyApplicationbuild.gradle(Project)// Top-level build file where you can add configuration options common to all sub-projects/modules. buildscript { ext.kotlin_version = '1.3.50' repositories { google() jcenter() maven { url "https://github.com/layerhq/releases-gradle/raw/master/releases" } ←これを追加 } dependencies { classpath 'com.android.tools.build:gradle:3.5.1' classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version" // NOTE: Do not place your application dependencies here; they belong // in the individual module build.gradle files classpath group: 'com.layer', name: 'git-repo-plugin', version: '1.0.0' ←これを追加 } } allprojects { repositories { google() jcenter() } } task clean(type: Delete) { delete rootProject.buildDir }build.gradle(app)apply plugin: 'com.android.application' apply plugin: 'kotlin-android' apply plugin: 'kotlin-android-extensions' android { compileSdkVersion 29 defaultConfig { applicationId "toku.san.myapplication" minSdkVersion 28 targetSdkVersion 29 versionCode 1 versionName "1.0" testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner" } buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } } } apply plugin: 'git-repo' ←これを追加 repositories { git("git@github.com:tokuyama-san/MyLibrary.git", "toku.san.mylibrary:MyLibrarySDK", "master", "repository") ←これを追加 } dependencies { implementation fileTree(dir: 'libs', include: ['*.jar']) implementation"org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version" implementation 'androidx.appcompat:appcompat:1.1.0' implementation 'androidx.core:core-ktx:1.1.0' implementation 'androidx.constraintlayout:constraintlayout:1.1.3' testImplementation 'junit:junit:4.12' androidTestImplementation 'androidx.test.ext:junit:1.1.1' androidTestImplementation 'androidx.test.espresso:espresso-core:3.2.0' implementation 'toku.san.mylibrary:MyLibrarySDK:0.9.0' ←これを追加 }ライブラリの更新方法
ライブラリのリポジトリですること
1.maven.gradleに記載しているバージョン（VersionName）を変更する（例. "0.9.1beta"）
2.ライブラリのルートディレクトリで以下のコマンド
./gradlew uploadArchives3.repository配下に指定したバージョンのファイルがいくつか出来上がるのでGitにコミット＆プッシュする
アプリのリポジトリですること
アプリのbuild.gradleに記載されているdependenciesスコープ内の
ライブラリのバージョン部分を変更する。
implementation 'toku.san.mylibrary:MyLibrarySDK:0.9.0'
↓
implementation 'toku.san.mylibrary:MyLibrarySDK:0.9.1beta'あとはビルドすればOK