お久しぶりの KUCKLU（@kuck1u） です。 公開は少しマニアックなネタです。 本番 / テスト環境へのファイル転送 WordPress のテーマやプラグインの開発でローカル環境での動作確認完了後、本番を想定したテストサーバーで動作確認をする事が多い思います。例えば、公開ドメインのサブドメインでテスト環境を作ってなど。 テストサーバーで動作確認をしようとした時、大多数の人はローカルにあるファイル一式を FTP や SSH などで転送と思います。もしくは、ちょっとイケメンな人だと WordMove というツールを使ったり。 方法はさまざまだけど、とにかくファイルを転送しますよね。 でも、正直面倒臭くないですか？・・・僕は、面倒臭いです。 Git と連動してみる とはいえ、黒い画面は不慣れなので、ついつい SFTP クライアントとか立ち上げてドラッグ・アンド・ドロップとかしています。
Gitを使用している人であれば、プルリクエストには馴染みがあるでしょう。これは、分散バージョン管理システムが世に出始めてから、何らかの形で使われています。BitbucketやGitHubのように凝ったWebユーザインターフェイスが構築される前は、プルリクエストは単純に電子メールベースで行われており、Aliceのリポジトリから変更をプルするように依頼していました。プルリクエストを受けた側がこの変更を妥当だと判断すれば、いくつかのコマンドを実行しmasterブランチに変更をプルするという流れです。 $ git remote add alice git://bitbucket.org/alice/bleak.git $ git checkout master $ git pull alice master もちろん、手あたり次第Aliceの変更をmasterにプルすることは、 得策 ではありませ
はじめに 最初に、Gitに関するリソースとして、本では「入門Git」と「実用Git」、Web上では「Pro Git」が読みやすく、わかりやすいため、Gitについて知りたい人は一読をおすすめします。 特に、他のバージョン管理システムに関する前提知識がある場合には、Gitの概念や使い方も比較的スムーズに理解できるかと思います。実際に、バージョン管理システムをSubversionからGitへと移行してからしばらくが経ちますが、通常の操作に関しては、それほど不自由することなくGitを利用できています。 しかし、Gitを利用していくにつれて色々と疑問も出てきます。局所的なワークフローについては、様々なリソースによって理解することができます。では、効率的に開発・運用・保守・管理を行うために、大局的・継続的なワークフローをどのように採ればよいのか、特にGitの柔軟性を活かすにはブランチをどのように使えば
追記[2011/09/26] git-now のurlをgistからgit-hubに変更しました。 追記[2011/10/17] ライセンスはGPLです 一時的なtmp コミットや、簡単なログメッセージのコミット（push 前にログメッセージを整えています）を作るとき、今まで↓みたいな事をしていました。 で、これを使いながら「〜〜も出来たら便利かもー」とかつぶやいていたら、隣の人が一晩で（ｒｙ と、そんな感じで出来たgit-now の紹介 簡単な実行例 コマンド $ git now これで、版管理されているファイルのtmp コミットが作成できます。 コミットメッセージ例 [from now] Tue Dec 7 23:00:24 2010 diff --git a/hello.py b/hello.py index 51cff9f..9e84b86 100644 --- a/hello.p
id:bleis-tiftによるgitのフックスクリプト集がマジ便利。 gitとredmineを使ってる人はぜひ使うべき 機能 チケット番号付加 id/12というブランチで作業してるときは、コミットメッセージの末尾にrefs 12を自動でつけてくれます Redmineのチケットごとにブランチを切るようにすると、マジ便利 masterブランチへのコミット拒否 masterブランチへのコミットを拒否する 必ずトピックブランチを切るようになる pushされたときにチケットIDのないコミットの拒否 チケットIDのないコミットのpushを拒否します ダウンロード・インストール方法 https://github.com/bleis-tift/Git-Hooks に書いてある通りにすれば簡単にインストールできます
【翻訳】あなたの知らないGit Tips
Mislav Marohnićさんの "A few git tips you didn't know about" を翻訳しました。 元記事はこちら： http://mislav.uniqpath.com/2010/07/git-tips/ （翻訳の公開は本人より許諾済みです） 翻訳の間違い等があれば遠慮なくご指摘ください。 あなたの知らないGit Tips注意：いくつかのコマンドやオプションは Git の version 1.7.2 以降が必要です。 OS Xでは、 Homebrew で簡単にアップグレードできます： brew install git git log でブランチとタグも見る$ git log --oneline --decorate 7466000 (HEAD, mislav/master, mislav) fix test that fails if current d
みんな大好きgithubが新たにMac用のgitクライアント(実はgithub以外でも使える)をリリースしました。このクライアントを利用する事でコマンドラインを使わずに手軽にコードを共有したり公開したりできるようになります。 また特徴としては下記のような点があります。 プッシュとプルを同時に行う「sync」機能 ワンクリックでクローン ショートカットキーを利用した操作 Gravatarを利用したアバター表示 なぜわざわざgithub専用なのかという疑問もあるかもしれませんが、複数のリモートはサポートしないものの手動でgithub以外のリポジトリをマスタにする事も可能なようです。どことなく硬派なgitのguiではなくかわいいインターフェースでgitを使いたい人には朗報です。なおどうやらインストーラーとアイコンがかわいいらしいので、とりあえず入れてみるといいかもしれません。 via:http:
設定 基本 ブランチ リモート・リポジトリ git-stash git-svn 参考 修正履歴 設定 Git には様々なオプション設定がある。中には挙動を大きく変えるものもあるので注意が必要である。 設定をすべて表示する $ git config --list システム (/etc/gitconfig) の設定 $ git config --system --list や、ユーザーごと (~/.gitconfig) の設定 $ git config --global --list など表示する対象を絞ることもできる。 ユーザ名とメール・アドレスを設定する $ git config --global user.name "John Doe" $ git config --global user.email "john.doe@example.com" コミットする時に記録されるユーザー名とメ
WordPress developer for Automattic, Linux fan, and all-around nerd I’ve spent a little more than a month working with Git now. I can honestly say that while there are many things that I like about Git, there are just as many things that I personally find to be a pain in the butt. Submodules specifically have managed to be a thorn in my side on many occasions. While the concept of submodules is sim
Git#は.NET製のオープンソース・ソフトウェア。Gitは開発以外でも利用できる場面が多い。かつてRCSのような個人向けバージョン管理システムがあったが、その代わりにもなるし、Windowsネットワークのような小規模な形でも利用が開始できる。サーバを立てたりする必要のあるバージョン管理に比べてごく手軽だ。 デモアプリケーションのリポジトリブラウザ そんなGitをWindowsでも使おうと思うとmsysGitを使うのが一般的だ。ただ使うだけならば良いが、他のソフトウェアから利用したり今後の拡張性を考えるなら.NET実装の方が可能性がありそうだ。それがGit#になる。 Git#はC#.NETで実装されたGitで、通常のGitコマンドと変わらない操作ができる。そのような使い方はもちろん、ライブラリとしてソフトウェア内部に組み込むことも考慮している。デモとして簡易的なリポジトリブラウザが付属して
Vivre dans la capitale de la France est le rêve de nombreuses personnes. Pour le réaliser, il faut louer un appartement dans cette ville dynamique. Ce projet peut rapidement devenir un casse-tête, si certaines erreurs sont commises durant la recherche du bien approprié. Les annonces immobilières sont généralement pléthoriques, et ceux qui veulent un logement ne savent pas toujours... L’utilisation
このドキュメントは Version Control for Designers の日本語訳であり、元のドキュメントと同じくソースコード管理に予備知識がまったくない人を想定している はじめに リポジトリの構造 ブランチ 作業の流れ ブランチを切る その他の便利なツール ベスト・プラクティス はじめに What have you done for me lately? バージョン管理、ソース管理やリビジョン管理とも呼ばれているものはあらゆる開発に必須である。なぜなら基本的にはメールやインスタント・メッセンジャーと同じようなコミュニケーションをとることができるツールでありながら、人々の会話ではなくソースコードを元にして機能することができるからだ。 バージョン管理 他のプログラマと簡単に意思の疎通を図ることができる 開発チームでコードを共有することができる デプロイしている「製品」バージョンを別個
インストール Windows で git を使う場合、cygwin か msysgit を使うのが一般的。 git だけ使えればいいので、msysgit をチョイス。 インストールはここに従った。 日本語環境を構築する為の注意書きがあるが、リンクが切れてたり、 設定の意味が解説されていなかったりするので、忘れないように書いておきます。 Git Bash 上で日本語入力 初期状態では、Git Bash 上で日本語入力が出来ない。*1 [git のインストールディレクトリ]/etc/inputrc に次の設定を追記。*2 set kanji-code utf-8 set convert-meta off set meta-flag on set output-meta on PAGER のマルチバイト対応 先のリンク先では、日本語対応 less を別途ダウンロードしていたが、 標準で入る le
git に関する文書。っても全部 http://git-scm.com/documentation にあるのなんだけど。とりあえず全部読んでおくべきなんだけど個人的にこの順番で読むと理解が進むと思う順に挙げる。てかつくづく導入の敷居が高い tool だな。と思ったけど習得曲線ののびが悪いだけで習熟する範囲はそんなに広くないから一度覚悟を決めてしまえば何とかなる感じ。まず local での操作を覚えてそれで生活しつつ branch や remote の管理を覚えていくというのが鉄板な気がするなぁ。 SVN Crash Course http://git-scm.com/course/svn.html svn 関係触ったことのあるひと ( TortoiseSVN 含む ) はまず真っ先に読むべき。というのも svn を使ったことのあるひとにとっては git は紛らわしい単語の使い方をしているの
みんなやってて今さらな感じですね． これまでおれおれスクリプトを使ってやっていたんですが，zsh-gitというプロジェクトで公開されているPROMPTテーマを使うとすごい楽に高機能なプロンプトにできました．インストール方法とかはREADMEと付属のzshrcを参照してね! 現在のブランチ名以外にも，untrackedなファイルがあると '!' を表示したり，modifiedなファイルがあると '?' を表示してくれたりするので，なかなか高機能です． ただ，ちょっと表示がうるさい感じだったのでちょっとカスタマイズして使っています． 不覚にもゆのっちに表情がついて良い感じです. このプロンプト設定ファイルはこちら
Git 公式 http://git.or.cz/gitwiki/GitFaq チートシート http://cheat.errtheblog.com/s/git git 全般 空ディレクトリを追加したいときってどうすんの (FAQ に書いてあるけど) できない。.gitignore ファイルをつくって add するとかするしかない。 「元に戻す」コマンド git-revertは指定したコミットと同じ状態に戻るようなパッチを作成・適用してコミットする。つまり、以前の状態に戻し、「戻した」という作業も変更履歴に残したい場合に使う。 git-resetはrevertと似ているが、新たなコミットは発生せず、変更履歴には残らない。マージをミスったり、直前にコミットした内容に実はしょぼいミスがあって修正したいときに使う。前者の場合は--hardを指定して作業ツリーの内容も元に戻すとよい。後者の場合は--
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
