異国の友人たちへ、また会う日まで 2024年ゴールデンウィーク。5年ぶりにウズベキスタン旅行に行ってきたので、旅の模様をデイリーポータルZに綴りました。ウズベク旅行記はこれが3本目。 dailyportalz.jp dailyportalz.jp dailyportalz.jp (↑New!) おかげさまでどの記事も多くの方にお読みいただき、…
![はてなブログ | 無料ブログを作成しよう](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
I recently had a fun idea, that I wanted to try and implement for PHPUnit. I really like coloured console output. PHPUnit already has the option for coloured output, but I wanted more. I wanted to get coloured text for F, E, S, and I that showed up in the test run progress. I also figured this might be something others might want, and that I’d create a patch for PHPUnit. This of course meant I’d n
2011年10月1日のminami.rbの第9回勉強会で発表したgitのtipsのプレゼン資料です。Read less
hg と git のコマンド相違点 似てるようで違う hg と git の違いのメモ。 基本 working directory : バージョン管理対象のファイルを置くディレクトリ。バージョン管理対象にしないオブジェクトファイル等を一緒に置いても良い。 repository : working directory の一番上にある、.hg (hg の場合) または .git (git の場合) ディレクトリの中身。バージョン管理に関する情報、履歴等が置かれる。 あるところにあるリポジトリを追いかけるだけの使い方 たとえば www.kernel.org の Linus のリポジトリを追いかけるとか、そんな使い方の場合。一番シンプルな例。 最初の取得 (リポジトリを取得し作業ディレクトリに最新の内容を展開する) hg clone url [dir] git clone url [dir] 最新リ
Vim プラグインを pathogen で管理してきたけど… 今では後発の Vundle の方が主流ぽいので、pathogen から Vundle に移行することにしました。Vundle は Ruby の Bundle をインスパイアしていて、GitHub や vimscripts からプラグインファイルをダウンロードしてインストールできるという。なにそのステキ機能。スバラシイ。 私のマシンは Windows なので、Windows で Vundle を導入した手順を書いていきます。 まずは下準備 Vundle が GitHub や vimscripts からプラグインをダウンロードするには、git と curl コマンドが必要。まず git を msysgit でインストール。 msysgit - Git for Windows - Google Project Hosting そして、
GitBoxはDropboxをGitリポジトリサーバ化するソフトウェア。 GitBoxはShellスクリプトのオープンソース・ソフトウェア。Gitは分散化リポジトリシステムなので、ネットワークがなくともリポジトリが参照できる。そこをメインにしてしまえばローカルだけでバージョン管理が可能だ。だが複数人になればやはりネットワークを介したリポジトリが欲しいと思うだろう。 利用中 そのためにサーバを立てるのは面倒だ。Githubを使う手もあるが、今はオープンソースでないとプライベートなリポジトリは作れない。そこで使ってみたいのがGitBox、Dropboxを使ったGitリポジトリサーバだ。 GitBoxはWindows/Mac OSX/Linuxに対応したソフトウェアだ。専用のコマンドでDropbox内にリポジトリを作成し、クローンも行ってくれる。後は通常通りファイルを編集したりコミットした後「g
前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは? HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは? --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
gitでは、ちょっとした開発やバグフィックスなどbranchを使用して開発する。 このために、頻繁にマージしたくなる。 ただし、ここであえて「マージ」と記述したのは、”git merge”のことではなく、 変更した内容を反映させたいという意味で「マージ」だ。 そのマージする際の、いろいろな手順にを覚書として記録しておく。 1)ブランチのコミットした内容も含めてマージする git merge [ブランチ名] 2)ブランチの修正した内容すべての変更を取り込む つまり、1)でやったこととほぼ同様だが、コミットはしない。 git merge --squash [ブランチ名] これで、ブランチ上で行ったすべての変更が1つになって取り込まれる。 しかしながら、これでは、せっかく何度もブランチ上で育てたログが無駄になってしまう。 ログとソースをきれいにした状態で再作成したい場合にはこれではこまるの
きっかけ A successful Git branching model » nvie.com ここらあたりを見て、--no-ffつけときゃいいんだなーと深く考えずに使ってたら、--squashつけると安全とかなんとかチラ聞きして混乱しまくったので調べてみた。 とりあえずman。 man git-merge ... --ff, --no-ff Do not generate a merge commit if the merge resolved as a fast-forward, only update the branch pointer. This is the default behavior of git-merge. With --no-ff Generate a merge commit even if the merge resolved as a fast-forwa
git.jsはnode.jsで作られたWebベースのGitリポジトリブラウザ。 git.jsはnode.js/JavaScript製のオープンソース・ソフトウェア。Gitの面白い所は個々にリポジトリがあることだ。それによって分散化を実現し、かつオフラインでも開発ができるようになった。リポジトリにはこれまでの開発が全て詰まっており、いつでも参照できるのが嬉しい。 ログ Gitリポジトリを取り込んでしまえば、リポジトリを操作するために都度ネットワークアクセスする必要もない。リポジトリブラウザが高速動作するのはとても良い。今回紹介するのはWebベース、JavaScript製のGitリポジトリブラウザであるgit.jsだ。 git.jsはサーバサイドでローカルのGitリポジトリの情報を読み込みつつ、それをWebブラウザ上で表示する仕組みになっている。node.jsを使っているのでどちらもJavaS
でbareなリポジトリができて、さらに $ git fetch --allだけでbareリポジトリのアップデートができる。 bareリポジトリからアップデートしたい時に便利。 別のやり方 --mirrorは実際これと同じことをしてるっぽい(たぶん) $ git clone --bare {uri} $ cd {dir} $ git config remote.origin.fetch '+refs/*:refs/*' $ git config remote.origin.url $uri $ git config remote.origin.mirror true 関連エントリ bareリポジトリから更新する方法 - Humanity
hub · the command-line wrapper for git gitコマンドだと、ローカルのgitをごにょごにょするに限られる。でも、gitユーザならgithub使ってるでしょ。github上でのリポジトリの作成もコマンドラインからやりたくなるでしょ。 Macには公式GUIクライアントがあって、そこからgithubコマンドを入れられたりもします。しかし、そのコマンドはGUIクライアントを起動するためのもの。GUIクライアントがあっても悪くないけど、CUIでできることをわざわざGUIでする必要もないですね。 hub インストール $ brew install hub その他のインストール方法は冒頭のリンク先を参照ください。 リモートリポジトリの作成 $ hub create コマンドひとつでgithub上にリポジトリを作ってくれる。もちろん、remotes/orignも設定し
当然、ターミナルのプロンプトには表示させてますよね?zshならvcs_infoとか使えばいいですし。では、Vimはどうですか?各種git操作はVimからしないって?甘い、甘い。 git の branch を vim のステータスラインに表示 - #生存戦略 、それは - subtech 2008年3月のエントリですが、大変そうですね。でも今なら簡単です!fugitive を使えばいいんです!! ギットギトなVimmerにはすっかりお馴染みかもしれないfugitiveです。それ自体は VimmerなGit使いはfugitive.vimを今すぐ入れたほうがいい - SELECT * FROM life; や Vim-users.jp - Hack #219: Gitを使う2 – Fugitive.vim あたりが詳しいです。 :Gstatusからのstage/unstageが便利すぎますね!
I bought a new MacBook Pro and installed the applications list below in order. On my old MacBook, also running OS X 10.6.6, I didn't have /usr/bin/git, however, on the new MacBook Pro, I do. The only differences that I can think of between the two systems are: New MacBook Pro has Xcode 4 vs. Xcode 3 on old MacBook New MacBook Pro installed git using homebrew vs. old MacBook installed [git-osx-inst
Using the :Git command, you can run any arbitrary git command from inside Vim. I prefer to switch to the shell for anything that generates a log of output, such as git log for example. But commands that generate little or no output are fair game for running from inside Vim (:Git checkout -b experimental for example). At Vim’s command line, the % symbol has a special meaning: it expands to the full
みなさん、Git使ってますか?僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
みなさんバージョンコントロールしてますか? 人生もバージョンコントロールしたいですね. zsh 上でバージョンコントロールを扱う場合に便利な vcs_info の使い方です. しかしながら自分で自分の使う VCS を使ってがりがりスクリプト書いたほうがいいような気もしますが気のせいです. 以下のようなものを $ZDOTDIR/.zshrc に書くだけです PROMPT のあたりは各自調整のこと. setopt prompt_subst autoload -Uz add-zsh-hook autoload -Uz vcs_info zstyle ':vcs_info:*' formats '%s' '%b' '%i' '%c' '%u' zstyle ':vcs_info:*' actionformats '%s' '%b' '%i' '%c' '%u' '%a' zstyle ':vcs_
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く