Uses of git
GIT is a distributed version control created by Linus Torvalds in 2005. After linux it is one of the most influential program written by Linus and it changed the way people think about version control systems. Eventhough originally intended to be used as a source code management system, now git has widespread use other than managing the source code. Git when used with other tools solves various pr
Gitで不適切なコミットメッセージを削除した公開リポジトリを作る - 2012-01-05 - ククログ
分散バージョン管理システムのGitには様々なサブコマンドがありますが、その中の1つである git filter-branch を使用すると、過去のコミットを完全に無かった事にしてしまうなどの強力なコミット履歴の編集が可能となります。大きなリポジトリの特定のディレクトリ以下の内容をコミット履歴付きで別の小さなリポジトリとして取り出したり、ファイルの中に書かれていた生のパスワードを履歴の中から消去したり、というのはよく紹介される例です。 このエントリでは別の例として、コミットメッセージだけを後からまとめて修正する手順をご紹介しましょう。 元々非公開なプロジェクトとして開発を進めていたものを、公開リポジトリに移動したいとなると、やはり機密情報は完全に取り除いておく必要があります。リポジトリに格納されているファイルそのものの内容の編集方法については上記の例で解説されていますが、それ以外の場合として
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 -
msysGit（Git for Windows）がいよいよ公式に UTF-8 をサポート！ - てっく煮ブログ
git最近、Git について勉強しています。Windows で Git をやるなら Cygwin と msysGit（Git for Windows） がメジャーなようです。Cygwin Git のいいとこ悪いとこCygwin は UTF-8 な日本語ファイル名にも対応しており、Cygwin の中で閉じて Git を使っている分には何不自由なく使えるのでお勧めです。ただし、次のような悲しいポイントがあります。 Cygwin 版 Git は、Windows 向けの GUI な Git ソフト(TortoiseGit や Git Extensions)との相性が悪い Windows のエディタやマージツールと連携しようとするとパスのポリシーが違うのでうまくいかないnkf を噛ませようとしても、Cygwin 用の nkf バイナリは公式配布されておらず、わざわざ Cygwin 上で make す
Tig(text-mode interface for git)を使う
twitterで流れてきたリンクに、CUIからgitを使うためのツールについての情報があった。早速試してみたらかなり便利だったので紹介してみる。 インストール普通にソースコードを取得してビルド / インストールする。記事の時点での最新版0.16.2を使用したが、実際に試すときはreleasesページから最新のリリースを取得したほうがいいだろう。 % wget http://jonas.nitro.dk/tig/releases/tig-0.16.2.tar.gz % tar -zxvf tig-0.16.2.tar.gz % cd tig-0.16.2/ % ./configure # (snip) configure: error: ncurses not found
git add -p のときの e(手動編集) - 肉とビールとパンケーキ by @sotarok
自分ではあまり add -p の e ってつかったことなかったんだけど友達がよくわからんってことだったので調べてみた。 以下のような diff を add -p して、 e してみます。 $ git add -p diff --git a/fuga b/fuga index 1a39df0..5bc676d 100644 --- a/fuga +++ b/fuga @@ -1,5 +1,5 @@ // hoge -fuga piyo hogera +fugera Stage this hunk [y,n,q,a,d,/,s,e,?]? e で、エディタが起動するわけです。以下のような感じで書いてあります。 # Manual hunk edit mode -- see bottom for a quick guide @@ -1,5 +1,5 @@ // hoge -fuga piyo ho
図解 Git
もし図の表示がおかしかったら、このページの SVGでないバージョンを試して下さい。 SVG の画像処理を中止しています。 (SVG の画像処理を再開) このページのオリジナルは、Mark Lodato さんが執筆した A Visual Git Referenceです。 このページでは、よく使われる git のコマンドを簡潔に図を用いて説明します。 git について少し知識があるなら、このページはその知識を整理するのに役立つかもしれません。このページがどのようにして作られたのか興味があるなら、私のGitHub リポジトリを見て下さい。(日本語訳の GitHub リポジトリ) 内容 基本的な使い方 凡例 コマンドの詳細 Diff Commit Checkout 分離HEADでの commit Reset Merge Cherry Pick Rebase 技術メモ 基本的な使い方 上記4つのコマ
ステージを理解して git をもっと便利に使う(その3)
前回から引き続き、「ステージを理解して git をもっと便利に使う」というテーマでお送りする、git解説記事の第3弾です。 まずは、前回までのおさらいです。 git にはリポジトリに格納された「最新のコミット」と「ワーキングコピー」の間に「index」と呼ばれる緩衝地帯が存在しています。チェックアウト直後は 「最新のコミット」＝「index」＝「ワーキングコピー」 ですが、ワーキングコピーを編集した後、git addにより編集内容がstage(indexに登録)され、 「最新のコミット」≠「index(+α)」＝「ワーキングコピー(+α)」 となります。 % git add や % git add -p を積極的に使うことで、編集内容を部分的にstageする/しないをコントロールし、1コミットの内容を洗練しましょう、というのが第1回の内容でした。 第2回はgit diffとgit diff
ステージを理解して git をもっと便利に使う(その2)
前回から引き続き、「ステージを理解して git をもっと便利に使う」というテーマでコマンドを紹介します。 今回は git diff --cached です。 ●git diff --cached 使用例 git diff --cached 前回覚えた git add でstageする/しないを使い分けると、困ったことがひとつ出てきます。 それは git diff が「index」と「ワーキングコピー」の差分だけを表示すること、つまり一旦git addでstageした内容はgit diffで表示されなくなってしまうことです。 前回の復習として、git add直後の「最新のコミット」と「index」、「ワーキングコピー」の関係を思い出してみましょう。 「最新のコミット」≠「index」＝「ワーキングコピー」 git diffは「index」と「ワーキングコピー」の差分だけを表示するので、「最新
ステージを理解して git をもっと便利に使う
git には「stage(ステージ)する」という概念があります。あるいは「index」と言い換えてもいいかもしれません。 簡単にいうと「stageする」＝「特定の変更内容をindexに登録する」＝「次回コミットに含めるようgitに指示する」ということなのですが、この概念は今まで主流だった CVS や Subversion といったバージョン管理システムにはありませんでいした。 長年CVSを使っていて、その考え方に凝り固まっていた私は、gitを使い始めてしばらくはstageやindexの概念を理解できなかったので、今回ここで紹介することにしました。 このstageとindexを覚えると「ひとつのコミットには、その主題となる変更と無関係な変更を含めない」という「バージョン管理システムを使う上で重要なはずなのに、つい疎かにしてしまいがち」なポリシーを簡単に実践できるようになります。 今回stag
git-rerereのメモ - unpushの日記
git-rerereってなんかレレレのおじさんみたいですが(Reuse recorded resolution of conflicted merges だそうな)、同じような衝突を何度も起こす状況で使うととっても便利なようで、調べつつ、メモ。 Linusが言っている「無駄なマージコミットやめて」を実現するには、rebaseがあればいいよね、と思ってたんだけど、既に公開しているようなブランチとなると、rebaseするわけにもいきません。 でも途中でちょっとだけ本線とマージしてテストしてみたくなったり、マージした後でやり直して再度マージしてみたくなったりも、しがちです。 そうなるとキツいのが、分かりきってるようなコンフリクトの解消。同じようなマージを繰り返すと、同じように衝突してるところを何度も手で直す作業を繰り返しやるハメになって、泣きそうになります。かといってマージを限界まで我慢して一発
gitで特定のファイルの履歴を消す方法 - ichhiの日記
$ git filter-branch --index-filter 'git rm --cached --ignore-unmatch targetfile' HEAD これで、特定のファイルtargetfileの履歴を消去できる。 特定のディレクトリは $ git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch dir' HEAD で特定のディレクトリdirが消える。-rオプションを忘れずに。 後は、コミットするだけ。 $ git commit -m 'delete targetfile' リモートのリポジトリにもこの変更を反映させなければならない。 そういう場合は $ git push origin master --force でプッシュ。--forceを付けたのはリモートを強制的に上書きするため。
インフラエンジニアのためのGit入門。 - ペンギンと愉快な機械の日々
Unix/Linux, Debian, 運用この資料、どこかの勉強会のLT向け*1に2010年11月13日に作ったのですが、大人の事情*2でお蔵入りにしてました。*3Git本も無事出版されたので、どこかのLTで発表しようか、というと個人的にはずいぶん忘却の彼方になってしまった感もありますし、今年はプライベートな事情*4で、参加できても東京エリアDebian勉強会と、CouchDB JPの勉強会くらいになりそうな感じですので、ブログで公開しておくことにしました。インフラエンジニアのためのGit入門 View more presentations from Kouhei Maeda興味があればぜひご覧ください。Git本もぜひよろしくです。wGitによるバージョン管理posted with amazlet at 12.01.04岩松 信洋 上川 純一 まえだこうへい 小川 伸一郎 オーム社 売り
git merge after git cherry-pick: avoiding duplicate commits
davitenio's blag Scratchpad mostly for Linux related discoveries, commands, scripts, tips… Imagine we have the master branch and a branch b: o---X <-- master \ b1---b2---b3---b4 <-- b Now we urgently need the commits b1 and b3 in master, but not the remaining commits in b. So what we do is checkout the master branch and cherry-pick commits b1 and b3: $ git checkout master $ git cherry-pick “b1’s S
Git、複数のリポジトリを一つにまとめる - <s>gnarl,</s>技術メモ”’<marquee><textarea>￥
やりたいこと ReopA,RepoBがある。ReboB/masterをRepoA/repob-branchにコピーしたい 方法 追記: git fetch location refs/heads/branch-from:refs/heads/branch-to でいける、とJunio様に教えていただきました(ひー)。コメント参照。 各リポジトリの位置を/repo_a,/repo_bとする 1. RepoBのオブジェクトを全部RepoAにコピー。 $ cp -rf /repo_b/.git/objects /repo_a/.git/2. RepoB/masterのオブジェクトIDを調べる [/repo_b]$ cat .git/refs/heads/master 37e7c1e20928bc...3. 2で調べたコミットオブジェクトをチェックアウトする [/repo_a]$ git chec
TiDDとgit-flowを合わせた開発手法について | Technology-Gym
Redmineを使ったTiDD（チケット駆動開発）と バージョン管理システムのGitを組み合わせて、どうやって開発していくのが上手い流れを作れるのかということを考えてみました。 まずはTiDDとは何か 気になるところを取り出すと コードに触る前にチケットを切る Ticket First タスクチケットは細分化して、放置されるようなタスクのサイズにしない チケットで親子関係を作ってまとめるといい 親チケット = ストーリーカード 子チケット = タスクカード コードとチケットを関係付ける(コミットコメントにチケット番号の付加など) No Ticket, No Commit katsumic.info – WorkNote » TiDD（チケット駆動開発）でいこう と大体同じです。 次はGitとチケットについて 元々、RedmineのチケットとGitをどう連携させるのがいいのだろう? というと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tigで別ブランチからcherry-pickする - Qiita
Git: ignore some files during a merge (keep some files restricted to one branch)
はてなブログ | 無料ブログを作成しよう
GitHub - hatena/Git-for-Designers: はてなのデザイナ向けの Git 入門ドキュメントです。
