Untracked Files を削除する - by shigemk2git/git覚書 - TOBY SOFT wiki git clean --dry-run untrackedになっているファイル(addでindexに入っていないファイル)を削除するgit clearnで、何が削除されるかを確認する。 git clean -f untrackedになっているファイルを実際に削除する。--dry-runで確認してからね。ディレクトリは対象にならない。ディレクトリも削除する場合は -d も付加する。 まずdry-runをやること。何が死ぬか分からないからね。
gitのmerge-commitをrevertする - 車輪を再発明 / koba04の日記
これまでtopic branchをmergeするときはrebaseしてfast-forwardな状態でmergeするか、merge --squashして何かあった時にすぐに戻せるようにと考えていたのですが、そもそもmergeを簡単にrevert出来れば問題ないしどうやるのかなぁと思って調べたところ、revert -mオプションで出来るんですね。 http://qiita.com/items/41b724a1c3569044372c (mergeした記録を残す必要がないときはfast-forwardなmergeでもいいと思いますがその辺りの議論は http://togetter.com/li/407277 を) mergeコミットを取り消したい場合 % git revert -m 1 mergeコミットのSHA1という感じでやれば出来るのですが-mの後の数値ってなんだということで色々試してみ
Git チームワークフロー: マージ (merge)、それともリベース (rebase) ? | Atlassian Japan 公式ブログ | アトラシアン株式会社
質問は簡単です。git と フィーチャーブランチ を利用しているソフトウェアチームにとって、完了済みの作業を開発のメインラインに取り込む最良の方法は何でしょうか？これは、確固たる意見を持つ両陣営によって繰り返し展開されている議論の一つですが、やはり議論には最低限の配慮を持って対応したいものです。 (その他の激しい議論の例としてはこれがあります: The Internet)。 リベースを行って、リポジトリの履歴をフラットかつクリーンに保つべきでしょうか？それとも、可読性と明晰さを犠牲にする事でトレーサビリティを得られる、マージを行うべきでしょうか？( ファストフォワード マージを禁止するなど。) 議論 このトピックは、vim と Emacs や Linux と BSD ほどまでには有名な論争の的とはなっていないものの、双方共に遠慮なく意見を述べ合っています。 all-things-git に
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう
Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう Jenkin developers accidentally do "git push --force" to over 150 repos on github | Hacker News Jenkinsの開発者、Luca Milanesioによって、Jenkinsの多くのgitレポジトリに対してpushが行われた。不思議なことに、pushをしたというのに変更点はほとんどみられない。一体ルカは何をやったのだ。 Dominik Bartholdi やあみんな、とくにルカ。 昨日、GitHub上のJenkinsの多くのレポジトリ（50以上）に、なにか変なことが起こった。 どうやら、Luca Mmilanesioが、何の変更もないのに、たくさんのたくさんのレポジトリにpushしたらしいのだ。
[Git] HEADの代わりに@が使えるようになったＹＯ！ · DQNEO日記
Git 1.8.5から、HEADと書くかわりに@が使えるようになったようです。 Instead of typing four capital letters "HEAD", you can say "@" now, e.g. "git log @". https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.5.txt 試してみた git log $ git log -1 @ commit db9bdfbeb044f73a01f6325f4ad61413666a2ce0 Author: Junio C Hamano <gitster@*****.***> Date: Fri Oct 18 13:53:05 2013 -0700 Update draft release notes to 1.8.5 Signed-of
git-gutterと git-gutter+の違い - Shohei Yoshida's Diary
hunkを stageする機能の実装で悩んでいるときに, git-gutter+だと 実装されているのかなと思って確認したところ実装されていて, その他の 部分も見てみるとおぉと思ったことがあったので, ここらで git-gutter との違いを示しておこうかと思います. git-gutter+のリポジトリ https://github.com/nonsequitur/git-gutter-plus forkの経緯 git-gutter+は git-gutterから forkしたプロジェクトです. forkの経緯は git-gutter+の作者の方が高速化(厳密には低速化の防止)の ための Pull Requestを私が rejectしたことです. そのパッチはかなり 巨大で既存の挙動をいろいろ変えるものでした. rejectした理由は, 私が外せないと思った機能が除去されていたことと,
/etc以下のファイルの変更をこっそりgitでトレースするツール - めもめも
・・・というと、「それってetckeeperでできるよ」という返答が高確率で返ってくるのですが、etckeeperの場合は、/etc以下を直接、バージョン管理システムの管理対象にして、システム管理者が意識的にコミットする形になります。 そうではなくて、たとえば、標準構成のLinuxの環境を利用者に貸し出して、自由にカスタマイズして使ってもらうのだけど、何か問題がおきて問い合わせがあった時に、サポート担当者が過去の設定変更の履歴を追えると便利じゃない？ というような利用シーンを想定しています。なので、利用者には存在を意識させずに、裏でこっそり差分を記録してけるといいかな、という感じです。 というようなことを３分ぐらい考えて書いたのが下記のスクリプト。 etctrace.sh #!/bin/sh TARGET=/etc REPODIR=/backup/etcrepo mkdir -p $REP
Gitを使ったデザイナーとプログラマの協業について話してきた #P4D #phpcon2013 - 納豆には卵を入れる派です。
常連プログラマがほぼ Rubyist しかいないP4Dなのですが、なぜかPHPカンファレンスで枠をいただいたとのことで、デザイナーとGitについて話し合ってみようという企画に参加してきました。 「生煮えぷるり」をプログラマとデザイナーの間で行ったり来たりさせる話 Pull Request 4 Designers - GitHubを使ったプログラマとデザイナーのイテレーティブな開発フロー// Speaker Deck GitHubを使った、実際のプログラマとデザイナーの協業の様子を見てもらおうということで、私がお手伝いさせていただいている、[https://forkwell.com:title=Forkwell] と [https://jobs.forkwell.com:title=Forkwell Jobs] での開発の様子を例にお話させていただきました。 補足とか 「生煮えぷるり」という
git/git rebaseを元に戻す方法 - TOBY SOFT wiki
例 † git rebaseの有効性は何故つかうか？は『Pro Git - Pro Git 3.6 Git のブランチ機能 リベース』 や ../git-rebase を見ていただくとしまして…。 さて、例えばmasterに修正を加えているオレオレ・カスタマイズ済みなmy_customブランチがあるとします。 このたびmasterが新しく更新されたので、my_customもmasterの変更に追従したいなと思いました。 そこで、git rebaseを使いmy_customをかつてのmasterからブランチを切った起点ではなく、あたらしく更新された今のmasterを起点に切り替えたいとします。（つまり、新しいmasterにmy_custom独自の差分パッチを再度当てた状態にしたい） ということで、 $ git checkout my_other_custom $ git rebase mas
新しい magit向け magit-statusの設定 - Shohei Yoshida's Diary
https://github.com/magit/magit magitが新しくなって, コミットメッセージを今まで独自のものから git-commit-modeを使うようになりました. そのせいかどうかは断定 できないんですが, commitメッセージを書き終えて, C-c C-cで それを反映させた後の Window構成が不安定になってしまったので, その対応(軽減するという程度のものかもしれません). 以前はこんなことなかったんですけどね. まあ他に任せられるところは 他に任せるという方針なんでしょうかね. コード multiple cursor等で有名なMagnar Sveenさんの設定そのものです。 (defadvice magit-status (around magit-fullscreen activate) (window-configuration-to-registe
git-rerereのメモ - unpushの日記
git-rerereってなんかレレレのおじさんみたいですが(Reuse recorded resolution of conflicted merges だそうな)、同じような衝突を何度も起こす状況で使うととっても便利なようで、調べつつ、メモ。 Linusが言っている「無駄なマージコミットやめて」を実現するには、rebaseがあればいいよね、と思ってたんだけど、既に公開しているようなブランチとなると、rebaseするわけにもいきません。 でも途中でちょっとだけ本線とマージしてテストしてみたくなったり、マージした後でやり直して再度マージしてみたくなったりも、しがちです。 そうなるとキツいのが、分かりきってるようなコンフリクトの解消。同じようなマージを繰り返すと、同じように衝突してるところを何度も手で直す作業を繰り返しやるハメになって、泣きそうになります。かといってマージを限界まで我慢して一発
Git ライフを快適にする知られざるコマンドたち
Git 初心者〜中級者に向けて、目立たないけど便利なコマンドを紹介します。
rebase について - ぐるぐる～
rebase 便利だよ、というだけのエントリです。 AA で書いてる部分は時間があれば画像に置き換えます。 rebase とは ブランチを作成した場所を変更することと理解しています。つまり、そのブランチの「親」を変更する、ということです。 もう少し動作に踏み込むと、指定したコミットの後ろに現在のブランチで行ったコミットをリプレイするように適用します*1。単なるリプレイではなく、その過程をいじくれるのが rebase のすごいところです。 単純な rebase はたとえばこんな感じです。 以下のようなリポジトリの状態があったとして (現在チェックアウトされているブランチは dev ということを表すのに * を使っています)、 1---2---3 *dev / A---B---C---D master次のコマンドを実行します。 $ git rebase masterこれにより、リポジトリの状態
Pro Git 日本語版電子書籍公開サイト
| 書籍紹介 | サイトの目的 | ダウンロード | 更新情報 | 謝辞 | お問い合わせ | 書籍紹介 Git は、 Linux カーネル開発のために Linus Torvalds さんが2005年に公開した分散型バージョン管理システムです。スタートアップのような小規模組織からGoogle、 IBM のような巨大企業で、また数多くのオープンソースプロジェクトで利用されています。現在の Git 開発は、濱野純さんを中心としたコミュニティによって非常に活発に行われています。 本書 Pro Git は、2009年に Apress から初版が、2014年に第2版が出版された、Git の解説書です。著者の Scott Chacon さんは、GitHub 社の CIO、Git のエバンジェリストであり、Git 公式サイトの管理者でもあります。 本書の内容は、出版以降も有志により頻繁に更新されており、
第3回 ブランチvs.フラグ | gihyo.jp
とっておきの変更 ソフトウェアをいつでもリリースできるようにしろと求める継続的デリバリの広まりにより、毎日のようにソフトウェアがリリースされるようになりました。早いうちからコードを野にさらせば、隠れた問題を前もって見つけることができるからです。 短いリリース間隔に身を置くと気づくことがあります。「リリースできること」と「リリースしたいこと」は、必ずしも一致しないのです。たとえば大規模なビジュアルデザインの変更やとっておきの新機能を想像してみましょう。こうした粒度の大きい変更は、たとえ動作する、つまりリリース可能な状態でも、そのまま衆目にさらしたいとは限りません。期待を裏切らない形でお披露目したい、とっておきの変更があります。息を飲む新しい体験がもたらすユーザの驚きや喜びも、ソフトウェアにとっては大切な財産だからです。 とっておきの変更を仕上げるには時間がかかります。一方で、その仕上げが終
git rebaseを使うときのルール | Yakst
Re: [git pull] drm-next Linus Torvalds Sun, 29 Mar 2009 14:48:18 -0700 (訳注 : Daveのrebaseのやり方が好みでないというLinusに対して) > 2009年5月29日(日曜日) Dave Airlieの発言 > > 今から自分がしようとしているのは、直線じゃないツリーを送ろうとしているだけだ。 > パッチを自分の次のツリーにマージする時はいつでも、そこにそれがあるからだ。 > 自分は、Ericのツリーを自分のツリーに直接プルして、その結果を送ろうとしている。 > きれいなマージ履歴について注意しているとは思っているけど、前に言ったように、 > カーネルツリーに関してのドキュメントが何もない状態では、君がどうしたいのか > 本当のところは今の今まで分からないよ。 自分が求めているのは、きれいな履歴だ。でも、それ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
submoduleの削除 - 呆備録
Blogger
How to use git mv from magit?
git pullする前にローカルレポジトリにどんな変更が行われるか確認する - （ひ）メモ
