gitねた - holly's wiki
holly's wiki hollyさんのwiki トップページページ一覧メンバー掲示板編集 gitねた 最終更新： kurt0027 2012年08月20日(月) 11:51:52履歴 Tweet gitコマンドを使うにあたってのもろもろ インストール yumでインストール まあ、centosだとyumとかでいれたらいいんじゃないあかなと yum install --enablerepo=rpmforge -y git perl-DBI perl-Error perl-Git とかで適当にはいるはず。ほかにも # yum search --enablerepo=rpmforge git | grep -E "^git" git.i386 : Git core and tools git-all.i386 : Meta-package to pull in all git tools gi
古いコミットを書き換える： 歴史修正主義者のための git rebase -i 入門 - 学習する機械、学習しない人間
直前のコミットをやり直したいときは、git commit --amend を使うと可能だ。そして、さらに昔のコミットをやり直す(書き換える)ときは、git rebase -i を使う。 git rebase -i を使うと、引数にとったコミット以降のコミット系列に対して、コミットの書き換え、削除、統合を行うことができる。 次の課題をこなすことを目標としながら、git rebase -i の動作を追っていこう。 課題「最新のものから古いほうへ3つ分のコミット(HEAD, HEAD~1, HEAD~2)のログメッセージを書き換えたい」 git rebase -i の起動 まず、変更したいコミットで一番古いものより一つ古いものを引数にして、git rebase -i を実行する。この場合は HEAD~3 である。 $ git rebase -i HEAD~3 すると、エディタが rebase コ
たのしいGit - Nalsh's Notes
序 言うまでもないことだが、タイトルはジョークである。 そもそもバージョン管理は本来我々がしたい事ではない（一部の人を除く）。別に作りたいものがあり、そこでの作業を円滑に進めるためにバージョン管理するのだから、所詮はヤクの毛刈りである。さらに、Gitクライアントのへっぽこさも相まってなかなかに時間を食われる。この文書はそのような人々が、より円滑にGitを使えることを祈って書かれた。 なお、バージョン管理というのはとても複雑なシステムであるため、バージョン管理自体が目的な人には楽しい世界である。そのような人々はぜひGitやその他のバージョン管理システムのマニュアルやソースコードを読んでいただきたい。きっとその奥深い世界を堪能できることだろう。 Git概説 Gitはこれまでの旧来のバージョン管理システムとは一風違った設計で作られている。また、Git特有の概念も多い。なので、まずGitの概観を説
Git管理の神ツール「Gitolite」なら、ここまでできる！
「Git」使ってますか？ 近年、分散バージョン管理システム「Git」が急速にシェアを伸ばしています。筆者は、チケットシステムやバージョン管理の勉強会などを開催したりしていますが、Gitユーザーがかなり増えてきていると感じます。 しかしながら、そのような勉強会でアンケートを取ってみると、実案件では半分以上の人がSubversionを利用しており、Gitの導入はまだまだ進んでいません。移行コストが掛かったり、プロジェクトマネージャ層への知名度がまだまだ低いというのもありますが、理由の1つとして、ユーザー管理が煩雑であったり、アクセス制御に関する情報が不足しているということもあると思います。 そういうわけで本稿では、Gitリポジトリのユーザー管理やアクセス制御を簡単に行う「Gitolite」を紹介します。 なお、本稿ではGitの利用方法については紹介しませんので、Git自身の使い方については改め
Gitの使い方あれこれ
2011年10月1日のminami.rbの第9回勉強会で発表したgitのtipsのプレゼン資料です。Read less
git-mergeで--ff(デフォルト)と--no-ffと--squashの違い - u1tnkの日記
きっかけ A successful Git branching model » nvie.com ここらあたりを見て、--no-ffつけときゃいいんだなーと深く考えずに使ってたら、--squashつけると安全とかなんとかチラ聞きして混乱しまくったので調べてみた。 とりあえずman。 man git-merge ... --ff, --no-ff Do not generate a merge commit if the merge resolved as a fast-forward, only update the branch pointer. This is the default behavior of git-merge. With --no-ff Generate a merge commit even if the merge resolved as a fast-forwa
自分用のGit備忘録 - kanonji’s diary
gitはコマンド体系が複雑で、なかなか覚えられないので備忘録をつけます。細かすぎて毎回エントリー作るのもなんだし、でもまとまるまで待ってると忘れちゃうので、備忘録にしたいなーと思ったときに追記する形にしようかな。なので、随時追記していきます。 自分用のLinuxコマンド・シェルコマンド備忘録 - kanonjiの日記 自分用のVim備忘録 - kanonjiの日記 他にLinux(とMacの場合もあり)のコマンドとvimの備忘録も貯めてます。 ローカルに既にあるリポジトリを、githubにpushする githubでリポジトリを作る。 ローカルでpush出来る状態にしておく。*1 $ git remote add origin git@github.com:username/foo-repos.git $ git push -u origin master 例としてusernameというユ
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
msysGit の git stash や git rebase --onto でエラーの回避 - miauのブログ
Git で日本語のコミットログを残している場合、msysGit で git stash や git rebase --onto を実行すると、 usage: git update-ref [options] -d <refname> [<oldval>] or: git update-ref [options] <refname> <newval> [<oldval>] -m <reason> reason of the update -d deletes the reference --no-deref update <refname> not the one it points to Cannot save the current statusと言われて失敗しまうことがありました。この回避策を調べたので書いておきます。バージョンは git version 1.7.0.2.msysgit
WindowsでのGit環境構築とその注意点 | OSDN Magazine
もともとはLinuxカーネル用のバージョン管理システムとして開発されたこともあって、GitのWindowsサポートは若干遅れている。特に日本語環境で利用する場合は設定などに注意が必要だ。そこで本記事では、Windows環境でGitを利用する方法およびその設定方法、そしてGUIでGitの機能を利用できるツールについても紹介する。 Windows環境向けのGitバイナリを選ぶ Gitは標準ではWindows環境をサポートしていない。Gitのコア部分はCで記述されているものの、周辺ツールやサーバー機能の実現にはPerlやシェルスクリプトを利用しているからだ。そのため、Windows環境でGitを利用するには、これらを含めた環境構築が必要となる。現在、Windows上でGitおよびその周辺環境をまとめてインストールできるものとして、msysgitとCygwinがある。 msysgitは、Windo
[Git] Git コマンドメモ - それはBooks
Git のコマンドメモ。 コミット ステージングエリアに追加する $ git add [--all] <filepattern> オプション –all を指定するとすべてのファイルをステージングエリアに追加する。 ステージングエリアから削除する $ git rm --cached <filepattern> git rm を使うと、ファイルを作業ツリーから削除する。–cached オプションを指定するとステージングエリアから削除するが作業ツリーには残った状態になる。 単にステージングエリアへの追加を取り消したい場合は対話モードを使って revert（取り消し）を行う。 $ git add -i staged unstaged path 1: +1/-1 nothing README.txt *** Commands *** 1: [s]tatus 2: [u]pdate 3: [r]eve
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
NDP Software :: Git Cheatsheet
stash workspace index local repository upstream repository status Displays paths that have differences between the index file and the current HEAD commit, paths that have differences between the workspace and the index file, and paths in the workspace that are not tracked by git. diff Displays the differences not added to the index. diff commit or branch View the changes you have in your workspace
subversionを使っていた人がgit便利だなと感じたこと - (ﾟ∀ﾟ)o彡 sasata299's blog
2009年05月25日05:42 Git subversionを使っていた人がgit便利だなと感じたこと 最近は subversion も使いますが、git を使うことも多くなってきました。モジュールの配布なども git のものが多くなってきて、そろそろ git を使えるようになっておかないとまずい気が・・。ってことでちょっと勉強してみたのでまとめてみます。 そもそも「 subversion と git は何が違うの？」っていう話ですが、主な違いは以下の通りです。【参考】に挙げたサイトが分かり易いと思います。 subversion ・単一リポジトリ（リポジトリは一つだけ） ・commit したら即反映 ・add するのは新規にファイルを追加するときだけ ・リビジョン番号は数字 ・考えるのは『ローカル（ checkout した場所）』と『リポジトリ』の2つだけ git ・分散リポジトリ（マス
.gitconfigに設定してるaliasなどのまとめ - ( ꒪⌓꒪) ゆるよろ日記
22:56 @thinca さんからの指摘を追記 @yuroyoro あとお節介ですが、n個前とdiffなら HEAD^ より HEAD~ の方がいいと思いますよ。両者では若干意味が違います。~なら HEAD~3 と数字が書けるのも利点です。あと個人的にはwhatchangedよりlog --statの方が見やすくて好きです。 2010-10-08 22:30:52 via Tween to @yuroyoro @yuroyoro URL このgitconfigの記事に関して質問なのですが、core.excludesfile は $HOME で動きますか?以前試した時ダメで、~/ なら動いたのでこちらを使ってるんですが。 2010-10-08 22:20:49 via Tween to @yuroyoro 「そんな.gitconfigで大丈夫か?」 そんなわけで、仕事でもモリンモリンにgi
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 この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
Git初心者が絶対に覚えておくべきコマンド - idesaku blog
Gitの使い方を覚えるにあたって、まず知っておきたいのは――git-cloneだのgit-commitだのは当然として――「操作をミスったときにどのように回復するか」である。それを実現するのは、次の３つのコマンドだ。 git-commit --amend git-reset git-reflog git-commit --amend あるファイルをコミットしたとしよう。 $ (edit...) $ git commit -am 'メッセージ生成処理を実装したよ。'しかし、しばらくして彼は気づいた。 def create_massage(param) ...typoしてる！massageじゃない、messageだ！マッサージを作ってどうする！ 慌てるな。まずは直してステージに上げるんだ*1。 def create_message(param) ...$ git add .そして…。 $ gi
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git:start - Kent's Study Notes
http://blog.inouetakuya.info/entry/20110605/1307261417
