2014年04月02日

SourceTreeの日本語版 2014

Git: SourceTreeの日本語版 2014
GitのGUIクライアント「SourceTree」が日本語化されました。
http://www.forest.impress.co.jp/docs/news/20140130_633112.html

ここで試用した時は、v1.1.1の英語版の時で、それからいろいろ改良が進んだようです。
(今回はv1.4.1)
http://avr.paslog.jp/article/2682692.html

ちなみにgithubにpull requestする時は「SmartGit」を使っています。

まだ、全然試用できてないけどSoureTreeの注目ポイント、
(1) Stashの中身が閲覧できる。
    これができるGUIは初めて見た。(^^)/ (^^)/
    ポイント高い。
    TortoiseHGのShelve機能と比べると足もとにも及ばないものの、:D
    今後の改良に期待したい。
(2) hunk(ブロック)単位のステージ、コミットが容易になった。 (^^)/(^^)/
    以前より操作性が格段に向上している模様。

ということで、英語版のSmartGitに慣れてしまったのでアレだけど、
将来、SourceTreeはGit入門GUIの決定版になる可能性があると思われます。

注意ポイントはLinux版がない点。 orz

* 注意ポイント
ほんのちょっとつついた感想。
    (1) コミットのやりなおし。
    コミットのUndo(やり直し)ができなさそう。 orz
        打ち消しコミットではちょっと orz
        これは、戻したい位置をコミットグラフ上でポイントして
        「リセット」を使えばできる様だ。
    (2) 以前開いて、閉じたリポジトリを記憶していない。orz
        閉じなければいいんだけど。。。
    (3) Squash(コミットの統合)ができなさそう orz orz

今のところ、ここに書いたことが直感的にはできない感じかなぁ。
 SmartGit使用メモ / プルリクエストへの道

posted by Copyright (C) avrin All Rights Reserved. at 00:00| Comment(0) | TrackBack(0) | TortoiseHg/DVCS | このブログの読者になる | 更新情報をチェックする

2014年03月20日

SmartGit使用メモ / プルリクエストへの道

SmartGit使用メモ / プルリクエストへの道
* はじまり
* Gitリポジトリ
    本家リポジトリ:
    自分のリモート・リポジトリ:
    自分のローカル・リポジトリ:
* コミットグラフ/ログウインドウ/履歴グラフ/等々
* ローカルコミット系
    ローカルコミットの手順
    ローカル・リポジトリにコミットしてしまったコミットを取り消す方法:
    連続したローカルコミットの統合:
    コミットの分解:
* リモート・コミットの取消し
* プルリクエストの取消し/修正
* 本家の最新版を取り込むだけ:Fetch
* Rebase(リベース)かマージか?

* トピックブランチを使う
* トピックブランチを作る
* (トピック)ブランチを自由に切り換える

* Rebaseする手順
* リモートリポジトリを本家の最新と同一内容に更新する

* Rebase失敗時の対応(再Rebase方法)
    再リベース(リベースの継続):
* 知らない振りして古いコミットを送りつける xD


* はじまり
SmartGit v5.08をGithubでプルリクエストしながら使うと時のメモ。
http://www.syntevo.com/smartgithg/
SmartGitも徐々に改良が進んでいる様だ。

* Gitリポジトリ
本家リポジトリ:
    「本家/master」とする。
    プルリクエストを出す宛先のリポジトリ。
    実際には「本家」の部分に「本家の名前」が表示される。
    
    Githubにログインした状態でこのリポジトリのForkボタンを押すと、
    以下の「自分のリモートリ・ポジトリ」が生成される。
自分のリモート・リポジトリ:
    「origin/master」とする。
    本家をGithub上でクローンしたもので、実体もGithub上にある。
    ローカルコミットのPush先であると同時に、
    プルリクエストの発行元となる。
    プルリクエストを本家に出す時は、Githubにログインした状態で、
    このリモート・リポジトリの最新コミット(自分の)を表示すると、
    プルリクエスト発行ボタンが現れる。
自分のローカル・リポジトリ:
    「ローカル/master」とする。
    「Branchesタブ」の表示だと「Local Branches」の下の「master」である。

* コミットグラフ/ログウインドウ/履歴グラフ/等々
    これらは同じものを意味することにする。
    メインウインドウ上の「Logボタン」で出てくる。

* ローカルコミット系
ローカルコミットの手順
        (トピックブランチ上でやった方が良い)
        リポジトリに存在するソースの場合、
            (1) ソースを変更する。メインウインド上では赤背景で表示される。
                「State」が「Modified」になる。
            (2) 上を繰り返すと複数のファイルがModifiedになる。
                コミットしたいファイルを選択して「Commit」ボタンを押し、コミットメッセージを入れておしまい。
            
        リポジトリに存在しないソースの場合、
            リポジトリに、新たにファイルを追加する場合。
            そのファイルは「Untracked」と表示される。
            選択して、「Stage」ボタンを押せば「Added」表示になってStageされたことになる。
            (コミットでいきなりコミットも可能)
        Stage
            「Stageされたものだけコミット」、「コミット可能なものを全部コミット」を
            コミット時に選択でき、なおかつ、「チェックボックス」で選択し直すこともできる。
            
ローカル・リポジトリにコミットしてしまったコミットを取り消す方法:
        メインウインドウ上で、
        メニューから「Local」-「Undo Last Commit」すると、
        コミット前の状態に戻せる。

連続したローカルコミットの統合:
        メインウインドウ上の、
        「Outgoing」ペインで連結したいコミットを複数選択して、
        右クリックで「Squash commit」。
        分解はできなさそう。

コミットの分解:
        一つのコミットを複数のコミットに分解してコミットを重ねたい。
        やるなら、コミットを取り消して、その後に
        Satgeとコミットを繰り返して再構成する。

* リモート・コミットの取消し
    間違って意図しないコミットを自分のリモート・リポジトリ(origin/master)にPushしてまった場合。
    取消しは可能。
    きれいに消える。(見た目は。詳細不明)
    コミットグラフ上で、取り消したい先端のリモートコミット(origin/master)を選択、
    右クリックで「Delete origin/master...」で可能。
    Githubの場合、取消しがリモートへ反映されるまでに少し時間がかって焦る。

* プルリクエストの取消し/修正
    取消しはできないらしい。
    orz
    プルリクエストした時と同じブランチ上で、リモート(origin/master)に追加コミットを
    Pushすると自動でプルリクエストに追加される。
    この方法で修正コミットを重ねるしかない様だ。

* 本家の最新版を取り込むだけ:Fetch
    メインウインドウで「Branchesタブ」内の本家URLを右クリック「Pull」、
    その後「Fetch Only」を選択し取り込む。
    Fetchにすると「ローカル/master」とは別の「本家/master」の「枝」に取り込まれるので安心。
    カレントブランチの状態に依存しない。

* Rebase(リベース)かマージか?
  本家の最新版を取り込んだので、自分のローカル変更と「結合」します。
  結合方法には「Rebase」と「マージ(merge)」があって、
  可能な限り「Rebase」を選択した方が分かり易いと思います。

* トピックブランチを使う
    本家から取り込んだソースコードに変更を加える場合、
    一連のコミット(変更)をひとまとめにして名前を付けて管理します。
    そのために独立したブランチを一つ作ってその中で作業します。
    この新しいブランチに自由な名前を付けたものをトピックブランチとします。

    例えば「○○の機能追加」や「○○のバグ修正」という名前にします。
    ただし、日本語は無理なので適当な英語にしておきます。

    トピックブランチ方式にしたほうが、コミットグラフ上での視認性が増すと思います。
    というか、絶対見やすい。扱いやすい。

* トピックブランチを作る
トピックブランチはどこにでも、いくつでも作成可能。
   (1) コミットグラフ上で、新規ブランチの基点となるコミットを選択して「Add Branch」ボタンを押して
       名前をつけるだけ。
       この時、作ったブランチに「Switch」することも可能。
   (2) メインウインドウの場合は、カレントブランチに積み上げる形で新規ブランチが
        作られます。
        「Branches」タブの「Local Branches」を選択して右クリック「Add Branch」。

* (トピック)ブランチを自由に切り換える
        ブランチの切り替えには「Switch」を使います。
        カレントブランチにしたいブランチを「Branchesタブ」で選択して右クリック、
        「Switch branch」でブランチが切り替わります。
        切り換え前のブランチに未コミットのファイルが存在しないことが条件。

* Rebaseする手順
    (1) リベースしたい(トピック)ブランチをカレントブランチにします。
    (2) コミットグラフ上でリベース先のコミットポイントを選択する。
        通常は本家/masterの最先端部分。
        ここを右クリックして、
        「Rebase HEAD(nnn) to ...」を選択実行する。
        (「nnn」の部分はカレントブランチ名が入る)

* リモートリポジトリを本家の最新と同一内容に更新する
最もややこしいのがこれ。orz orz
    (1) 本家の最新をローカルにFetchする。
    (2) ローカルブランチをローカル/masterに切り換える。
    (3) コミットグラフ上で本家/masterを選択してそこへ「Rebase」する。
これで、「本家/master」と「ローカル/master」が同一で最新の内容になる。

この状態だと「リモート/master」だけが下の方に取り残されている。
すなわち、
「ローカル/master」(最新)と「リモート/master」(古い)の距離分のコミットが、
「リモート/master」へプッシュする内容となる。
それらは、メインウインドウの「Outgoingタブ」で確認できる。

この状態でメインウインドウの「Push」ボタンを押すと自分のリモートリポジトリ(origin/master)に
変更がPushされて、めでたく本家と同じ最新の状態となる。
ふぅっ! :D

* Rebase失敗時の対応(再Rebase方法)
本家の最新版をちょくちょく取り込んで状況をにらみつつ、
自分のトピックブランチ内で変更を続けていくと、
本家との差分が徐々に大きくなって、その中に自分の変更と競合(Conflict/コンフリクト)するコミットも現れます。
競合分が増加する前に適当なところでRebaseしておきます。

この時点で本家最新の"最先端"にRebaseを試みます。すると予定通り競合でRebaseが失敗(中断)します。
慌てずに、競合したファイルを一つずつ修正したあとStageしていきます。
再リベース(リベースの継続):
    全ての競合修正とStageが済んだらRebase失敗で中断していたRebaseが継続可能になります。
    コミットグラフ・ウインドウの「Rebase」ボタンを押して「Contine Rebase」で
    めでたくRebaseが完了します。(^^)/

* 知らない振りして古いコミットを送りつける xD
    最新版を取り込んでリベースしながら作業するのも大変なので、
    コンフリクトする可能性を承知で本家に送りつける手。(オイ
    マージの手作業を本家に押しつける方法。(オイ
    ただし、受け取りを拒否される可能性がある。
    というか、自動コンパイルシステムがあるとそれに引っかかって
    「エラーあるよ?」といわれるかもしれない。




posted by Copyright (C) avrin All Rights Reserved. at 00:00| Comment(0) | TrackBack(0) | TortoiseHg/DVCS | このブログの読者になる | 更新情報をチェックする

2013年09月05日

Git GUIで部分コミットするための1つの方法

Git GUIで部分コミットするための1つの方法
* はじまり
最近 、githubで初プル・リクエストをした時にTortoiseGitを使ってみた。
TortoiseGitでは部分コミットが出来ないことに気づいたのだった。orz

* プル・リクエスト (注2)
は、githubに登録されたオープンソース・プロジェクト等に対して、
バグFixや機能追加などの変更点を、github経由で送りつける(爆 機能です。
プロジェクトに対するコミット権限が不要なので、誰でも変更を送り付ける(爆
ことが可能です。
送りつけられた変更に対して専用スレッドが立つので、誰でもツッコミや助言、
質問を書くことが可能です。(レビューとも言う :-)
その過程で間違いが見つかれば変更点を自分のforkリポジトリに再度コミットすると、
自動でプル・リクエスト内容も追従して更新されます。
これは、便利だぁ〜。
送り付けるというのが、ミソかも。:D  (contributionとも言う)
特に、単純なバグとかコンパイル出来ない系の内容を、いちいちフォーラムや掲示板に書き込んだり
するのが面倒な昨今(注3)、自分で出来そうなものは四の五の言わずに、
直して送りつけた方が早いって感じでしょうか。


で、
TortoiseGit v1.8.5.0現時点(2013/08)の最新版。
ここでは、コマンドラインでgitをどうこうするのではなく、
あくまでGUIで便利に使いたいというのが前提です。
* 部分コミットとは?
例えば、下図の様に1つのファイル内で複数箇所の修正を入れたものの、
git-partial-commit.png
デバッグ用の修正は個人的なものなのでコミットしたくない、
また、他の用途にも使えるので、しばらくこのまま残しておきたい。
従って、
(ローカル)コミットはバグ修正部分だけにしたいのだった。

この用途には「gitのstashという機能を使えば簡単にできるはず」と思い込んでいたが、
実はTortoiseGitの実装が全然できてなくて困ってしまったのだった。

* stash (スタッシュ)
stashというのは、ざっくり言うと、ローカルで加えた変更を一旦全部なしにして、
変更部分を別の場所に名前付きで待避しておける機能だ。
必要になったらいつでも変更を再適用できるのだ。
こういうシーンは良くあること。
で、
問題は、TortoiseGitのstashは全ての変更を一括で待避する機能しか実装されていないのだった。
これだと部分コミットには使えません。
orz
(調べたところ、gitコマンドの仕様としては、部分stashに対応している様です)
部分コミットに必要な要件:
(1) ファイル単位(選択して)でstash出来ること。
(2) 1つのファイル内で変更差分ブロック(hunk、ハンク)単位でstash出来ること。 

* stage (ステージ)?!
ググっている最中にstageという機能が発見された。
えっ?!
TortoiseGitのメニューにはstageなんて文字出てこないよ?!
orz orz
stageとは、ぶっちゃけた話  (爆(爆、(注4)
選択的にコミット出来る機能なのだ。(あくまで、ぶっちゃけ的表現です xD )
な、な〜んだ、これでい〜じゃん! !
(爆
もう少し書くと、
「stageする」とは、コミットしたいファイルや変更点をリクエストするという感じでしょうか。
コミット時は、リクエストがあったものだけがコミットされることになります。
ちなみに、
stageするとファイル(変更点)が「Index」に登録されたことになって、何が現在stageされているかを
見るには「Indexed」されたリストを見るという表現になる様です。
GUIによっては、「Staged」と表示されるものもあるようです。
で、上に書いた様な理由で、
コミットとstageは不可分なので、
ユーザには「stage」という行為をさせなくても良い(GUI側でやってしまう)
というのが、TortoiseGitの現時点の造りだと思われます。

* 選択的、部分 stage が可能な Git GUIは?
stageにはファイル単位、hunk単位(注1)でステージ出来る機能があるんです。
Windows上で無料で使えるGit GUIでhunk単位のstageが可能なものを探してみた。
シンプルなものも含めて5種類くらいを試してみたら、以下の3つが該当した。
優勝 (爆: 
SmartGit/HG
http://www.syntevo.com/smartgithg/
ver.4.6.3
Windows/Linux/Mac
(1) 非商用で使うなら無料。
(2) stageのGUIは良くできている感じです。
(3) stageのhunk選択はブロック指向。(後述)
(4) gitの管理下にあるファイルは、画面中段のペインでstage選択ができるけど、
    メニューボタンの「Index Editor」を使うと更に見やすいウインドウで操作できます。
(5) 英語ベース。
準優勝 :D :
SourceTree
http://www.sourcetreeapp.com/
ver.1.1.1.0
Windows/Mac
  残念ながらLinux対応は、当分ないと宣言されています。
   https://answers.atlassian.com/questions/149631/sourcetree-for-linux?sort=votes&page=1
(1) 完全無料。
(2) stageのGUIは微妙に変です。(爆(爆
    hunkのブロック選択が可能なGUIに見えるものの、実際には「行指向のhunk選択しかできない」感じです。
    hunkを行選択で指定するのは、ちょっとつらいものがあります。
    (できないよりは、良いけれど。。。ブロック選択もほしいね)
    ちゃんと実装されれば今後、逆転優勝もありえる。
(3) Linuxで使えないのは、ちょっと残念なSourceTree.
(4) 英語ベース。
準優勝 :D :
Git Extensions
http://code.google.com/p/gitextensions/
Windows/Linux/Mac?
(1) 完全無料。
(2) stageのhunk選択は、行選択指向です。 できないよりは、良いけれど。。。
(3) 日本語化されている。
銅賞:
TortoiseGit
http://code.google.com/p/tortoisegit/
(1) 完全無料。
(2) 使い込んだワケじゃないけど、日本語化されているし、SmartGit/SourceTreeに比べれば軽快だし、
    シンプルに使う分には、そんなに悪くないと思う。
    今後、上記ステージ・インターフェースが実装される事を期待する。

* stageとstashを使った 部分コミット手順
まとめると、以下のようになります。
(1) 必要な部分(hunk)だけをstageした後、ローカル・コミットする。
(2) ローカルファイルを全部stashして「コミットしなかった変更部分」を全部取り去る。
(3) これでローカルファイル群がコミットした内容に一致するので、
    この状態で再度コンパイル等をして動作確認する。
(4) OKなら、サーバにローカル・コミットをPushする。
注意ポイント:
(a)、 (2)と(3)を省略するとコンパイル不能なコードや、(爆
       バギーなコード(爆(爆 をコミットしてしまっても発見できない可能性がある。
(b)、 stageした後、コミットせずにstashすると、stageしたものもstashされて消えてしまう。
      これよく間違えます。 orz

* まとめ
結局、2013/09現在、部分stashを実装したGit GUIは発見できてない。
部分stageが出来るGUIも少ない。
hunkのブロック選択における弱点は、以下のかたの記述が参考になります。

横着で神経質な私とあなたに贈るgit add -p
http://qiita.com/crifff/items/1abf08bca4ce51db4775

* その他
ちなみに、TortoiseHgというMecurial用のGUIに、Gitのstash相当の機能(shelve)が実装されているが、
その出来ときたら、秀逸(しゅういつ)を通り越して超絶な感があるのも事実。(爆(爆

* stash問題、再燃
コミットしない変更点を定常的に保持する必要がある場合。
例えば、Makefile内でコンパイラの実行パスが絶対パス指定になっている場合、
最終確認のためstashすると、コンパイルも出来なくなってしまう。orz

TortoiseHGのshelveなら朝飯前だけど、
gitの場合は多分、手動でパッチを作って適宜パッチあてするとか、自前で部分stashを作って置くか、
という面倒な方向な気がする。
mbed-sdk:
最近、mbed-sdkをコンパイルした時に、この問題を華麗に解決していて感心した。
コンパイラの絶対パス指定のファイルを独立させ、プロジェクトに含めないで、
使用者側で決められたファイル名と書式で新規作成する。(設定ファイル)
これを例えば、
Makefile内やビルド・スクリプト内でインクルードして使う。
これなら、
設定ファイルはgitの管理下にないので、stashの影響を受けなくて済む。
ただし、「gitの管理下にないファイルも含めてstashする」とういう強力な
機能(オプション)が使えなくなるといえば、そうかも。。。 :D


おしまいっ!







(注1)hunkはファイルの中にあるので、ファイル単位という言い方は、hunk単位と言っているのと同じです。 :D
(注2)他のプロバイダも同じ呼び方をする様だ。
(注3)書き込んでも、忘れられたり、後回しになったり、うやむやになったり。。。。 :D
(注4)詳細はWebページ参照。 :D


参考リンク:
Gitによるバージョン管理入門 for windows 
http://www.plowman.co.jp/school/Git/Git.html
非常に分かり易いです。でもなんか覚えるの大変。(爆


posted by Copyright (C) avrin All Rights Reserved. at 00:00| Comment(0) | TrackBack(0) | TortoiseHg/DVCS | このブログの読者になる | 更新情報をチェックする

2011年04月02日

TortoiseHg Ver.2.03 で githubにPushする方法. 2011年4月

TortoiseHg Ver.2.0.3が2011/04/01(昨日)出ました。

Ver2.0.2に対して修正が3週間で300コミットくらい入っているのでアップしたほうが
良いかもです。
https://bitbucket.org/tortoisehg/thg/downloads

Ver.2.0.0の時に「githubへのプッシュ」をあきらめていましたが、
今回のVer.2.0.3であらためて実験したところ成功しました。
設定関係は、以前の
TortoiseHg(Mercurial)探検隊(2) githubにPushする方法. 2010年10月
と同じです。(ssh.exeのコピーは不要でした)

結局キモは、
「hggit」のアップデートでした。

「hggit」のリポジトリを最新に更新します。少なくとも
"リビジョン382" 2011-03-23 にする必要があります。

「hggit」のリポジトリの場所は「mercurial.ini」に書いてあります。

これで、「githubへのプッシュ」ができました。 v(^^)

*良くなった点
まだ、Ver.2.0.3にしたばかりなのでアレだけど、細々(こまごま)と
改善がされていて好印象です。(表示関係とか)

タブ切り換えで少しもたついていた(リポジトリが大きいとき)ところが改善されています。

もう少し使って見ることにする。
posted by Copyright (C) avrin All Rights Reserved. at 18:46| Comment(0) | TortoiseHg/DVCS | このブログの読者になる | 更新情報をチェックする

2011年02月26日

待望のTortoiseHg Ver.2.0出そう?! → 出たっ!!

そろそろでるね。

(2011/03/02)
https://bitbucket.org/tortoisehg/thg/downloads
出ました。
Ver.2.0のリリースから15時間で丁度2000回ダウンロードされています。
(x86 + x64)
(2011/03/10夜時点で約19500回のダウンロードを確認(Ver.2.0))


少し使って見たところ期待通り大変すばらしい感じです。
もう少し使ってみます。

tortoise2.0.gif

上が今回目玉の「あちこちにあるリポジトリをまとめてタブブラウジングできる」
画面です。
めちゃめちゃ使いやすいです。
(できれば「リポジトリ一覧ペイン」は、ワンクリックでタブが切り替わってほしいけど。)



*残念な点?
GUI大幅変更版なので細かいところは、これからな感じがします。

現状「hggit」はうまく動作しないようです。
リポジトリをクローンし直すとPullはできるようになります。
でもPushはうまく行きませんでした。

しばらくは、以下のバグ報告(BTS)をウオッチする必要がありそう。
https://bitbucket.org/tortoisehg/thg/issues


(2011/03/10)
*Torttoise2.0の開発バージョン
https://bitbucket.org/tortoisehg/thg-winbuild/downloads
から2.0の最新版を取得できる。
上の正式リリース版以降の修正がされているのを期待して
現在はこの開発版をインストールして使っている。

参考 日本語Mercurialメーリングリスト
http://groups.google.com/group/mercurial-ja/browse_thread/thread/d6c6584bda3ab80f


(2011/03/11)
*Tortoise Ver.2.0.1リリース
正式版Tortoise Ver.2.0.1がリリースされていました。
v2.0から120回以上のコミットが入っているのと、Mercurialがv1.8.1に
変更になっている版。
https://bitbucket.org/tortoisehg/thg/downloads







参考メモ:

SVNからMercurialに移行するべき8つの理由
http://anlyznews.blogspot.com/2010/12/svnmercurial8.html
上のリンクで難しいのが、それぞれの用語の意味が分からないと
理解が難しそうなところ。でも言いたいことはわかるかも。

操作体系から見る、GitとMercurialの8つの理由
http://anlyznews.blogspot.com/2010/12/gitmercurial8.html

Mercurial: The Definitive Guide
(Mercurial による分散構成管理)
http://foozy.bitbucket.org/hgbook-ja/d6ca1334a19d/hgbook.html
目次は英語だけど中身は日本語です。

Mercurial初心者が絶対にブックマークすべきページ
http://uncorrelated.servehttp.com/tool/t02.shtml
Mercurial の使い方のチュートリアル
http://mercurial.selenic.com/wiki/JapaneseTutorial
posted by Copyright (C) avrin All Rights Reserved. at 22:17| Comment(0) | TortoiseHg/DVCS | このブログの読者になる | 更新情報をチェックする