Git | excludeファイルにローカル環境だけ無視したいファイルを登録 - Tbpgr Blog
概要 excludeファイルにローカル環境だけ無視したいファイルを登録 内容 .gitignoreはバージョン管理の対象外にしたいファイルを登録することができます。 登録した内容はリポジトリで管理し、共同で利用しているユーザーと共有出来ます。 しかし、ローカル環境のみ自分独自の設定内容を保持したいファイルがある場合で .gitignoreでその状態を共有したくない場合があります。 そのような場合は .git/info/excludeにファイルを追加することでコミット対象外としつつ、他のメンバーと除外設定を 共有せずに済みます。 サンプル myfile.txtというファイルがコミットされずに存在しています。 このファイルを.git/info/excludeに追記し、除外対象とした後に git statusで確認を行います。 $git status # On branch master # U
QA＠IT サービス終了のお知らせ - ＠IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
git pullの詳細な挙動を追ってみる - hokaccha memo
git push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう？ $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ（master）にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ
git merge or rebase, ff or no-ff
Kazuho Oku @kazuho バージョン管理システムの目的は変更履歴を管理することなんだから、git rebase とか履歴を改変するコマンドは言うまでもなくダークサイド 2012-11-09 16:58:32
git rebaseって超便利じゃね？ - Seasons.NET
Gitでとても便利だと思っているのが、rebaseというコマンド。 ブランチを切った時点からオリジナルは刻一刻と変化していくわけで、 自分のブランチはあくまで現在最新のオリジナルに対するパッチである 必要がある場合は、このrebaseというコマンドを使って、オリジナル(HEAD)と マージすると、最新のオリジナル(HEAD)に対して、ブランチを切ったことになります。 これチョー便利じゃね？ 以下、git-rebaseから引用 git-rebase を使用して一連のパッチを最新に保つ リモート追跡ブランチ "origin" の上にブランチ "mywork" を作成し、幾つかコミットを作成したとします： $ git checkout -b mywork origin $ vi file.txt $ git commit $ vi otherfile.txt $ git commit ... m
図で分かるgit-rebase - アジャイルSEを目指すブログ
世間的に「Gitはコミットログを書き換えられてキモい」と言われ、肩身が狭いので git-rebase の説明を書いてみた。 git help から引用 まずは基本に忠実に、ヘルプを読みましょう。 git help rebase SYNOPSIS git rebase [-i | --interactive] [options] [--onto <newbase>] <upstream> [<branch>] git rebase [-i | --interactive] [options] --onto <newbase> --root [<branch>] git rebase --continue | --skip | --abort DESCRIPTION If <branch> is specified, git rebase will perform an automatic g
git rebaseのメモ - unpushの日記
ときどき間違うので。 大雑把に言うと、git rebase は「git reset + git cherry-pick × n回 を自動化したもの」と考えられる（適用するコミット群が少なければ、手動でreset & cherry-pickしても良いが、たくさんあるとそうもいかない） 好きな場所にresetして、好きな位置から好きな位置までのコミットを順次適用できる。 つまりコミットを並べ替えたり除外したり、「積み木を積み直す」ようなことが出来る。 git rebase ポピュラーな使い方。 現在のブランチをにreset から見て現在のブランチにだけ存在していたコミットを順に適用 適用されるコミット群は、から見て現在のブランチにだけ存在していたコミット、つまりgit log ..HEAD で出てくるコミット。 以下の例だとA、B、Cのコミットがreset後に適用される予定 A---B---C
普通のpatchコマンドで取り込めるdiffファイルをgitで作成する - kanonji’s diary
まとめ $ git diff --no-prefix HEAD~ > thisis.patch $ patch --dry-run -p0 < thisis.patch $ patch -p0 < thisis.patch git diffに--no-prefixをつける事で、普通のpatchで当てられるパッチファイルを出力できます。この例ではHEADの1個前*1からHEAD*2までのパッチです。 普通のpatchコマンドのほうの知識があまり無くて-p0がいまいちよく分からないんですが、git diff --no-prefixで作成したパッチファイルを当てるには必要みたいです。--dry-runは、実際には当てないけど当てた場合の結果を出力します。なので、まずは--dry-runで確認して、問題が無ければ実際にパッチを当てます。 エントリー書いた後に教えてもらった補足 patch -p1の
git reset についてもまとめてみる - murankの日記
前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは？ HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは？ --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
[Git] Fork 元の単独のコミットを取り込む cherry-pick
メモ程度に。Github で Fork 元からまとめて pull したり rebase するのではなく、単一のコミットだけ持ってきたいときに cherry-pick というコマンドが使えるようだ。 リモートのレポジトリをローカルに追加してから cherry-pick で取り込みたいコミットのハッシュを指定して取り込む。 git remote add upstream git://github.com/concrete5/concrete5.git git fetch upstream git cherry-pick bf926.... 今後何か問題が出たらこの記事で報告します。 詳細はこちらを参考にしました。 [技術][Git]git-cherry-pickを掘り下げる git-cherry-pick(1) Manual Page
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のベストプラクティクスっぽいもの - Sexually Knowing
tbaggery - A Note About Git Commit Messages A successful Git branching model » nvie.com Commit Often, Perfect Later, Publish Once—Git Best Practices だいたいこれらに書いてあることを考えている。 基本的にGit Successful Branch Modelで運用する。git-flowを入れて使っているけど、手でやってもそんなに面倒ではないし好きなようにしたらよさそう。 Subversionを個人で使っていたころはブランチはよくわからないけど恐しいものだったけど、Gitを使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう
CUI な Git ブラウザ tig を入れてみた - Born Too Late
Git をなかなか使いこなせずにいる私ですが、これはいい ! コンソールから使える git ブラウザ、tig が超便利 Vim に近い操作感で使えるのが Vim 使いには非常に嬉しいところです。以下で、インストール方法と基本操作について紹介します。 インストール インストールは、まずソースコードからやってみたのですが、パッケージが存在することに気づいたので、 aptitude で入れ直しました。 sudo aptitude install tig はい、簡単ですね。 起動する カレントディレクトリを Git のワークツリーに移動して、 tig コマンドを実行します。 $ cd /path/to/work-tree $ tig ヘルプを表示する: h 何はともあれ、わからないことがあればとりあえず h を押してヘルプを調べましょう。 カーソルの移動: j, k Vim ユーザなら、何の問題も
git log - Webtech Walker
についてのメモ。 出力件数を指定する 出力件数を表示する。どちらもいっしょ。 $ git log -n 10 # 最新10件のログ $ git log -10 # 最新10件のログ 範囲指定 コミットの範囲を指定する $ git log HEAD~10..HEAD~5 # 10個前か5個前までのログ $ git log HEAD~10.. # 10個前から最新までのログ $ git log 3hg4390fj3..93jj23rn20 # ハッシュ値で範囲指定 パッチ形式で出力する -pでパッチ形式で出力する。 $ git log -p Authorから探す コミットした人を指定する。部分一致っぽい。 $ git log --author=hokamura # hokamuraを含むAuthorのログ コミット日時から探す 指定した時間以降のコミットを表示する。どちらもいっしょ。 $ gi
git初心者向けのTipsなど - os0x.blog
gitの基本的なcommandしか使ってないって人向けのtips集です。 エイリアスの設定 $ git config --global alias.co "checkout" とすると、 ~/.gitconfig に [alias] co = checkout のように追記されます。 このようにgit configを叩いてもいいですし、~/.gitconfigを直接編集しても大丈夫です。 とりあえず、 [alias] co = checkout # checkout長い… st = status -sb # シンプルなstatus pr = pull --rebase # pull するときにmergeコミットを作らない fo = fetch origin ro = rebase origin # branchでfoしてroすればmasterにrebaseできる rc = rebase -
はてなブログ | 無料ブログを作成しよう
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
たのしいGit - Nalsh's Notes
序 言うまでもないことだが、タイトルはジョークである。 そもそもバージョン管理は本来我々がしたい事ではない（一部の人を除く）。別に作りたいものがあり、そこでの作業を円滑に進めるためにバージョン管理するのだから、所詮はヤクの毛刈りである。さらに、Gitクライアントのへっぽこさも相まってなかなかに時間を食われる。この文書はそのような人々が、より円滑にGitを使えることを祈って書かれた。 なお、バージョン管理というのはとても複雑なシステムであるため、バージョン管理自体が目的な人には楽しい世界である。そのような人々はぜひGitやその他のバージョン管理システムのマニュアルやソースコードを読んでいただきたい。きっとその奥深い世界を堪能できることだろう。 Git概説 Gitはこれまでの旧来のバージョン管理システムとは一風違った設計で作られている。また、Git特有の概念も多い。なので、まずGitの概観を説
zsh で Git の作業コピーに変更があるかどうかをプロンプトに表示する方法 - mollifier delta blog
2012/12/13 追記 zsh 4.3.11 以降の新しい機能を使って改良しました。 -> 「zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する - Qiita」 Git を使ってファイルを編集した場合、それをいったんインデックスに追加(add)してその後コミットってのが基本的な流れになる。なんかいろいろやってると、ちゃんと add したのかどうかわかんなくなることがある。 そういうときは status コマンド使えばいいんだけど、以前エントリ書いた zsh の vcs_info の機能を使うといい感じにプロンプトに表示できるようになるので紹介する。 zshrc の書き方 こんな風に zshrc に書いておけば OK。 autoload -Uz add-zsh-hook autoload -Uz colors color
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20120506/p01/