update.お疲れさまです、trebyです。2014の23日目を担当させていただきます。Gitを業務で使い始めて早2年、だいぶ慣れてきた感じがありますが、それをアウトプットする機会があるかといえばなかなかありません。同僚に聞かれるくらいでなんかもったいない感じがあります。そこで今日は私個人がgitを使って仕事をする上でどういうフローしているかなーということを改めて文字にアウトプットしてみたいと思います。ご参考にしていただくなり、ツッコミしていただくなりしていただけますと幸いです。本投稿において想定するツールはGit、ホスティングサービスはGitHubですが、多分その他のサービスでもいけるのではないかと思います。「新しくチームに配属された!」等のシチュエーションを想定しています。initというものがありますが(今更)、既に開発が始まっているプロジェクトにジョインするような場面でこれを打つことはまずないですよね。cloneだと思います。git@github.com:reddit/reddit.gitこうすることで、GitHubのreddit/redditのコードを手元に持ってくることができます。あ、もちろん各種ホスティングサービスへの公開鍵の登録みたいな作業は完了させておいてくださいね。開発フローがgit-flowであれ、github-flowであれホスティングサービス上に自分用のリポジトリを持っておくことになるでしょう。開発に参加するならば、GitHub上でリポジトリをforkしますよね。そこで開発マシン上で自分用のリモートリポジトリに名前をつけてあげます。git@github.com:treby/reddit.gitとすれば、先ほどのreddit/redditをforkした(という想定)treby/redditにselfという名前をつけたことになります。Requestを作成することになります。-vで見ることができます。【ユーザ名】@【ホスト名】という情報が使われます。--reset-authorそこで、コミットのAuthor情報などに使われる自分の情報を設定してあげます。"treby@example.net"とまあ通常であれば、大抵のケースではこれ一回行えば良いのですが、プロジェクトによってAuthorを変えたいという場合が生じることがあります。一つのマシンで仕事のコードと趣味のコード、両方を書くようなケースですね。gitがコミットの際に付与する情報はデフォルトでは上記で設定した情報ですが、もちろんリポジトリごとに設定することもできます。やり方は簡単で設定したいプロジェクトのコードがあるディレクトリで先ほどのコマンドから--globalを外せば良いです。"hiroaki.ninomiya@example.com"ここで設定した情報はプロジェクトルート以下の.git/configに記述されています。hiroaki.ninomiya@example.comここまでで一通りの開発準備ができました。使うテクニックあれこれ次は実際に開発作業を行う上でよく使うコマンドをTips風に紹介します。branch自体はブランチを一覧するための用途に使用することが多いです。branchは--mergedオプションで現在のブランチ(というかHEADというか)にマージされている(含まれている)ブランチの一覧、-dオプションでブランチの削除ができます。これらのオプションを利用して、開発が進んでブランチが多くなった時などmasterブランチ(最新にしておく)上などで以下のようにして、マージされたブランチを一括で削除したりします。...コミット前の準備コードの修正がひと段落したらコードをステージングエリアにあげましょう。ステージングエリアという考え方が独特でとっつきにくく感じていらっしゃる方も多いようですが、コミットの前の準備状態くらいの認識で良いのではないかと思います(15日目の記事では「手紙を封筒に入れる」というユニークな表現をされています)。.と入力すれば、そこまで行った全てのコード修正がステージングエリアにあがります(封筒に詰められます)。全てのコード修正をステージングエリアにあげて、コミットしたい場合はこれで良いのですが、コード修正を行ったけれど一部は別にしたいなぁとか、今はまだいいかなというケースではどうすれば良いのでしょうか。私は移り気な性格をしていますので、機能を実装している途中に実装と全く関係のない部分のタイポ修正だとか、インデントの崩れの修正だとかを行ってしまいます。-pで、どの部分の変更をステージングエリアにあげるのか指定することも割とあります。Requestしたほうが行儀が良い気がします。rmを使うと、これらの変更をステージングエリアにあげることができます。コミットの作り方ステージングエリアの準備ができたら、次はいよいよコミットです。行った修正を歴史に刻みましょう。statusを使ってコミットしようとしている内容を本当にコミットして良いか確認しましょう。.DS_StoreやThumb.dbが含まれていると恥ずかしいですよ:)実際のところ、普段は-mオプションつけて一行でコメントを書くことが多いです。bad.'チケット対応など、修正に対応するリソースがある場合は、あえてオプションをつけずエディタを起動させます。エディタ上で2行目などにチケットへのURLを添付します。.)つけてコミットすることもあります。typo.'ちなみにコメントは現在形で書くのが良いらしいです。日本語/英語、現在形/過去形、自動詞/他動詞などのお作法はそれぞれのプロジェクトの文化によると思いますので、そちらに合わせてください。コミットの作り直しちゃんと正しいかを確認してコミットしたつもりでも、やっぱりミスっていたり、そうでなくても後で関連する場所のtypoを直したくなったりすることはよくあります。そのようなケースでのコミットの作り直し(歴史の刻み直し)方を紹介します。ちなみにエチケット上、公開されている環境下(チームの共用リポジトリなど)のコミットを書き換えることは厳禁です。事故の元になるので控えましょう。typoのコミットを作成してみて、それに慣れた段階で参考されてみてください。--amend単純に直前のコミットに修正やファイル追加やファイル削除などを行いたい場合は、--amendオプションを使います。rebase機能開発途中のコミットでtypoをしてしまった場合など、対話的rebaseを使います(-iオプション)。3つ前のコミットで軽微なミスをした場合は以下のように入力します。HEAD~3するとエディタが起動して、下記のような画面になります。1)を行った状態で一時停止してくれます。--amendでコミットをまとめます。1)にまとめられる形になります。--continueでrebase作業を続行します。--abortでrebase処理そのものを中断することもできます。-iについて、ここではコミット間に変更を加えるeditを紹介しましたが、その他にもコミットを一つにまとめられるsquashなどを利用することができます。pickの記述をなくすことでコミットそのものをなかったことにしたり、前後を入れ替えることでコミットの順番を変更することもできます。rebase自体は作成してからちょっと時間が経っちゃったなというブランチに対して行うことが多いです。reset実際上、ブランチのつじつま合わせに使っています。本来であれば別途featureブランチを作成して行うべきコミットを誤ってmasterブランチに行ってしまった場合などです。--hardします(一旦戻そう、的な)。--hardまとめgitはあくまでツールの一つなので最低限使えればそれで十分だと思います。自由自在に使えるとドヤリングできますし、頼られますし、微かな全能感があって楽しいのも確かです。使い始めはなんだかよくわからなくておっかなびっくりになってしまいがちですが(私の場合、開発環境上でコミットすら怖かったです)、コミットしていてリポジトリ(プロジェクトの.gitディレクトリ)が無事ならばなんとかなります。masterブランチ消してもなんとかなります。Hacking!!していきましょう。明日はshigemk2さんによる「GitHubEnterpriseを導入してみるにあたって気をつけたいことをいくつか」(既に記事がある......!)です。upLoginユーザーは見つかりませんでした。