README.md などの Markdown ファイルを GitHub に push する前に、GitHub と全く同じ見た目でプレビューできる GitHub CLI の extension を作った。markdown-previewというカスタムコマンドが使える。 今回はgh-markdown-previewの紹介と、GitHub CLI extension を作ってみての所感を書く。 gh-markdown-preview Markdown、特にREADMEファイルを GitHub のリモートレポジトリに push する前にプレビューしたいことが結構あった。github.com のページでどのように表示されるかをブラウザで見てみたいのだ。Markdown エディタやビューアーで GitHub っぽいスタイルはあるものの、HTMLとCSSがビミョーに、いや「わりと」違うので満足がいかなか
この前作ったスクリプトをより改良しました。 SourceTree で指定のリビジョン間の差分ファイルだけ取り出したい ターミナルでも使えますが、SourceTree のカスタムアクションで使うほうがわかりやすいです。 こんな感じの機能が git export みたいな感じで実装されてればよいのですが…。 このリポジトリをクローンしてください。必要なのはスクリプトだけなので、アーカイブでもファイルだけでもいいです。 44uk/git-export-tools: export files from git repository 任意の場所に保存したら、SourceTree のカスタムアクションに登録します。 引数としてハッシュが必要なので $SHA を Parameters に画像のようにセットします。 後は、リビジョン一覧から取り出したいリビジョンを選択して、アクションを呼び出してください。
ネイティブアプリの開発とかしてると、ついつい git にスプライトの png とか一緒にコミットしてしまって、気づいたらリポジトリサイズが 1GB 超えてたとかありますよね。 git annex とか、本格的なアセット管理システムとか使えば良いんだけど、普通のgitコマンド覚えるだけでいっぱいいっぱいな人にさらに他のツールまで覚えてもらうのは大変です。 そこで、登録しておいた拡張子のファイルはハッシュ値だけをリポジトリに格納し、ファイルの内容は別のディレクトリやAmazon S3に格納する git-largefile/gits3 を作りました。 git-largefile/gits3 は git の filter として動きます。 filter は通常改行コードの変換をしたり $Id$ のようなキーワードを変換したり行末のスペースを消す、文字通りフィルターなのですが、ここでファイル本体から
A free Git client for Windows and Mac Sourcetree simplifies how you interact with your Git repositories so you can focus on coding. Visualize and manage your repositories through Sourcetree's simple Git GUI. Simple for beginners Say goodbye to the command line - simplify distributed version control with a Git client and quickly bring everyone up to speed. Powerful for experts Perfect for making ad
git rebaseについてのtips - けーこ in サンフランシスコ gitを使って開発をすすめていると、このようなコミットを見かけることがあります。 Merge branch ‘master’ of git://github.com/hogehoge 最新のマスターを私のブランチにマージした、という意味のログなのだが、 はっきり言ってこれ必要ないね。 ブランチをマージして、その後にgit pullしたあとに出てしまうコミットのようで、 pull requestを出す前に最新のマスターを自分のブランチにマージしたいために このようなコミットメッセージが出てしまうようだ。 要するに、自作したブランチの修正が、git pullしたmasterブランチの最新の修正よりも 前だったら上記のようなコミットメッセージを出しつつ、ブランチのコミットを前に 持ってくるわけですね。 で、 git lo
注意: バズってますが、これははてなダイアリーからはてなブログの自動マイグレーションに失敗してたものを復旧させたもので、書かれたのは2012年です。 - 最近流行っているGit初心者向け記事は、「僕らが本当に知りたかったこと」が欠けているようにしか思えません。 そこで、本当のGitの使い方を僕が皆さんに伝授しようと思いました。 なにはともかく使ってみよう 前提として、皆様のお手元にはすでにGitがインストールされているものとします。 今回はエディタとしてDungeonCrawl StoneSoupを使います。 Downloads « Dungeon Crawl Stone Soup http://crawl.develz.org/wordpress/downloads Dungeon Crwal Stone Soup は今一番ホットなオープンソースのローグライクです。風来のシレンやトルネコ
前々回のGit解説の続き。 Gitでは色んな作業の仕方があります。 デザイナーとエンジニアの間でよくある作業の流れをイメージ描きつつ説明してみようかと。 今回は「エンジニアとデザイナーが同じブランチで作業する」です。 まず朝出社！ 今日は検索ページを作るお仕事をすることになりました。 このイメージにそって説明してみます。 [イメージ内：P-1] エンジニアがみんなの場所（remoteとか呼ばれてるところ）から最新の「master」ブランチを持ってきて… そこから「search」というブランチを作りました。 [イメージ内：P-2] エンジニアは「search」というブランチで、検索フォームのあるページを作成しました。 デザインはまだ入ってません。 [イメージ内：P-3] エンジニアは「git push」というコマンドで みんなの場所remoteに「search」ブランチを置
どうもこんにちは。フックしてますか。ジャブからローにつなげてますか。 そんなこんなで最近は僕もそこそこ git に慣れてきて助けてもらわなくても良くなって来ました。 しかし人間の欲望はとどまるところをしらず、「なんか定形作業めんどくせーなだるいしなんかうまいことどうにかなれよ面倒くせぇ」とか考え始めるものです。たとえば「テスト通ってないコードコミットするなってリーダーがいうけどいちいち手でテスト走らせて確認すんのだるいからなんかうまいこと自動で動かんかな」とか。 git は大変よくできたツールですので、そういうのもちゃんと用意されています。hooks といって、コミットのタイミングなどで特定のシェルスクリプトなりなんなりを動かすことが出来るよう配慮されているのです。すげーな git 。 しかしこいつがマジめんどくさい。自分でシェルスクリプト書くとか絶対嫌だし、すでにそのへんに転がってるのを
西尾さんが奥さんに Git を使わせたいらしい それを口実に妻にgitを覚えさせようとしたら紙の方が便利だと言われて説得しきれなかったので手伝ってください！(ぇ @yoshiori: 校正のために git 使ったけど便利やぁ みんな git で原稿上げてくれればいいのに＞＜ 2012-01-24 20:24:13 via Twitter for iPhone なのでちょっとバージョン管理としてだけでも Git 使うと楽だなぁと思うところを書いてみたい。 あ、西尾さんは多分複数で校正とかする文章の話なんだと思うんだけど、今回は複数で管理とかそういうところはやらずに純粋に一人で文章書くときも Git 使うと便利だよってことを書こうかなぁと思う。 最初の一歩 文章を管理するディレクトリを Git 管理下に置く $ git init Initialized empty Git repository
序 言うまでもないことだが、タイトルはジョークである。 そもそもバージョン管理は本来我々がしたい事ではない（一部の人を除く）。別に作りたいものがあり、そこでの作業を円滑に進めるためにバージョン管理するのだから、所詮はヤクの毛刈りである。さらに、Gitクライアントのへっぽこさも相まってなかなかに時間を食われる。この文書はそのような人々が、より円滑にGitを使えることを祈って書かれた。 なお、バージョン管理というのはとても複雑なシステムであるため、バージョン管理自体が目的な人には楽しい世界である。そのような人々はぜひGitやその他のバージョン管理システムのマニュアルやソースコードを読んでいただきたい。きっとその奥深い世界を堪能できることだろう。 Git概説 Gitはこれまでの旧来のバージョン管理システムとは一風違った設計で作られている。また、Git特有の概念も多い。なので、まずGitの概観を説
追記：たくさんブクマしていただいて驚いております。ブクマコメントだと、やはり git push -f は反則だろという意見がサイレントマジョリティのようですが、そこはそれ、自 己 責 任 追記２(2011/11/07)：commit messageをミスった場合について訂正しました。 git rebase -i で直近のコミットを "edit" にして修正すると、 「--amend使えや」と言われるようです。 gitのコミットをしくじった時の対処法について、一覧性の高いまとめがなかったので作りました。正確さは保証できないので、コマンド名ヒントに自分でググって下さい ほかのやり方があるよ、間違ってるよ等のご指摘歓迎です。 派閥別 gitでコミットミスった時のまとめ ｜ ├─ 一人で使ってるよ ｜ ｜ ｜ ├─ 手元に変更を取り戻したいよ(1)（そうだね、add忘れだね派） ｜ ｜
「Git」使ってますか？ 近年、分散バージョン管理システム「Git」が急速にシェアを伸ばしています。筆者は、チケットシステムやバージョン管理の勉強会などを開催したりしていますが、Gitユーザーがかなり増えてきていると感じます。 しかしながら、そのような勉強会でアンケートを取ってみると、実案件では半分以上の人がSubversionを利用しており、Gitの導入はまだまだ進んでいません。移行コストが掛かったり、プロジェクトマネージャ層への知名度がまだまだ低いというのもありますが、理由の1つとして、ユーザー管理が煩雑であったり、アクセス制御に関する情報が不足しているということもあると思います。 そういうわけで本稿では、Gitリポジトリのユーザー管理やアクセス制御を簡単に行う「Gitolite」を紹介します。 なお、本稿ではGitの利用方法については紹介しませんので、Git自身の使い方については改め
Wikiというものはとても便利なんだけど、 大量の文章を書くにはWebブラウザのインターフェースはまだまだ辛い オフラインで使えない(文章書くのは電車が一番) 複数の文章を再構成したり、一括で検索したり、置換したりは、Webだとやっぱりきびしい と言った欠点がある。 とは言え、誰でも気軽に編集できるWikiの魅力も捨てがたい。 そこで、「Wikiではあるんだけど、ローカルでも自分の好きなエディタで簡単に編集できるツールないかなー」と探してみたら、 Gitit というWikiを発見した。 ここ数日、結構な量のドキュメントをGititで書いてみて、わりと満足しているのだけど、検索してもGititの日本語の情報があまり出てこないので紹介してみる。 Gititの特徴 コンテンツをGitのレポジトリに保存する。 そのGItレポジトリをcloneして好きなようにいじってからcommit/pushすれば
git cloneするときに--recursiveをつけると，サブモジュールもcloneしてくれる． リポジトリがサブモジュールを持ってるときだけgit submodule update --initするのは難しいので，勝手にやってくれるのは良いと思う． こんな感じ． % git clone https://github.com/unconed/TermKit.git --recursive Cloning into TermKit... remote: Counting objects: 2574, done. remote: Compressing objects: 100% (1099/1099), done. remote: Total 2574 (delta 1431), reused 2502 (delta 1385) Receiving objects: 100% (2574
detached HEADって言う名前で入門Gitにも書いてあるんだけど、そういうことが起こりうるってメンタルモデルができてないと起きていることにすら気づかないので書いておく。 まず説明用のリポジトリを用意します。 t$ git init Initialized empty Git repository in /Users/nishio/gittest/pygit2/t/.git/ t$ touch a t$ git add a t$ git commit -m "add a" [master (root-commit) 6f6eb7c] add a 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 a t$ touch b t$ git add b t$ git commit -m "add b" [m
git リポジトリの .git/config には remote origin となる URL がテキストで書かれている。 [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = ssh://user@host/~user/git-bare/repo.git [branch "master"] remote = origin merge = refs/heads/master なお、これらの値は git config -l で参照することもできる。このうち remote.origin.url を書き換えることで pull/push の対象
Webサーバに Subversion のサーバを立てておき、HTML や CSS を commit することでWebサイトを更新する方法は、良く知られているテクニック、らしいですね*1。更新の履歴を残すことができるし、ましてチマチマとFTPやsftpでアップロードするよりずっと簡単です。 しかし SVN の代わりに git を使おうとすると、pushしてもリポートリポジトリではファイルを更新してくれません。 また、リポジトリはWebサーバ上に作るよりも、便利な管理インタフェースがある github（や噂のgitosis）に置いておきたいところです。 そこで、github の Post-Receive Hook を使うと、リポジトリに変更を push すると同時に、Webサーバにも同期させることができます*2。 Webサーバに同期する前に、Sphinxでドキュメントを整形したり、SassをC
はじめに ここでは Vimpr でよく使うと思われる git コマンドの一覧と概説を提供します。全ての git コマンドやオプションを網羅しているわけではありませんし、git を利用したワークフローまでは記載しませんので、git メンテナー濱野純さんの入門Git等で勉強してください。 またこのページに記載したいコマンドがあれば、追記してください。 たぶんよく使う git コマンド一覧 リモート・リポジトリ関連 git clone リモート・リポジトリをローカルへ clone git clone git@github.com:vimpr/vimperator-plugins.git git clone git@github.com:vimpr/vimperator-rc.git git clone git@github.com:vimpr/vimperator-colors.git git
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く