この記事は Git Advent Calendar 2019 10日目の記事です。

はじめに

最近、gitのhooksでpre-commitを使い始めた
なかなか良いことが多かったので書いてみる

モチベーション

• PHPという自由な言語なので、他人のコードを読む時に苦しみたくない
• コードレビューの時にスペースがないとかくだらないことをチェックしたくない
• シンタックスエラーを事前に検知したい

やったこと

• php -lでのシンタックスチェック
• phpmdでのお作法チェック
• php-cs-fixerでの自動修正

上記3点をcommit時にチェック。違反や引っかかることがあった時に、commitできないという結構厳しめのルール設定

php -lについて

• phpのシンタックスエラーをチェックしてくれる

<?php

$a = "test"
echo $a;

?>

$ php -l file.php

Parse error: syntax error, unexpected 'echo' (T_ECHO) in test.php on line 5
Errors parsing test.php

このようにあらかじめエラーを見つけてくれる

phpmdについて

公式

インストール方法

$ brew install phpmd

$ phpmd --version
PHPMD 2.7.0snapshot201907302127

このように表示されればOK

使用法

• 使っていない変数のチェック
• 長すぎる変数名
• 複雑すぎるクラス

などなど様々なバグの温床をあらかじめ見つけてくれる

使い方は以下のように2通り

$ phpmd file.php text unusedcode,codesize,naming

or

$ phpmd file.php text phpmd-ruleset.xml

phpmdコマンドの後ろにファイル名またはディレクトリ、レポートフォーマット（text or xml）、使用ルールまたはルール記述xmlファイルの指定という風に書く。

ルールセットについて

上記のようにxmlファイルでルールを設定することができる。

phpmd-ruleset.xml

<?xml version="1.0"?>
<ruleset name="My first PHPMD rule set"
        xmlns="http://pmd.sf.net/ruleset/1.0.0"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0
                    http://pmd.sf.net/ruleset_xml_schema.xsd"
        xsi:noNamespaceSchemaLocation="
                    http://pmd.sf.net/ruleset_xml_schema.xsd">
<description>
    My custom rule set that checks my code...
</description>

    <rule ref="rulesets/codesize.xml">
        <exclude name="CyclomaticComplexity" />
    </rule>
    <rule ref="rulesets/controversial.xml" />
    <rule ref="rulesets/unusedcode.xml" />
    <rule ref="rulesets/naming.xml">
        <exclude name="ShortVariable" />
        <exclude name="ShortMethodName" />
    </rule>
    <rule ref="rulesets/design.xml">
        <exclude name="CouplingBetweenObjects" />
    </rule>
</ruleset>

このように、<rule>タグで使用ルールを指定。<exclude>タグでルール内の細かいルールの除外をする。

例えば、

<rule ref="rulesets/naming.xml">
    <exclude name="ShortVariable" />
    <exclude name="ShortMethodName" />
</rule>

この場合、ネーミングに関するルールを使用するが、短すぎる(3文字以内)の変数名は引っかかるというルールを除外している。

php-cs-fixerについて

インストール方法

// composerのあるディレクトリに移動
$ cd path/to/your/project

$ composer install

$ ./vendor/bin/php-cs-fixer --version

PHP CS Fixer 2.16.0 Yellow Bird by Fabien Potencier and Dariusz Ruminski

こうなればOK。

使い方

$ ./vendor/bin/php-cs-fixer fix file.php

このようにすると、これが

<?php

$a="test";
echo $a

?>

こうなる

<?php

$a = "test";
echo $a;

これでコードの統一性がある程度出るし、変な指摘をしないで済む。

ルールについて

.php_cs.distというファイルで設定できる

<?php

return PhpCsFixer\Config::create()
    ->setRiskyAllowed(true)
    ->setRules([
        '@PSR2' => true, //基準となるルールの設定
        'array_syntax' => ['syntax' => 'short'], //配列の書き方について
        'global_namespace_import' => ['import_classes' => true, 'import_constants' => true, 'import_functions' => true],  //namespaceの書き方について
        'concat_space' => ['spacing' => 'one'] //文字列連結の際のスペースについて
    ])
    ->setFinder(PhpCsFixer\Finder::create()
        ->exclude('vendor')
        ->in(__DIR__)
    );

これ以外にもこれを使えば便利に比較することができる。

pre-commitの設定

$ cd path/to/your/project/.git/hooks

$ touch pre-commit

$ vim pre-commit

#!/bin/sh
against=HEAD

IS_ERROR=0

for FILE in `git diff-index --name-status $against -- | grep -E '^[AUM].*\.php$'| cut -c3-`; do
    if php -l $FILE; then
        ./vendor/bin/php-cs-fixer fix $FILE
        git add $FILE

        if ! phpmd $FILE text phpmd-ruleset.xml; then
            IS_ERROR=1
        fi
    else
        IS_ERROR=1
    fi
done
exit $IS_ERROR

.phpファイルのみだけがチェック対象。

導入後

• コードレビューでクリティカルな指摘に集中できるようになった
• コーディングスタイルが整うようになり、可読性が上がった
• 潜在的なバグが減らせた（と思ってる）
• 一度にcommitするとしんどいからcommit粒度が細かくなり、振り返りやすくなった

良いことだらけ。
ぜひ良いコミットライフを！

つい先月，自分のgithubアカウントで技術ポートフォリオを作成した．→　tackkyのポートフォリオ
どうしてgitもhtmlも慣れていないのに作ろうと思ったのか，その辺の話も含めて記事にする．

技術ポートフォリオは何に役立つ？

1. 就活で使える

1. 逆求人

これが一番大きい. 特に最近IT系の就活では逆求人(企業様の方から連絡が来る就活)で，まず自分の情報を見ていただく．

例えば，

• 研究室での研究内容
• 資格，その他技術的にやってきたこと

など．この場合，研究内容だけ突き詰めて研究している方ならそこを詳しく書けばいいけれど，私などのようにいろんな技術をつまみ食いしているような人には不利になる．githubで公開リポジトリーとしてアップするという手もあるけれど，やはり就活では技術に詳しくない人事の方も見ているので，見た目にも綺麗なwebページが一番企業様へのインパクトは大きい．

2. エントリーシート

このような目的で作成されたポートフォリオは，エントリーシートの作成にも役立つ．
研究内容にも言及していれば，そのポートフォリオ記事を参考に書くことができるし，アピールポイントにこのページのURLを貼ることができる．(後たまに，技術ポートフォリオがあれば教えてくださいみたいな欄があることがある)

2. 勉強になる

最後に，HTMLとCSSを使うので何より勉強になる．私は研究室や講義でHTMLは兎も角CSSは使用したことはないけれど，技術ポートフォリオを作ることはHTMLとCSSの使用経験につながる．

技術的観点から

GitHub

技術者になる者，Github含め，Gitは使えるようになった方がいい．私は研究を他の人と共同でやっていないので研究室としてgitを使用することはないけれど，バージョン管理システムとして少し前から使い始めた．特に共有する相手がいなくてもgitはおすすめ．よく考えなくてもgitは バージョン管理システムである．私が最近使用しているgitの使い道が参考になるかもしれない．

• 理由１　論文を書くときにも使える．
  
  参考URL：ライトに知りたい人はこちら ，しっかり読みたい人はこちら

  ナウいヤングは論文執筆にGitHubを使う
  まず、学会や学校などのテンプレートを導入して正しくコンパイルされる状態にしたものをfirst commitとしてmasterブランチにコミットします。
  次にmasterから1stブランチを切って、GitHub上でmasterブランチにPull Requestを送ります。
  PRを送ったら、1stブランチでガリガリ初稿を書いていきます。コミットの粒度は小節毎だったり段落ごとだったりしますが、これは執筆が進んでいくと変わっていくと思います。後半になると修正箇所も少なくなるので「○○先生添削分修正」などとふわっとしてきます。
  添削の依頼をして返ってきたら、1stブランチをmasterにマージします。そして2ndブランチを切ってPRを送って……の繰り返しです。

• 理由２　スライド管理にも使える．
  様々な版(学会用，卒業発表用等)とわけることができる．次のページがわかりやすすぎるので説明は割愛．
  
  参考URL：ここのページからスライド管理するようになった

HTMLとCSS

…ざっくり仕組み使えるようになりたいなって思ってた，それだけです．講義で扱うのはHTMLだけなのでやっぱり心寂しい．

技術ポートフォリオの作り方

作ってみた流れ．

1.githubでページを作る

GitHub Pagesというサービスがある．これは，Githubに登録したリポジトリーをwebページとして公開することができるGitHubのサービスである．settingにgithub pagesの項目があるのでそこでソースをマスターブランチに登録するだけである．とりあえずhello worldとでも書いたindex.htmlを用意して公開すればいい．

一応：github pagesによる静的サービス公開方法

2.サンプルページを探してくる

結構フリーでHTMLとCSSのソースは落ちている．特にtemplate free engineer portfolioとでも検索すれば，ごまんとフリーテンプレートが見つかる．私は以下のサイトから見つけてきた．(確か．)
50 free portfolio website templates 2019

3.自分仕様に変更する

後はダウンロードしたデータを自分仕様にカスタマイズするだけだ．先のテンプレートサイト等には結構な量のデータがあるので，私のような初心者エンジニアにはいらない部分が多すぎる．なので「いらない部分を削る」作業が必要になる．これには，どこからどこまで削っても問題なく動作するのか判断するために，HTMLの構造を理解している必要がある．CSSは色のテイストや配置などを変えたくなってから触る方が楽なのでとりあえず置いておいて，HTML→CSSの順でカスタマイズするのがおすすめ．

おめでとう！

ここまでのプロセスでやっと技術ポートフォリオをつくることができる．新しいことに取り組むことがあれば，どんどん追加して素晴らしいポートフォリオにしよう．

参考サイト

エンジニア向けのポートフォリオサイトまとめ
ポートフォリオをGitHub で公開する

本稿は Git Advent Calendar 2019 の12日目の記事です。
昨日の記事は @miiina016 さんによる ブランチを切ってinitialコミットまでするalias でした。

概要

こんにちは。とつぜんですが、みなさまは GitHub で以下のようなものを見かけませんでしょうか。

↓こんなのとか

↓こんなのとか

※画像は Laravel先生の公式リポジトリ からお借りしました。

なんというかこんな風にバージョン6.5.2とか書かれると プロっぽさ というか 製品感がある というか。とにかく 見た目カッチョイイ ですよね(語彙力

これっていったいどうやってるんだろうと思って少し調べてみたところ、実はごく簡単な方法で実現ができるということがわかりました。そんなわけで今日はその方法を紹介してみたいとおもいます。

適当なリポジトリをつくります

単に私が検証用のリポジトリを用意しているだけなので、ここは読み飛ばしてもらってOKですｗ
下記は特になんの変哲もないリポジトリです。

tagをつけます

v1.0 という名前のタグを付けてリモートへ push します。

$ git tag -a v1.0 -m 'version 1.0'
$ git push origin v1.0
Counting objects: 1, done.
Writing objects: 100% (1/1), 162 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To https://github.com/Jpsern/test-product.git
 * [new tag]         v1.0 -> v1.0

おや？ release のようすが・・・

さきほどまではなかった release の数字が0から1に増えてますね。

クリックしてみるとこんなかんじです。

おお、バージョンがつきましたね。

しかし、もう少しなにかが足りない

さっき見た Laravel のリポジトリと比べると何かまだ見た目が寂しいですね。
ここからが Release 機能の出番です。使い方は簡単です。

1. Draft a new release をクリックします

2. 必要な情報を入力します

例えばこんなかんじです。一番上には先ほど作ったタグの名前を入れます。2つめはタイトルです。一番下のテキストエリアはリリース内容の詳細です。

入力が終わったら Publish release を押します。

すると・・・？

おお、なんということでしょう・・・！(古い)
冒頭でお見せしました Laravel の公式リポジトリと同じようなかんじになりましたね

ちなみに

下記の入力フォームのキャプチャを見ていただくと、Choose an existing tag, or create a new tag on publish とタグの入力フォームのそばに書かれています。

Release の登録時に存在しない tag の名前を指定すると、tag の生成も行います。なので、実は GitHub 上ですべて完結することも可能です。タグの名前を入力すると、そのタグが既に存在するかどうかメッセージも出してくれるので、こちらのほうが作業効率もよかったりします。

ただ、今回は tag の追加と、Release の編集を分けて説明したかったので前述までのような形をとりました。なので慣れている人はGitHub側の Release 機能でタグの追加からRelease編集までまとめて行うと良いのではないかと思います。

追記

@munieru_jp さんから、さらにプロっぽく見せることができるナイスなアドバイスをいただきましたので追記します。

バージョン表記は セマンティックバージョニング にしたがって行うようにすると、よりプロっぽさが増します。

細かい話は前述のリンク先を見てください。
超おおざっぱに説明しますと、以下の書式でバージョンを表記することです。必ず3ケタで表記します。

メジャー番号.マイナー番号.パッチ番号

例：1.0.0、1.1.0、など

感想

ということで味気なかった私のテスト用リポジトリでさえ少し立派に見えるようになりましたｗ
みなさまも制作されたソフトウェア等を GitHub で管理する際には git tag や、GitHub の Release 機能を使うと、それだけでちょっと見た目がいいかんじになるのでテンションが上がるとおもいます。気が向いた方はぜひ試してみてください

お世話になった参考リンク様

• Git - Tagging
• Creating releases - GitHub Help
• git tagの使い方まとめ - Qiita
• GitHubのリリース機能を使う - Qiita

スタッシュしたくないファイルも入れて、間違えてスタッシュしてしまった場合にそれを除いたファイルのみ取り出す方法の備忘録。

SourceTreeではうまくできないので、コマンドを使用する。

現在スタッシュしているリストを表示する

$ git stash list

結果は、こんな感じ

stash@{0}: On branch/sample1: スタッシュしてみた1
stash@{1}: On branch/sample2: スタッシュしてみた2
stash@{2}: On branch/sample3: スタッシュしてみた3

取り出したいファイルのあるスタッシュの番号を指定して、その中の一部ファイルを取り出す

スタッシュリストの番号を指定して、取り出したい中身のファイル名を入れるだけ
ファイルを取り出すだけなので、スタッシュは消えない

$ git checkout stash@{1} pc/hoge/sample.html

おまけ

スタッシュの中身の差分を確認したいとき

$ git diff stash@{1}

.git/configを以下のように編集する。USERNAME/PASSWORDはgithubのユーザー名／パスワード。

[remote "origin"]
     url = https://USERNAME:PASSWORD@github.com/xxxx.git

gitoliteをインストールしてリポジトリ管理をする。

環境
・CentOS7

準備
・自分の公開鍵を取得
・config作成(初回だけ)
　C:\Users\PCXXXXXX.ssh
　　⇒config中身
　　　Host gitolite
　　　HostName gitサーバー
　　　IdentityFile 自分の鍵
　　　user ユーザー名
　　　port ポート番号

・ローカル環境にGitをインストール
※今回は自分が管理者となって鍵を管理します

gitoliteとは

Gitで共有リポジトリのユーザー管理やアクセス管理を行えるツールのこと。
sshの鍵を使用してユーザーを管理します。
※GitHubで公開している。

インストール

既にCentOS上にGitをインストールしていたため
Githubに公開されているgitoliteをクローンします。

# git clone git://github.com/sitaramc/gitolite
# gitolite/install -ln ~/bin

※gitoliteをセットアップする前に自分の鍵(管理者)をサーバーに移動させておくこと！

# gitolite setup -pk 管理者.pub   //セットアップコマンド

/home/git/repositoriesにgitolite-admin.gitとtesting.gitが作成されたのを確認。
gitoliteはこのgitolite-admin.gitを使用してアカウント、リポジトリ管理していきます。

アカウント追加方法

※ローカル環境上
サーバー上で行ってしまってプチパニックになりました。
今回はGit Bashを使用しています。

①ローカルにクローンします。

# git clone ssh://root@gitサーバー/home/git/repositories/gitolite-admin.git

②ディレクトリ移動して確認

# cd gitolite-admin

③keydirに自分の鍵が有ったら管理したい人の鍵を入れていく（add,commit）
※confで管理したい人が参照できるリポジトリを指定

# git add keydir/管理したい人の鍵.pub
# git commit keydir/管理したい人の鍵.pub conf/gitolite.conf 

neovim に設定

git config --global core.editor nvim

こんな状況に出くわした

リポジトリがでかすぎて私の激遅回線ではクローンするのに1日かかってしまう！
※イメージ

今回はこのリポジトリ下から2番目のコミットFirst Commit(e24b3ba0f2d9d367d4758ccfafa4aef0e90b804a)が欲しいのだ

実験

当然、クローンしていないので

git checkout e24b3ba0f2d9d367d4758ccfafa4aef0e90b804a

などとはできない。
そして、

git fetch origin e24b3ba0f2d9d367d4758ccfafa4aef0e90b804a:refs/remotes/origin/template

などとしても、

error: Server does not allow request for unadvertised object e24b3ba0f2d9d367d4758ccfafa4aef0e90b804a

と怒られてしまう

結論

Web上からタグを作ってしまおう ¹

方法

タグ画面から

New tagを押して

Tag nameは適当、Create FromにコミットIDを打ち込んで

Create tagを押す

あとは
git initなどでリポジトリを作り、git remote set-url origin <URL>などでリモートを設定後、
タグ名でフェッチできる

git fetch origin template:refs/remotes/origin/template

あとはチェックアウトするだけ

git checkout -b template refs/tags/template

---

1. 書き込み権限がないリポジトリの場合はフォークしましょう ↩