2017年08月28日

実践git

Git-Logo-1788C.png

公式サイト:https://git-scm.com/



インストール









1人でgitを使う


準備





基本的な作業



この流れの繰り返し。


リリース作業








複数人でgitを使う


準備






基本的な作業


リモートリポジトリからクローンして、ローカルリポジトリを準備すれば、後は1人でgitを使う流れと同じ。



他のメンバーと作業内容を共有







リリース作業


基本は 1人でgitを使う場合のリリース作業と同じ。





ブランチモデル








困ったときのtips


変更したファイルがたくさんある。ステージするのがたいへん。

  • $ git add .
    "."(ピリオド)を指定するとそのディレクトリ以下の階層すべての変更ファイルがステージの対象となる。

作業ツリー上に、gitで管理してほしくないファイルが存在している。


さっきコミットしたのに、追加を忘れたファイルがあった。


コミットしたコミットメッセージがいまいちだった。書き換えたい。


間違ってステージしてしまった。

  • ステージされているすべてのファイルをもとに戻す場合
    $ git reset HEAD
  • 特定のファイルだけ戻す場合
    $ git reset HEAD <対象ファイルパス>

間違ってコミットした。取り消したい。

  • 1つ前のコミット状態に戻す。ただし、作業ツリー、ステージングエリア上の変更は戻さない。コミットだけ無しにする。
    $ git reset --soft HEAD^

リセット実行したけど、実行前の状態に戻したい。


異なる目的の対応を一気にやってしまった。複数のファイルの変更点がある。分けてコミットしたい。

  • $ git add -p
    "-p" オプションをつけると、ステージする処理をインタラクティブに進める。
    変更ファイルが順に示されるので、コマンド入力でステージする・しないを決定する。コマンドの種類はいくつかあるが、ややこしい操作は無しにして次の操作だけ行えばいい。
    [y]ステージする、[n]ステージしない、[q]操作を中止する。

作業ツリー上の内容が中途半端でまだコミットできないのに、同じ作業ツリー上で、急遽、別の作業を行わないといけなくなった。


細目にコミットしたが、履歴を追うのが大変。まとまりある単位でのコミットにしておけば良かった。マージする前に整理したい。

  • git rebase -i で "squash" を指定してコミットをまとめる。

ブランチを切り替えるの忘れて、コミットしてしまった。

  • まず正しいブランチに切り替える
    $ git checkout <正しいブランチ名>
    コミットIDを使い、間違ったコミットを指定してチェリーピックする。
    $ git cherry-pick &ly;commitID>
    間違ってブランチに戻り、不要なコミットをリセットする。
    $ git checkout <間違ったブランチ名> && git reset --hard HEAD~

違うブランチを削除してしまった。

  • ローカルリポジトリの場合
    reflogで過去の作業から、ブランチ削除の前の状態を確認する。
    復活させたいブランチ名と確認した番号を使い、以下のコマンドを実行する。
    $ git branch <復活させたいブランチ名> HEAD@{確認した番号}
  • リモートリポジトリの場合
    すぐに他のメンバーに確認。リモートリポジトリを触って影響を受けないように連絡と、既に影響を受けてしまった人がいないか確認。
    そのうえで復活操作可能と判断できれば復活させる。すぐの操作が難しいとなればメンバー間で今後について相談する。

    復活手順:
    もしローカルリポジトリにも削除してしまったブランチがなければ、上記手順で復活させる。そのブランチをリモートリポジトリにプッシュする。ただし普通にはプッシュできないので、強制的にプッシュし復活させる。
    $ git push -f <リモートリポジトリ> <復活させるブランチ名>

リモートブランチは他のメンバーに影響を与える可能性が高い
焦って git push -f をしてはダメ。
メンバーに確認して、大丈夫だと確認が取れてから操作すること。

プッシュしたコミットが間違っていたので取り消したい。

  • 基本的にコミットを無かったことにするのはあきらめる。
    リモートブランチは他のメンバーに影響を与える可能性が高いので、コミット履歴を改変しないこと。
    git revert でコミットした歴史は残しつつ、内容だけ差し戻す。
  • もし他メンバーの誰にも影響が出ないことがわかったなら、例外的処置でリモートリポジトリを書き換える。
    まずローカルリポジトリでコミットをリセットする。
    $ git reset --hard HEAD^
    リセットした内容を強制的にプッシュする。
    $ git push -f <リモートリポジトリ> <ブランチ名>

スタッシュした内容を消してしまった。

間違って git stash drop したときや、git stash pop のあとに、うっかり git reset して大事なスタッシュを消してしまった場合。
  • "drop" や "pop" のスタッシュ操作したときに、
    例えば "Dropped refs/stash@{0} (13ce25271878e0763aaaefab44c0b2c52743df51)" と、SHA-1 が示される。これを使って復活させる。
    $ git stash apply <SHA-1>
  • もし、SHA-1 がわからない場合は、
    $ git fsck
    とすると、"dangling commit"(中間ファイルのようなもの)が列挙される。このどれかが消えたスタッシュ。
    上記操作で適用して地道に探してみる。

サーバーの入れ替えがあり、サーバーのアドレスが変わってしまった。


ローカルで1人で作業していたがチーム編成になり、今までの内容をメンバーに展開することになった。






gitの基礎


gitをインストール
gitサーバーのセットアップ
git ブランチについて
git 変更を一時的に退避 stash
git ブランチを合流するマージ
git ブランチを付け替える
git コミット履歴を変更する
git 変更をリセットする
git リモートでの操作
git ファイルの追跡
git リリース準備
git 変更をpatchファイルにする
git コンフリクトに対処する
git 失敗したときの復元


posted by Zorinos at 20:00| Comment(0) | Linux | 更新情報をチェックする

2017年08月11日

100均のクーラーボックスで簡易クーラーを作ってみた

クーラーボックスに保冷剤を入れて、上部から暑い風が入り、下部から冷たい空気が出ていくというもの。

Youtubeで100均ダイソーのクーラーボックスで作るというのを見て、


これに使われているダイソー扇風機、使ってるわ、って思って、
cooler01.jpg
涼しくなるなら作ってみよう。

って思ったんだけど、貧乏性がでてきて
使っている扇風機を奪われるのはちょっとな。。。
そういえば使っていないPCファンがあるけど、これで代わりにならないだろうかと。

で、調べてみたらPCファンで簡易クーラーを作っている人も多いな。できるんじゃないか。







材料


100均ダイソーでクーラーボックスを購入。税抜¥150。
cooler04.jpg
100均で、保冷剤を立てて置くために、まな板たてと、
USB充電ケーブルを購入。
cooler06.jpg
送出口として、ホームセンターでL字型の塩ビパイプを購入。

PCファンのカバー用には、家にあった園芸用の鉢底ネットを使う。
保冷剤も家にあるものを使う。
これでカッターとホットボンドを使って工作する。
あと、テスターはあったほうがいい。


しかし、心配事はある。
  • PCファンを動かすには、USB電源を使おう。楽だから。
  • PCファンは12v電源だけど、USBからは5v電源しかとれない。
  • そもそも5v電源で、このPCファンは回るのだろうか。
  • 回ったとして、十分な風力は得られるのだろうか。



まぁ試してみてみよう。
PCファンはこれ。
cooler02.jpg

80mm角の静音タイプ。
小さくて、静かな。その分、風量も弱い。。。
不安。



製作


まずは、穴をあける場所の位置決め。
風を上から送り込んで、下から送出するのだろうけど、
風量が心配なので、中で溜めて冷たくなった空気が漏れ出すようなイメージでつくることにした。
cooler03.png
加工をクーラーボックスの蓋だけで済むせることで、
簡易クーラーとしてはいまいちだったとしてもボックスとしては再利用しやすいという算段。


念のため、扇風機で風を送りこむことができるようにサイズだけは確認。
cooler04.jpg
蓋の枠にぴったりとはまっているように見えるが、実際には無理矢理押し込んでいる。

では、PCファンを使って穴をあける位置を決める。
cooler05.jpg
80mmサイズでちょうどいい大きさだった。

これに送出口となる場所を塩ビパイプで位置決めする。
あとはカッターで切って穴をあけて納めてみる。
cooler07.jpg


鉢底ネットをファンのサイズにカットして、蓋をすれば完成。
cooler11.jpg


次に、USBケーブルの加工。
cooler08.jpg
MicroUSBコネクタ側をカットして、ケーブルを剥き出す。
テスターで配線を確認。

PCファン側のコネクタの配線は
cooler09.jpg

普通はハンダでつけるけど、
ここでも貧乏性がでて、あとからPCファンとして復帰できるように、
PCファン側は加工せずに、強引にコネクタ側に銅線を差し込みホットボンドで固めた。
cooler10.jpg
見た目はともかく、
簡易クーラーとして使わなくなれば、ホットボンドで固めたところを強引に剥がせば、PCファンとして復帰できる。

USBを挿して電源を入れてみると、PCファンが回った。
が、予想通りに微風。超微風。

とりあえず、保冷剤を納めて、冷気を期待してみる。
cooler12.jpg

冷気が漏れ出してくるという表現がぴったり。

cooler13.jpg


期待通りといえばそうだが、
やっぱりこんなものかと言う達成感を感じない気持ち。
とりあえず、机の脚元において過ごしてみる。
PCの排気の熱を取りこみ、冷気に変換してくれているのか、ちょっと冷えている気がする。

なんか役に立っているかも。


まとめ


さすがに一気に冷やしてくれるという訳にはいかないが、それなりに活躍はしてくれているみたい。
静音ファンが低い電圧で動いているので、回転音がほぼしない。静か。
5v→12vに変換してもっとパワーアップさせて動かそうかと思ったけど、いまのままでもいいかな。
たまにファンが回らないときがあるが、そのときは指でファンを回すと動き出す。初動の力が足りないみたい。いいよ、これぐらいは手で動かすよ。



ラベル:PCパーツ DIY 自作
posted by Zorinos at 20:00| Comment(0) | DIY | 更新情報をチェックする

2017年08月08日

100均材料で 折りたたみできる撮影ボックスを作成

物を撮影するときに光源の位置で、
影が気になったり、反射が気になったり、周囲の映り込みが気になったり、
気になることが多すぎる。

簡易的なもので良いので撮影ボックスが欲しいなぁと常々思っていた。
常時、撮影に勤しむわけではないので、折りたたみできることは必須の要素。



値段も手ごろなので購入しようかなと思っていたところ、
結構、自作している人も多い。
欲しいサイズは小ぶりの撮影ボックスで、自作ならちょうどそれぐらいのサイズ感。
それなら100均で材料そろえて試してみよう。



材料


材料はセリアで購入。
  1. プラダン x 5枚
    box01.jpg
    プラダンと呼ばれる、プラスチック段ボール。カラーボックスのドアに使う目的に販売されているやつが手ごろなサイズで、クリアカラーだったのでちょうど良かった。

  2. 模造紙
    box02.jpg
    とりあえず白色の紙を準備したけど、布でも良いと思うし、色がついた紙とかをつかえば雰囲気がでると思う。

  3. 面ファスナー
    box03.jpg
    折りたためるように作るため、面の固定用に使う。
    どれぐらい使うのかわからなかったので4本分購入してみたけど、使ったのは1本だけだった。

  4. 両面テープ
    プラスチックに使えるやつ。
    家にあるものを使ったけど、プラスチックは不向きって書いてあった。けど、固定できたのでそのまま使っている。

  5. クリップ
    後から必要になった。とりあえず洗濯ばさみで代用した。

  6. その他
    • 瞬間接着剤があったほうがいい
    • カッター
    • 定規
    • カッター使うので、カッターマットまたは傷つかないようにする何か







製図


展開図


真ん中が底面、その上が背面。上面は絵の空きスペースの関係で下に描いた。
box04.jpg


グレーは面と面をくっつけるのりしろ部分。両面テープ等でかためる。
水色はプラダンを直角に当てる箇所。なのでプラダンの厚み3mm幅とっている。ここは瞬間接着剤でつけると良い。普通の接着剤でもいいが固定するのに苦労する。
黄色は前面のフラップになる。
紫は不要な部分。
赤線にカッターで切れ込みを入れ、折る。山折り(鎖線)、谷折り(破線)ある。カッターで切れ込みを入れる面に注意。



底面拡大図


底面を上から見た図。
底面はすべて谷折り。裏側からカットを入れ、内側に向けて折り込む。
折りたためるように2箇所カットし、コの字型にまげている。
裏側にカットを入れるので、作業するために裏側に向けたときには図面と左右逆になることに注意。
box05.jpg





左側面拡大図


上側が背面と接続。右側は底面と接続。
上部の山折り線は、折りたたむときに底面とぶつかる部分を避けるための折りたたみ。
下部のフラップ部分は、くみ上げたときに前面の空いた口を隠すように谷折り。
box06.jpg


右側面拡大図


左側面と対称。
box07.jpg





背面


左右ののりしろは側面との接続部分。山折りで後ろ側に折り込む。側面ののりしろと重なるのでクリップでとめる。
当初は、面ファスナーで引っ付けようと思ったが、思った以上に面ファスナーに厚みがあり、隙間が大きかったのでやめてクリップでとめることにした。
box08.jpg



上面


のりしろ部分は側面、背面を覆うように山折りで折り込む。
側面との接続部分は、面ファスナーでとめる。背面は覆うだけ。
box09.jpg




折りたたんだときの断面


ミリ単位でプラダンをカットしたり、折ったりする技術はないので絵にかいた餅なんだけど、目指す形はこんな断面。
box11.jpg





作業


まずはプラダン5枚を 370mm x 270mm のサイズにカット。
もともとが扉用なので取って部分になる丸い穴がある。そこまでがちょうど370mm。
box10.jpg

多少のずれは気にしない。
もともとミリ単位で正確にカットや折りまげができるわけではないので、正確にカットするという気持ちだけもって作業。

山折り・谷折りを考えて、切れ込み入れる面に注意する。

カッターで切れ込みを入れるときは、プラダンなので、一発で裁断することは無い。なので、あまり気を使わずカッターで切れ込みを入れる。切れ込みを入れたら丁寧に折り曲げる。
プラダンをミリ単位でカットしたり、きれいに折り曲げるのは難しいので、
だいたいの形で組み上げて、干渉する箇所があればカットして整えていく感じで組み上げる。


ピンぼけしてるけど、組み上げた状態。
box12.jpg
クリップがなかったので背面と側面の接続には洗濯ばさみを代用。


模造紙をセット。
模造紙は折って、背面に引っ掛けている。弧を描く感じで垂らすだけ。
bo13.jpg


上面を被せたら完成。
box14.jpg

上面と側面の接続部分は面ファスナーを使っている。
box15.jpg




折りたたみ


  1. 上面を外し、

  2. 左側面を折りたたむ。
    box16.jpg/li>
  3. 右側面を同じように折りたたむ。

  4. 背面を折りたたむ。
    box17.jpg
  5. 最後に上面をのせて、終了。
    box18.jpg


やはり、きっちりとは折りたためないが、邪魔にならないように片づけることが可能な大きさにはなるので十分。





使ってみた


まず撮影ボックス無しの場合、
box19.jpg
影が濃くでてるし、下地の映り込みがわかる。

撮影ボックス有りの場合、
box20.jpg
影が薄い。光源が右側にあるが、左側もきれいに映っている。
下地が白いので映込みが目立たない。






まとめ


撮影ボックスの効果がはっきりとわかって作成してよかった。
ライトは設置してないので、そこは必要に応じて用意することにする。
材料費も両面テープや、接着剤、クリップなどを買ったとしても1000円程度に収まるのでコスパは結構いいと思う。

もし撮影ボックスの設置スペースがあり、折りたたまなくてもいいのであれば、プラダンを適当なサイズにカットして、テープで貼り付けるだけで形になるので、それが一番簡単。


ラベル:自作 100均 カメラ DIY
posted by Zorinos at 20:00| Comment(0) | DIY | 更新情報をチェックする

2017年08月06日

git ブランチモデル git-flow

git のブランチは好きに使って効率よく作業すればいいのだが、好き勝手やり過ぎて効果的に使えなくなると意味がない。特にチームで使うとなると秩序が必要となる。また様々なチームを渡り歩いて作業するようなことになると、行く先々でルールが異なると、ローカルルールに従うことだけで苦労する。

こういった問題を解決するために「ブランチモデル」という管理法が提案されている。
メジャーなのが "git-flow" 。

"git-flow" という言葉は正確には Vincent Driessen 氏が提唱する
A successful Git branching model
(日本語訳 http://qiita.com/homhom44/items/9f13c646fa2619ae63d0)
というブランチモデルをサポートするツール(スクリプト)の名称を指しているが、ここでは「ブランチモデル」として整理する。





中央リポジトリ


git-flow02.png
まず中央リポジトリを準備し、各メンバーの作業はローカルリポジトリで作業する。
中央リポジトリは "origin" とする。リポジトリは自由に名前が付けれるが、gitを使ううえで馴染みが深い名称なので "origin" で統一する。
1人だけの作業であって中央リポジトリを準備し使うことにする。
(1人ならばネットワーク越しではなく、同一マシン上に準備しても良い)


各メンバーのローカルリポジトリを相互にリモートリポジトリとして追加して使っている。
これは、機能開発するうえで1人での単独開発だけではなく、機能の規模によりペアやチームを組んで機能開発にあたることがある。機能開発の途中段階において、中央リポジトリを使って共有するのではなく、各メンバー間でリモートリポジトリとして相互に指定して機能開発を進めることで、中央リポジトリに作業途中のコミットがあがることが避けられる。中央リポジトリはすっきりとした状態で保たれる。
(中央リポジトリ以外に、bareなリポジトリを準備できる場所を準備して、それをリモートリポジトリとして指定して共有して機能開発を進める。bareではないリポジトリを無理矢理に共有すると期待していない動作になるので注意)




定義されているブランチの種類


メインブランチ


git-flow01.png
中央リポジトリには、開発の最初から最後まで、恒久的に存在するブランチが2つ。
  • master
    "master" は gitブランチのデフォルトとしてのブランチ名だが、単にデフォルトだから使うのではなく、重要な役割をもつ名称として "master" が使われる。このブランチは常にリリース可能な安定版が反映される。
    "master" ブランチに直接コミットすることはなく、マージを行うだけのブランチとなる。
  • develop
    普段の開発ではこのブランチが更新される。開発の最新状態となるブランチ。プロジェクト開始時リポジトリを新規作成したときに、まず "master" ブランチから "develop" ブランチを切る。"master" ブランチ同様に、このブランチに直接コミットすることはない。






サポートブランチ


機能開発、不具合修正、リリース準備など、目的を達成するために作成されるブランチ。役割が終わると削除される。各メンバーのローカルリポジトリ上で主に作業されるブランチとなる。
それぞれのブランチには特定の目的があり、名称や、どのブランチから分岐し、どのブランチをマージ対象としなければならないかという厳格なルールがある。
(名称はブランチモデルとして絶対的な定義があるわけではない。自由度があり、プロジェクトごとに決めることができる。)




git-flow03.png
  • 機能ブランチ (feature branches) or トピックブランチ(topic branches)
    機能開発や不具合修正などほとんどの作業で使う。
    ブランチ元develop
    マージ先develop
    ブランチ名ルールfeature/?
    ブランチの存在期間機能ブランチは実装が継続している間は存在し続ける。実装が完了し "develop" ブランチにマージされるか、仕様ドロップで打ち切られるまで存在する。

    機能ブランチはメンバーのローカルリポジトリのみに存在し、中央リポジトリ "origin" には存在しない。

    機能ブランチを新たに作成するには、"develop" ブランチから分岐する。
    $ git checkout -b myfeature develop

    機能開発が完了したら "develop" ブランチへマージする。
    マージするときは --no-ff オプションを指定し、fast-­forwadマージが可能の場合であっても常にマージコミットを作成する。履歴に機能ブランチが存在したことの情報と、機能の追加のために行った作業をまとめて残しておける。
    $ git checkout develop   :"develop" ブランチへ切り替える
    $ git merge --no-ff feature/myapp :non-fast-forwardマージを指定

    機能開発が終了し、"develop" ブランチへマージしたら、役目を終えたブランチは削除する。
    $ git branch -d feature/myapp




git-flow04.png
  • リリースブランチ(release branches)
    製品をリリースするために使う。リリーステストで見つかった不具合修正や、リリースバージョンを付けたり、リリースのための関連作業を行う。
    ブランチ元develop
    マージ先develop と master
    ブランチ名ルールrelease/?
    ブランチの存在期間"develop" ブランチの状態が新しくリリースさせても良い状態になった時にブランチを切る。リリースが完全に出荷されるまでブランチは存在し続ける。

    リリースブランチを切り、リリース作業はそのブランチで専念することで、"develop" ブランチはリリースを気にすることなく作業を進めることができる。タイミング悪く、もし、今からのリリースに含まれない機能を "develop" ブランチへマージしようと思うのであれば、リリースブランチが切られるまで待ってからマージすること。

    リリースブランチを新たに作成するには、"develop" ブランチから分岐する。
    $ git checkout -b release/1.1 develop

    リリース作業中に見つかった不具合は、リリースブランチに対して適用する。
    これはリリース完了してから、まとめて "develop" ブランチへ反映するため。

    リリースできる状態になったら、"master" ブランチへマージし、タグも設定する。
    $ git checkout master   :"master" ブランチへ切り替える
    $ git merge --no-ff release/1.1 :non-fast-forwardマージを指定
    $ git tag -a 1.1 :注釈コメントも付ける

    リリースブランチで修正した内容を "develop" ブランチへも反映する。このときコンフリクトが起こる可能性が高いので注意してマージする。
    $ git checkout develop   :"develop" ブランチへ切り替える
    $ git merge --no-ff release/1.1 :non-fast-forwardマージを指定

    リリースが完了し、"master"・"develop" ブランチへのマージも完了したら、役目を終えたブランチは削除する。
    $ git branch -d release/1.1




git-flow05.png
  • Hotfixブランチ(hotfix branches)
    製品リリースした後で、重大な不具合が見つかり緊急対応が必要な場合に使う。次のリリースのためのブランチという意味でリリースブランチと似ているが、意図的に発生するものではない。
    ブランチ元master
    マージ先develop と master
    ブランチ名ルールhotfix/?
    ブランチの存在期間リリース後に重大な不具合が見つかり、緊急で対策を行いたい場合にブランチを切る。次のリリースが完全に出荷されるまでブランチは存在し続ける。

    "master" ブランチから分岐することで、"develop" ブランチの状況を気にせず、即座に緊急対応が可能。逆に担当者が緊急対応中でも他メンバーは "develop" ブランチで開発作業を継続できる。
    不具合修正とリリースバージョンを付け、その他リリースを行うための関連作業を行うという点で、リリースブランチと同じ。


    Hofixブランチは "master" ブランチから作成される。
    $ git checkout -b hotfix/1.2.1 master

    リリースできる状態になったら、"master" ブランチへマージし、タグも設定する。
    $ git checkout master   :"master" ブランチへ切り替える
    $ git merge --no-ff hotfix/1.2.1 :non-fast-forwardマージを指定
    $ git tag -a 1.2.1 :注釈コメントも付ける

    Hofixブランチで修正した内容を "develop" ブランチへも反映する。
    もし、このタイミングで進行中のリリースブランチがあれば、例外的にリリースブランチへマージする。これは、リリースブランチが完了すれば最終的に "develop" ブランチにも Hotfixブランチの不具合修正内容は反映されることになるから。ただしリリースブランチ完了まで待てない事情があれば、"develop" ブランチへマージしても問題はない。
    $ git checkout develop   :"develop" ブランチへ切り替える
    $ git merge --no-ff hotfix/1.2.1 :non-fast-forwardマージを指定

    リリースが完了し、"master"・"develop" ブランチへのマージも完了したら、役目を終えたブランチは削除する。
    $ git branch -d hotfix/1.2.1




git-flow06.png
  • (オプション)Supportブランチ(support branches)
    必須ではないが、旧バージョンをサポートし続けなければいけない場合に使う。旧バージョンの保守とリリースを行う。
    ブランチ元master
    マージ先develop
    ブランチ名ルールsupport/?
    ブランチの存在期間旧バージョンをサポートする必要が発生した場合にブランチを切る。以降はサポートが終了するまで、恒久的に存在する。



    Supportブランチは "master" ブランチからタグを指定し作成する。合わせて Supportブランチ用の Hotfixブランチを作成する。
    $ git checkout -b support/1.x 1.2  :Supportブランチを作成し切り替える
    $ git checkout -b hotfix/1.2.1

    Hotfixブランチで不具合修正を行い、リリースできる状態になったら、Supportブランチへマージし、タグも設定する。
    $ git checkout support/1.x   :Supportブランチへ切り替える
    $ git merge --no-ff hotfix/1.2.1 :non-fast-forwardマージを指定
    $ git tag -a 1.2.1 :注釈コメントも付ける

    旧バージョンのサポート用リリースが完了したら、役目を終えた Hotfixブランチは削除する。
    $ git branch -d hotfix/1.2.1


    混乱を避けるために、原則として、Supportブランチや、そこから分岐する Hotfixブランチを他のブランチへマージすることは避ける。

    最新リリースに対しても急ぎ不具合修正を反映する場合は、新たにHotfixブランチを作成する。
    $ git checkout -b hotfix/2.0.1 master

    (最新リリースに対して即時対応が必要なければ、"develop" ブランチから機能ブランチを分岐し、不具合修正として対応する。Hotfixブランチとは違うが対応の仕方は同じこと。)


    リリースできる状態になったら、"master" ブランチと "develop" ブランチへマージし、タグも設定する。
    $ git checkout master   :"master" ブランチへ切り替える
    $ git merge --no-ff hotfix/2.0.1 :non-fast-forwardマージを指定
    $ git tag -a 2.0.1 :注釈コメントも付ける
    $ git checkout develop :"develop" ブランチへ切り替える
    $ git merge --no-ff hotfix/2.0.1 :non-fast-forwardマージを指定

    リリースが完了したら、役目を終えたブランチは削除する。
    $ git branch -d hotfix/2.0.1








git-flow インストール


ここではマニュアルでインストールしてみる(nvie版)。
(git flow wiki:Installing git-flow manually

git-flow を github から clone する。リポジトリを用意する場所に移動してから実行。

$ cd ~/Downloads/gitflow
$ git clone --recursive git://github.com/nvie/gitflow.git



ツール(スクリプト)をインストール(コピー)する。
インストール先は、デフォルトは "/usr/local/bin"

$ sudo bash gitflow/contrib/gitflow-installer.sh

### gitflow no-make installer ###
Installing git-flow to /usr/local/bin
Using existing repo: gitflow
Submodules look up to date
'gitflow/git-flow' -> '/usr/local/bin/git-flow'
'gitflow/git-flow-init' -> '/usr/local/bin/git-flow-init'
'gitflow/git-flow-feature' -> '/usr/local/bin/git-flow-feature'
'gitflow/git-flow-hotfix' -> '/usr/local/bin/git-flow-hotfix'
'gitflow/git-flow-release' -> '/usr/local/bin/git-flow-release'
'gitflow/git-flow-support' -> '/usr/local/bin/git-flow-support'
'gitflow/git-flow-version' -> '/usr/local/bin/git-flow-version'
'gitflow/gitflow-common' -> '/usr/local/bin/gitflow-common'
'gitflow/gitflow-shFlags' -> '/usr/local/bin/gitflow-shFlags'




アンインストールする場合は、clone を実行したディレクトリから以下を実行する。

$ sudo bash gitflow/contrib/gitflow-installer.sh uninstall

### gitflow no-make installer ###
Uninstalling git-flow from /usr/local/bin
rm -vf /usr/local/bin/git-flow-init
'/usr/local/bin/git-flow-init' を削除しました
rm -vf /usr/local/bin/git-flow-feature
'/usr/local/bin/git-flow-feature' を削除しました
rm -vf /usr/local/bin/git-flow-hotfix
'/usr/local/bin/git-flow-hotfix' を削除しました
rm -vf /usr/local/bin/git-flow-release
'/usr/local/bin/git-flow-release' を削除しました
rm -vf /usr/local/bin/git-flow-support
'/usr/local/bin/git-flow-support' を削除しました
rm -vf /usr/local/bin/git-flow-version
'/usr/local/bin/git-flow-version' を削除しました
rm -vf /usr/local/bin/gitflow-common
'/usr/local/bin/gitflow-common' を削除しました
rm -vf /usr/local/bin/gitflow-shFlags
'/usr/local/bin/gitflow-shFlags' を削除しました
rm -vf /usr/local/bin/git-flow
'/usr/local/bin/git-flow' を削除しました






Ubuntuでは、apt管理から git-flow をインストールするとAVH版がインストールされる。

$ sudo apt-get install git-flow

基本は同じだが、こちらは機能が拡張されている。大は小を兼ねるの方針でAVH版を入れておけば問題ない。ここでは話が広がり過ぎるのでベースとなるnvie版を入れた。





git-flow を使ってみる


git コマンドの代わりに、git flow コマンドを使う。git コマンドもいつも通りに使える。git flow を使うことで、git-flow ルールを強制することができる。

リポジトリの初期化


各ブランチとタグの名称を指定するが、基本的にデフォルトのままでよいので、そのままEnterキーを押して進めれば良い。

$ git flow init

Initialized empty Git repository in ********************/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []



ブランチの状態を確認してみる。
$ git branch
* develop
master

"master" ブランチと "develop" ブランチが作成され、"develop" ブランチがチェックアウトされた状態となっている。


もし、初期化を修正したかったら、-f オプションを使う。

$ git flow init -f


これで再度初期設定が実行される。



中央リポジトリへ反映


中央リポジトリ となるリモートリポジトリを準備する。
ローカルリポジトリに、中央リポジトリ "origin" を設定して、プッシュする。

$ git remote add origin <リモートリポジトリのアドレス>
$ git push --all


ブランチの状態を確認してみる。
$ git branch -a
* develop
master
remotes/origin/develop
remotes/origin/master

リモート追跡ブランチも設定できた。




各メンバーの準備


中央リポジトリからクローンする。

$ git clone <リモートリポジトリのアドレス>


単にクローンしただけななおで、まだ "git-flow" の設定が紐づけられていない。
各メンバーのマシンにおいても初期設定を行う。これも git flow init でいける。注意するのは、プロジェクト内で用いるブランチ名はそろえておくこと。

$ git flow init

Initialized empty Git repository in ********************/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []


追跡ブランチを確認してみる。
$ git branch -vv
* develop 9790466 [origin/develop] Initial commit
master 9790466 [origin/master] Initial commit

ローカルリポジトリの各ブランチにも、ちゃんと上流ブランチが設定されている。これで "git-flow" を使う準備ができた。


作業で使うブランチの種類は以下。
  • feature :機能ブランチ
  • release :リリースブランチ
  • hotfix :Hotfixブランチ
  • support :Supportブランチ

作業の開始


どのブランチでも基本的な流れは同じ。例として、機能ブランチを作成する。

$ git flow feature start app1

$ git branch
develop
* feature/app1
master

"feature/app1" ブランチが作成され、チェックアウトされた状態になった。


このブランチで作業を行う。
ブランチ操作は、通常のgitコマンドを使えばよい。



作業の終了


作業が終了したらマージする。git-flow に限ったことではないが、マージする前にスカッシュやリベースでコミットの内容を整理しておくと後から履歴を見返したときにわかり易くなるのでおススメ。

$ git flow feature finish app1


マージコミットメッセージを入力するエディタが起動するので、メッセージを入れる。

ブランチを確認してみる。
$ git branch
* develop
master

"feature/app1" ブランチが削除され、"develop" ブランチがチェックアウトされた状態になった。




develop ブランチを中央リポジトリへ反映


develop ブランチを更新したので、中央リポジトリへ反映する。

$ git push --all



基本的に、作業開始し、作業終了でマージし、中央リポジトリへプッシュするというのが流れ。
コンフリクトなど問題が発生した場合は、git-flow のスクリプトも止まるので、その場合は残りは手作業となる。git-flow のモデルを理解していないと問題対処後に何をすべきかがわからないので、ブランチモデルを知らなくても使えるというツールではないことに注意。






まとめ


"git-flow" で理解・管理しておけば多くの場面で、ブランチ管理の混乱は避けられ、途中参加したメンバーもスムーズに作業に集中できると思う。また "git-flow" と言っても、上で記述したブランチ以外にも、機能ブランチとは分けて、bugfixブランチを用意する場合もある。このシンプルな形で進めればいいのだけど、このモデルをベースにして、うまくやってくれ、ということだと思う。多少の足し引きがあっても、考え方が沿っていれば理解は早い。後はプロジェクト、チームに沿ったやり方を毎回、模索するしかないと思う。




gitをインストール
gitサーバーのセットアップ
git ブランチについて
git 変更を一時的に退避 stash
git ブランチを合流するマージ
git ブランチを付け替える
git コミット履歴を変更する
git 変更をリセットする
git リモートでの操作
git ファイルの追跡
git リリース準備
git リモートブランチを追加
git チェックアウトをもっと便利に使う
git プロジェクトの構成
git 変更をpatchファイルにする
git コンフリクトに対処する
git 失敗したときの復元
posted by Zorinos at 20:00| Comment(0) | Linux | 更新情報をチェックする

2017年08月05日

git 失敗したときの復元

コミットしたけど間違っていたので無かったことにしたいと思えば git reset が使うことで履歴を変更できる。きれいさっぱり消して戻してくれる。
が、もしリセットする箇所を間違えたらどうなるのか?

このようなコミット履歴があった場合に、
$ git log --oneline
827142f modified2 a.txt b.txt
e379d74 modified a.txt b.txt
6c5004e modified a.txt d.txt
069d76c Add file :d.txt
4bfcd75 modified c.txt
3f062b7 modified b.txt
9925985 modified a.txt
d79bc0b Add files


間違ってコミットしたので、"HEAD^" で1つ前に戻ることにした。
$ git reset --hard HEAD^^
HEAD is now at 6c5004e modified a.txt d.txt

操作をミスで、"HEAD^^" で戻し過ぎてしまった!
reset --hard なのできれいに無くなってしまった!!
途方に暮れてしまう場面だが、gitにはこんなときでも復旧手段がある。




reflog(参照ログ)で復旧


$ git reflog


"reflog" はすべての変更を記録してくれている。
$ git reflog
6c5004e HEAD@{0}: reset: moving to HEAD^^
827142f HEAD@{1}: commit: modified2 a.txt b.txt
e379d74 HEAD@{2}: commit: modified a.txt b.txt
6c5004e HEAD@{3}: commit: modified a.txt d.txt
069d76c HEAD@{4}: commit: Add file :d.txt
4bfcd75 HEAD@{5}: commit: modified c.txt
3f062b7 HEAD@{6}: commit: modified b.txt
9925985 HEAD@{7}: commit: modified a.txt
d79bc0b HEAD@{8}: commit (initial): Add files


今回であれば git reset --hard HEAD^^ の前に戻れば復旧できるので、"HEAD@{1}" にリセットする。

$ git reset --hard HEAD@{1}


コミット履歴を確認してみる。
$ git log --oneline
827142f modified2 a.txt b.txt
e379d74 modified a.txt b.txt
6c5004e modified a.txt d.txt
069d76c Add file :d.txt
4bfcd75 modified c.txt
3f062b7 modified b.txt
9925985 modified a.txt
d79bc0b Add files

途方に暮れてしまう前の状態に巻き戻すことができている!


git reset だけではなく、git rebaseブランチの付け替えに失敗したときや、履歴の変更したときも使える。あとは、"detached HEAD" 状態に気づかずにコミットした後で、ブランチを切り替えた場合に、見えなくなってしまったコミットIDを探してチェリーピックすれば、失われたコミットをサルベージすることができる。




まとめ


作業ツリー上にしか存在していなかったデータなどはコミットしていなければ戻すことはできないが、直近の内容でコミットさえしてあれば、データがどこかに残っているので、目の前からデータが消えるようなことになってもリカバリできる。ただ、過去にさかのぼるのも限界があるので、間違いには早めに気づいて、気づいたらすぐに対処するのが良い。






gitをインストール
gitサーバーのセットアップ
git ブランチについて
git 変更を一時的に退避 stash
git ブランチを合流するマージ
git ブランチを付け替える
git コミット履歴を変更する
git 変更をリセットする
git リモートでの操作
git ファイルの追跡
git リリース準備
git リモートブランチを追加
git チェックアウトをもっと便利に使う
git プロジェクトの構成
git 変更をpatchファイルにする
git コンフリクトに対処する
posted by Zorinos at 20:00| Comment(0) | Linux | 更新情報をチェックする