git-ignoreというコマンドを書いた話 - ( ꒪⌓꒪) ゆるよろ日記
git-ignore add みたいのが欲しい— azu (@azu_re) August 24, 2014 ちょろっと書けそうだったので書いた。 yuroyoro/git-ignore · GitHub Demo Installation PATH通った場所においてくれ curl -sL https://raw.githubusercontent.com/yuroyoro/git-ignore/master/git-ignore > ~/bin/git-ignore Examples `git ignore add "pattern"`で、.gitignoreへ追加する。 $ git ignore add '*.log' .gitignoreから削除するには、`git ignore remove "pattern"`を実行する。 $ git ignore remove '*.log' a
リポジトリごとに user.name や user.email の設定を強制する - Qiita
社内やオープンソースのプロジェクトに並行して参加していると、gitconfig の user.name や user.email をリポジトリごとに切り替えたくなることがある。リポジトリを作るたびに git config user.name "My Name" すればいいのだが、 user.name が存在しないか空文字列だと環境変数 NAME の値を暗黙的に使う仕様になっているため、設定をうっかり忘れてしまうとなかなか気づけない。名前やメールアドレスを間違えたまま何度もコミットしてしまうと修正が厄介である。 Git 2.8以上 最近の Git で設定忘れを未然に防ぐには git config --global user.useConfigOnly true を実行する。これを設定するとユーザー情報について環境変数を暗黙に参照することがなくなる。グローバルな gitconfig で use
別のリポジトリの差分を取り込む - Git による版管理環境を構築する
Git で別のリポジトリからの差分を取り込むには、どのようにしたらいいのでしょう。 Subversion でいうところの "svn merge -r R1:R2 file:////svn/repo1" みたいなことをしたいのですけど、このような操作を Git で簡単に実現する方法がわかりませんでした。 とりあえず、このようなことを実現する方法として思いつくのが、修正を終えたリポジトリのワーキングコピーで "git format-patch" で差分を作った後、別のリポジトリのワーキングコピーで "git am" でそのパッチを適用するという流れでしたので、まずはこの方法で実現していってみたいと思います。 まず、作業を終えたリポジトリのワーキングコピーへ移動します。 そこで、"git log" で対象となるコミット ID を確認したら、次のコマンドを実行して、差分をファイルに書き出します。
めちゃくちゃにコンフリクトしたファイルを一歩一歩マージする方法 - Qiita
あるファイルに大量のコンフリクトが発生し解決が面倒なとき、パッチを使ってファイルに1コミットずつ変更を適用する方法を示す。この方法のメリットは： ファイルへの変更を1コミットずつ適用・コンフリクト解決することができる それぞれのコミットを適用する前に、コミットをパッチファイルの形で編集できる 注目するファイル以外への変更をいったん無視し、そのファイルに関係する変更に集中できる の3点である。複数コミットの変更が混ざった大量のコンフリクトマーカーを手作業で消すような状況に陥ったとき、この方法を使えばいくぶんかは楽にマージ作業を進められる。 概要 マージ中に特定のファイルに大量のコンフリクトが起きたら、マージを中止する。一時作業用ブランチを作り、そのファイルに1コミットずつパッチを当てて編集する。パッチを当て終わったらマージをやり直し、コンフリクト解決作業中に、コンフリクトしたファイルを一時作
git bisect で問題箇所を特定する - Qiita
以前は問題なく動いていたはずの機能が、最新版では動かなくなっている・・・。こんなときは、「どのコミットが問題を混入させてしまったのだろうか？」を知りたくなるでしょう。 これを手助けするのが git bisect コマンドです。git bisect コマンドは、二分探索によって問題箇所を特定します。 事前準備 最初に大事なことがひとつあります。それは、「問題がない（good）状態と問題がある（bad）状態を、確実に判定できるようにする」 ことです。 当然のことではありますが、ここがあやふやだと、二分探索をしても問題箇所をうまく特定できません。 可能なら、「テストスクリプトを1つ実行するだけで判定」できるようにしたほうが良いです。このとき、テストスクリプトは、git リポジトリからチェックアウトした作業ツリーに対して実行できるようにします（例えばソースからのビルド処理もテストスクリプトに含めま
Git - remove commits with empty changeset using filter-branch
How do I remove commits which have no changeset using git filter-branch? I rewrote my git history using: git filter-branch --tree-filter 'rm -r -f my_folder' -f HEAD this worked out well but now I have lots of commits with empty changesets. I would like to remove those commits. Preferably in msysgit. Rebasing is not really an option because I have over 4000 commits and half of them must be removed
gitで統合ブランチへ取り込まれたトピックブランチの一覧を抽出する | Webシステム開発／教育ソリューションのタイムインターメディア
問題 「トピックブランチをばんばん作ってある程度のところで統合ブランチへマージする」 という開発スタイルを行っていたとしましょう。 例えばバージョン1をベースにガリゴリとトピックブランチを作って統合ブランチへマージし、 一区切りついたところでバージョン2としてリリースするといった具合です。 マージするトピックの数が数個であれば特に問題はないのですが、 10や20になってくると git log を眺めてもどのトピックブランチが取り込まれているのか一目では分からなくなってきます。 例えば git log master..$topic の出力が空であれば $topic が取り込まれていないことは分かりますが、 10や20もトピックブランチがある状態ならばこんな方法で1個づつ調べる気は起きません。 どうにかして統合ブランチへ取り込まれたトピックブランチの一覧を抽出する方法はないでしょうか。 解決方
変更を一時的に退避！キメろgit stash - Qiita
gitは、とにかくトピックブランチを作成して作業する。だいたい機能追加とかバグ修正とかの単位でブランチを作って作業します。（ちゃんとやってますよね？） なので、作業の途中で別の修正を優先してお願いっ！なんて言われたときは、別のブランチに切り替えて作業をする必要がでてくる。そんな時に変更を一時的に退避しておくことのできる機能、それがstashである。 では、早速使い方 まだcommitしていない状態の変更ファイル（addしてる or add していない)が存在する状況で、次のコマンドを実行すると変更ファイルを退避することができる。 ※saveは、省略することもできる。 これでファイルの退避完了！git statusとか見てみると変更状態であったファイルがなくなっている。この状態なら安心してブランチを切り替えることもできる。めでたしめでたし。 と、退避だけならこれで終わりだけど、次につかうとき
git symbolic-ref を利用して、ブランチに対して別名をつけることができて墓ドル - ( ꒪⌓꒪) ゆるよろ日記
何が便利かというと、今git-flowで運用しているのだけど、リリースブランチを常に同じブランチ名で参照できるようになってうれしい。 例えば、次回にリリースブランチが'release/1.17.0'だとすると、'git symbolic-ref rc release/1.17.0'とすることで、'rc'という名前で参照できる。 エイリアス先の'release/1.17.0'のHEADが先に進んでも、rcも常に同じHEADを参照するので、一貫して'rc'という名前で扱える。 $ git symbolic-ref rc refs/heads/release/1.17.0 これだけだとありがたみがない。が、無事に1.17.0がリリースされて、その次のリリースブランチがrelease/1.18.0になったときでも、'git symbolic-ref rc release/1.18.0'でエイリアス
空のディレクトリをgitで管理するには.gitkeepを使う（.gitignoreは使わない） - YomuKaku Memo
gitを使ってバージョン管理を行う際に、プロジェクト全体のツリー構造をそのまま管理する目的で、中身が何も無いディレクトリもgitの管理下に置きたい場合があります。 何も対応しないと、gitは空のディレクトリをバージョン管理してくれません。 中身が空のディレクトリをgitのバージョン管理下に入れるためには、当該の空ディレクトリの中に .gitkeep というファイルを作成してからgitで管理します。 実例 Railsのアプリケーションを新しく作成する場合を例に用います。 $ rails new test_application $ cd test_application $ ls -l vendor/plugins （vendor/pluginsは中身が空なので何も出力されません） 上のように、vendor/pluginsは中身が空です。 このディレクトリをgitの管理下に入れるために、次の
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
git diffで比較した差分のファイルだけを抽出するスクリプト - hogehoge foobar Blog Style Beta
HTML等をgitで管理していると、サーバーへのアップロード用のファイルとしてコミットした差分のファイルだけを抽出したい事があります。 「git diff」で差分の表示は出来るのですが、ディレクトリ構造を保持した状態でのファイル抽出みたいな事は出来ないようだったので、Perlでスクリプトを書いてみました。 ※bashとかでも書けると思いますが、なんとなくPerlで書いてみました。 「git diff --name-only」で差分のファイル名を取得 普通にgit diffを使うと・・・ gitでの差分の表示には「git diff」を使用しますが、そのまま使うとファイルの内容まで表示されてしまいます。 $ git diff HEAD^ diff --git a/bar.txt b/bar.txt new file mode 100755 index 0000000..9e74262 ---
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
特定のブランチの rebase を禁止する git hook 書いた - ヤルキデナイズド
2つのブランチの分岐点をみつけるgit show-branch --merge-base - Qiita
More Git and GitHub Secrets
Git でマージ済みのブランチを一括削除する - Qiita
git add したあと、commit するの忘れてて reset --hard しちゃったけど、取り戻したい #git - Qiita [キータ]![git add したあと、commit するの忘れてて reset --hard しちゃったけど、取り戻したい #git - Qiita [キータ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/3497e19aeb570cec80fba59ff266cacc1cb77b64/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9Z2l0JTIwYWRkJTIwJUUzJTgxJTk3JUUzJTgxJTlGJUUzJTgxJTgyJUUzJTgxJUE4JUUzJTgwJTgxY29tbWl0JTIwJUUzJTgxJTk5JUUzJTgyJThCJUUzJTgxJUFFJUU1JUJGJTk4JUUzJTgyJThDJUUzJTgxJUE2JUUzJTgxJUE2JTIwcmVzZXQlMjAtLWhhcmQlMjAlRTMlODElOTclRTMlODElQTElRTMlODIlODMlRTMlODElQTMlRTMlODElOUYlRTMlODElOTElRTMlODElQTklRTMlODAlODElRTUlOEYlOTYlRTMlODIlOEElRTYlODglQkIlRTMlODElOTclRTMlODElOUYlRTMlODElODQmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPTZhNjcxZDUwM2Y2MmU5YmMyZmQyMzcxNTEzZGJiNmMz%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB5b3NoaW9yaSZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ZmNjY2MxYWI5ZmIyNThkNmU1NDY1YTUwMDRiZjcyN2E%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4gQ09PS1BBRA%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25231E2121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D373832f692384daa95854903f5b66d98)
bayashi.jp
git fetch-pulls - tokuhirom's blog