git configをプロジェクトによって使い分ける - QiitaGit v2.13.0（2017/05/10リリース）でgit configにConditional includes（条件付きインクルード）という機能が実装され、特定のリポジトリに対して一括でgit configを適用できるようになりました。 会社用と個人用でプロファイルを使い分けたり、たまに使う設定をまとめて適用する場合などに役立ちそうです。 設定方法 includeIfセクションを使います。git configコマンドか、~/.gitconfigを直接編集して追記します。
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
超俺専用メモ「rubyのsvn->git gateway再構築方法」
一般化すれば他者にも有益な話題と思われるがとりあえずめどい。 方針 ありものをつかう回線に優しくてっとりばやくデータロスしないsetup OpenSSH multiple connection sharing以下の方式ではsvnサーバにつなぎに行っては「あ、やっぱ手元にあったわ」でコネクション切るというのを繰り返す感じなる。git-svn(1)頭悪いな。で、普通にそのままやるとSSHのセッションハンドシェイクが全体の時間に対して支配的になる上に、どう考えても回線の無駄なので、一旦作ったコネクションを使いまわすことで対応する。これはOpenSSHには普通に備わっている機能だ。~/.ssh/configに以下のように書いておく。 Host ci.ruby-lang.org User svn Hostname ci.ruby-lang.org IdentityFile ~/.ssh/id_rsa
Gitでマージしたバイナリファイルがconflictした場合の解決策｜DIGITAL SQUADブログ
Gitでマージしたバイナリファイルがconflictした場合の解決策 Gitでマージした際にバイナリファイルがコンフリクトした場合 現在いるブランチaにブランチbをマージした際に、db/development.sqlite3がコンフリクトした場合。 ブランチaの方を採用する場合 git checkout --ours db/development.sqlite3 ブランチbの方を採用する場合 git checkout --theirs db/development.sqlite3 その後にgit commit する。 ちなみにコンフリクトしたファイルの確認はgit ls-files -u タグ：Rails git Tweet posted by digital-squad at 2010年05月25日 11時20分 | Comment(0) | TrackBack(0) | Git この記
git-utils 0.0.1リリース - 2010-05-18 - ククログ
git関連の様々なユーティリティソフトウェアのパッケージであるgit-utilsのバージョン0.0.1をリリースしました。このパッケージには、gitリポジトリ用のコミットメール送信スクリプトcommit-email.rbが入っています。以下からダウンロードできます。 packages.clear-code.comからダウンロード 概要 今回のリリースはgit-utilsの最初のリリースです。 このパッケージに同梱されているcommit-email.rbを使うことで、gitリポジトリにpushされたコミットのコミットメールを送信することができます。 gitでは複数のコミットを一度にリポジトリに追加することができます。これはpushと呼ばれています。commit-email.rbはインストールしたリポジトリに対してpushが発生する度に実行されます。そして、そのpushの中にあるコミットごとに
Git, タグを別名でフェッチする - <s>gnarl,</s>技術メモ”’<marquee><textarea>￥
動機 複数のremoteを設定したリポジトリがある。 $ git remote origin library-agit fetchのデフォルトだとタグも取得する。ところでタグの名前空間はどこからfetchするかによらず同じだ $ git tag my_tag $ git fetch library-a # library-aのタグが取得されrefs/tags/*へ $ git tag v1.0 v2.0 v2.1 v2.2 : : my_tagノーグッド。わかりにくいし、リモートが多数になると衝突しかねない。タグの名前空間を分けたい。 library-aのタグは library-a/v1.0 とかでアクセスできるようになるといいですね。 方法 git fetchに--no-tagsオプションを付けることでタグを取得しないことができる $ git fetch --no-tags librar
Rails のプラグインを subtree として管理する - ドレッシングのような
(2010.02.05 追記) read-tree する前に ours ストラテジで merge しなきゃダメだったようなので、その手順を追加した。 下のエントリではプラグインを submodule として管理する方法をメモした。 今回扱っているリポジトリは僕だけでなく他社の人 (それも git に慣れてない人) と一緒に弄るものなので、submodule を使うと clone するところから大変なことが分かった *1。 そこで、submodule の代わりに subtree merge と呼ばれる方法を採用することに変更した。これは、プラグインのリポジトリをブランチの中で管理し、master ブランチへ read-tree というコマンドでマージする方法。 restful_authentication を例に説明する。まず、本家を remote リポジトリとして追加する。 $ git r
git-cherry-pickを掘り下げる - idesaku blog
Gitにgit-cherry-pickという、知らなくてもなんとかなるが知っていると便利なコマンドがある。このコマンドを少し掘り下げてみた。 git-cherry-pick git-cherry-pickは、狙ったコミットの変更内容だけを現在のブランチに取り込む操作である。 例えば、つぎのような履歴を想定する。 ---A---B---C [master] \ \ ---X---Y [temp]ここで、YはCの後にコミットするほうが適切であることに気づいた。このとき、masterブランチで次のようにすると目的は達成される*1。 $ git cherry-pick YコミットYの変更内容だけをmasterのHEADに適用する、という操作である。このときXの変更内容は適用されない点がgit-mergeとは異なる。 ---A---B---C---Y' [master] \ \ ---X---Y [
Gitリポジトリ中のサブディレクトリを別のリポジトリにする - Pixel Pedals of Tomakomai
clone して filter-branch を使うと、サブディレクトリを別のリポジトリにできます。 例えば、/tmp/hoge にあるリポジトリに hoge と subdir/foo と言うファイルがあって、ログが以下とすると、 % git log -p --pretty=oneline ac27f0a1f18108cd81be52634b07228c6bb95a0b Added foofoo diff --git a/subdir/foo b/subdir/foo index 257cc56..b4c9d55 100644 --- a/subdir/foo +++ b/subdir/foo @@ -1 +1,2 @@ foo +foofoo a6cc83ca5cec477444f0d63359ef12dede648eb5 Added hogehoge diff --git a/hoge
MARC: Mailing list ARChives
Search: [] List [] Subjects [] Authors [] Bodies for list 'git' Set Page Width: [ 80 ] [ 90 ] [ 100 ] [ 120 ] Development Various development/programming languages and tools git git change-tracking tool 2024-09-01 - 2024-10-01 (1707 messages) 2024-08-01 - 2024-09-01 (2197 messages) 2024-07-01 - 2024-08-01 (1890 messages) 2024-06-01 - 2024-07-01 (1833 messages) 2024-05-01 - 2024-06-01 (2212 message
git-rerereのメモ - unpushの日記
git-rerereってなんかレレレのおじさんみたいですが(Reuse recorded resolution of conflicted merges だそうな)、同じような衝突を何度も起こす状況で使うととっても便利なようで、調べつつ、メモ。 Linusが言っている「無駄なマージコミットやめて」を実現するには、rebaseがあればいいよね、と思ってたんだけど、既に公開しているようなブランチとなると、rebaseするわけにもいきません。 でも途中でちょっとだけ本線とマージしてテストしてみたくなったり、マージした後でやり直して再度マージしてみたくなったりも、しがちです。 そうなるとキツいのが、分かりきってるようなコンフリクトの解消。同じようなマージを繰り返すと、同じように衝突してるところを何度も手で直す作業を繰り返しやるハメになって、泣きそうになります。かといってマージを限界まで我慢して一発
Git だろうと Mercurial だろうと、ブランチ名をzshのプロンプトにスマートに表示する方法 - mollifier delta blog
2012/12/13 追記 zsh 4.3.11 以降の新しい機能を使って改良しました。 -> 「zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する - Qiita」 最近Gitを使い始めた。で、ブランチとか使うようになって、今どのブランチにいるのかをzshのプロンプトに表示したくなってきた。「そういやそんなブログのエントリ、よく見かけるな」と思ってちょっと調べてみた。 gitコマンドを呼び出してなんかやってる例が多いけど、manを読んでたらzsh自体にそういうのが組み込まれてたので紹介。vcs_info ってのを使うと解決する。 zshrcの例 いきなりだけど zshrc の書き方の例。 autoload -Uz vcs_info zstyle ':vcs_info:*' formats '(%s)-[%b]' zstyl
git stash save で一時退避した変更を、誤って git stash clear で消してしまったときの回復法 - t-wada の日記（旧）
一年くらい前から git を使い始め、ここ半年くらいは毎日の開発に git を使っています。昨日 git stash という機能を使っている時に失敗してしまい、何人かの方にアドバイスいただくことによって無事回復することが出来たので、感謝の印として、そして運悪く同じ問題に遭遇してしまった人たち(私もまたやるかも)へのメモとして記しておきます。 御託はいいから、早く回復法を知りたい人のためのまとめ $ git fsck | awk '/dangling commit/ {print $3}' 候補の sha1 がいくつか出てくる(長く開発していると、結構多く候補が出てきます) $ git show --summary 候補のsha1 一つ一つの sha1 の内容を確認 $ git cherry-pick -n -m1 見つけたsha1 いきさつ 私の作業のやりかたでは、 タスク毎にブランチを切
シェルのプロンプトにgit「ブランチ」を表示するやつ - while (”im mirrored”);
git function prompt-git-head-name() { local git_dir="$(git rev-parse --git-dir 2>/dev/null)" if [ -z "$git_dir" ]; then return 1 fi local head_name='' local additional_info='' if [ -d "$git_dir/rebase-apply" ]; then if [ -f "$git_dir/rebase-apply/rebasing" ]; then additional_info="REBASE" elif [ -f "$git_dir/rebase-apply/applying" ]; then additional_info="AM" else additional_info="AM/REBASE" fi he
git-pull、git-pull --rebaseをめぐる冒険＋コンフリクトした場合の作業 - satoko's blog - s21g
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 git-pullで私なりの解釈で aha！が来たのでメモします。 これからは git-pull --rebaseにしよー 下記をそのままという感じなのですがｗ http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#using-git-rebase そういえばトッポさんが言ってた：git-pull --rebaseを使うといいよ git-pullよりgit-pull --rebaseを使うといいよ(ただしという注意(下記太字)があるのでその辺は注意。ほとんどの人は関係ないと思うんだけど。。。) Here's a tip for keeping up
Git(ギット)勉強会メモ - kinneko@転職先募集中の日記
さすがに開発者は的確な解説と、質問にもズバズバ答えるのだなぁ。 Gitのメンテナが日本人の方だったというのは、今回はじめて知りました。 プレゼン資料については、アメリカに帰られたらWebで公開されるということでしたが、PDFで分けてもらったので、ご希望の方がいれば送ります。中身は英語ですが(^^;。 # さっそくアップロードされたようです。http://www.kernel.org/~junio/200810-tut.pdf というわけで、twiterでメモを流していたけど、途中で挫折したので、手元のメモを貼っておきます。 間違いがあったら指摘してね。 自分用メモなので、意味不明なとこはご勘弁を。 gitギット。イギリス英語で「やなやつ」。 kernel bitkeeper商用のバージョン管理システムを使っていた。 方針がかわって、無料で使えなくなってしまった。 svnを使うの？cvsを使
git bisectの使いかた - walf443's blog
gitを話を聞きに第33回git勉強会に行ってきました。 詳しいまとめは http://d.hatena.ne.jp/conceal-rs/20080928/1222612534 http://wota.jp/ac/?date=20080928#p01 などがあるので割愛します。 git stashの話が出てきたときに、git stashがいつごろから入った機能なのか調べるにはどうしたらよいか?という話が出ていて、git bisectを使うと有効に探せるのではないか?とあまりgit bisectがわかってないながらも言ってみたので、できるのかどうか検証してみた。 まずはgitをgit clone. URLがgitgitですね。 git clone git://git.kernel.org/pub/scm/git/git.git git stashの機能がいつ入った機能かは知らないものとして
ヽ( ・∀・)ノくまくまー(2008-09-28) Rails勉強会＠東京第33回
いきなり Git オブジェクトの話からはじまる。オブジェクトの概要に軽く触れてから、それから Git コマンドの説明に移るのだろうと思っていたら、そのまま関係性や参照方法といったオブジェクトの深い話にどんどん落ちて行くのだった。これでGit未経験者はついて来れるのか？この人、正気か？とか心配していたが、一旦オブジェクトを理解したあとで、Git コマンドの話に移った瞬間、今まで漠然としていた Git に対する疑問が全て氷解していることに気付いた。なるほど、確かにオブジェクトの理解は重要だ。 ある程度Gitコマンドは知っていて、ある程度Gitを使えてるけど、時々起きるエラーの意味や復旧方法がわからない、というGit初心者にはぴったりの内容だった。そこから次のレベルに行くにはまさにGitオブジェクトの理解が必須だったのだ。残念ながら参加できなかった、でも興味がある！というGit初心者はYugui
Rails' Wiki - Rails勉強会＠東京第33回に参加してきた． - なんとなく日記
ここ最近の9月としては結構冷え込む中，30人ぐらいが Git のために集まりました．Git すごいよ，Git． 午前中は Git のお話 午後はそのとき決めることに まとめと感想 はてブのタグ RailsMeetingTokyo ぎっとであってじっとではない． いろんな使い方があるけど，やっぱ基本はあると言うことがわかった． 専門家(？)を呼んでの講演は非常に良かった．こういう異文化交流っていいよね． 分散ソースコード管理システム Git 岩松さん＠Debian JP Project の中の人 もともと OSC Sapporo で高橋会長が依頼したようだ はじめに Git は「じっと」じゃなくて「ぎっと」 使い方は人によってそれぞれ異なる 朝起きてまずすることは -> リポジトリのチェック Git のデータモデルや考え方 4つの階層 Working Copy index Local Rep
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git を使ったビルドテストについて