gitで誤ったブランチに対して行った変更を正しいブランチに移す(stash編) | Webシステム開発／教育ソリューションのタイムインターメディア
問題 gitで誤ったブランチに対して行った変更を正しいブランチへ移す(cherry-pick編) では一度コミットしてしまった変更を別のブランチへ付け変える方法について紹介しました。 この例では誤ったブランチに対して一度コミットしてしまいましたが、 コミットする前に誤ったブランチで作業していたことに気付くこともよくあります。 例えば以下のような状態です: $ git branch master * topic-y $ git branch topic-x master $ $EDITOR # git checkout topic-x を忘れて作業してしまった。 $ git status # On branch topic-y # Changed but not updated: # (use "git add <file>..." to update what will be commit
RedmineでGitのリモートリポジトリを参照 | へびにっき
Redmineでブラウズの対象とするには local かつ bare なリポジトリでなければならないので、そのままでは使えない。そこでまず対象リポジトリのミラーとなるbareリポジトリを作る。 git clone --bare git://host/path.git cd path git remote add --mirror origin git://host/path.git 最近のバージョンの git では clone のオプションに –mirror を直接指定することができるらしいが、1.5.6 では上の手順が必要だった。 # git-1.6.0.6以降 git clone --mirror git://host/path.git リポジトリを同期するには、ミラーリポジトリ内で fetch を実行する。cronで定期的に実行するよう設定しておけば実用上は十分だろう。 git fe
Git - Gitの参照
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
initしてremote addするのとcloneするのの違い - hokaccha memo
gitのリポジトリを最初につくるとき、リモートリポジトリを最初に作ったあと、 $ git init $ git remote add origin <repos>ってやるのと $ git clone <repos>ってのがある。 remote add したとき、pullしようとすると $ git pull You asked me to pull without telling me which branch you want to merge with, and 'branch.master.merge' in your configuration file does not tell me, either. Please specify which branch you want to use on the command line and try again (e.g. 'git p
dotfilesをgithubで管理する！ - 憧れ駆動開発
dotfilesとは .vimrc とか .tmux.conf とか .screenrc とか .bashrc とか .zshrc とか、だいたいそういう設定ファイルの類です。それらをまとめてgithubで管理すると、どの環境でも git clone するだけで同期がとれてすごく便利です。 まあ ぶっちゃけそれだけならいろんな人がやっています。いろんな人のを参考にすればいい。githubへの登録の仕方とかは自分で調べてください。簡単です。 yuroyoroさんはすごかった しかし github で dotfils を管理するときにシンボリックリンクを自動的に貼るスクリプトを使うという発想はなかった。これはすごい。 iTerm2 + zsh + tmux + vim で快適な256色ターミナル環境を構築する - ( ꒪⌓꒪) ゆるよろ日記 このエントリはいろんな意味で最強すぎる。さすがにそこ
How to have 'git log' show filenames like 'svn log -v'
SVN's log has a "-v" mode that outputs filenames of files changed in each commit, like so: jes5199$ svn log -v ------------------------------------------------------------------------ r1 | jes5199 | 2007-01-03 14:39:41 -0800 (Wed, 03 Jan 2007) | 1 line Changed paths: A /AUTHORS A /COPYING A /ChangeLog A /EVOLUTION A /INSTALL A /MacOSX Is there a quick way to get a list of changed files in each com
aka:Github
Github Basic Configuration Reference http://help.github.com/mac-set-up-git/ Memo How to reuse existing SSH keys Just copy the private and public key into the .ssh directory. If you have multiple key paris, write or modify .ssh/config file to bind hosts and keys. http://linux.die.net/man/5/ssh_config aka:ssh 複数Github アカウント Githubは、1つのGithubアカウントに複数のSSH公開鍵を設定することはできるが、1つのSSH公開鍵を複数のGithubアカウントに設定すること
Accueil
La décoration intérieure est une opportunité d'exprimer votre style personnel et de créer un espace qui reflète votre personnalité. Explorez les règles d'or qui peuvent guider votre démarche, vous aidant à transformer votre intérieur en un lieu harmonieux et esthétiquement plaisant. Compréhension de l'espace et planification La première règle d'or pour une décoration intérieure réussie réside dans
nabokov7; rehash : 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム
October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ
僕たちが行き着いた、シンプルで簡潔なGitの運用方法 - テクノロジーと広義のデザイン！
Gitを使い始めて１年以上たちます。最近、Gitを使ったプロジェクト運用方法が自分なりに固まってきたので公開します。かなりシンプルなので、ある程度Gitに慣れていれば十分に運用可能だと思います。 僕たちが理想とするヒストリーGitを使った開発の成果物、それは開発のヒストリー（履歴）そのものです。このヒストリーが論理的に正しく、かつ、簡潔で理解しやすいものを目指すというのが大方針となります。その方針のなか、現時点で僕たちが理想だと考えているのが、以下の図のような履歴がリモートブランチに残ることです。このヒストリーには２タイプのブランチが存在します。 リリースブランチ … 次期リリースバージョンに向けて進んで行くブランチ。チケット１枚について１つのコミットが良い。 フィーチャーブランチ … チケット１枚について１つ切られるブランチ。機能を実装する際に小刻みにコミットしたログが残っているため、後
Git管理の神ツール「Gitolite」なら、ここまでできる！
「Git」使ってますか？ 近年、分散バージョン管理システム「Git」が急速にシェアを伸ばしています。筆者は、チケットシステムやバージョン管理の勉強会などを開催したりしていますが、Gitユーザーがかなり増えてきていると感じます。 しかしながら、そのような勉強会でアンケートを取ってみると、実案件では半分以上の人がSubversionを利用しており、Gitの導入はまだまだ進んでいません。移行コストが掛かったり、プロジェクトマネージャ層への知名度がまだまだ低いというのもありますが、理由の1つとして、ユーザー管理が煩雑であったり、アクセス制御に関する情報が不足しているということもあると思います。 そういうわけで本稿では、Gitリポジトリのユーザー管理やアクセス制御を簡単に行う「Gitolite」を紹介します。 なお、本稿ではGitの利用方法については紹介しませんので、Git自身の使い方については改め
小規模Webサービス向け安上がりシステム構成と開発フロー（怖話.jp） - Fjord, Inc(株式会社フィヨルド)
こちらのエントリーが大変参考になったので、僕らが作ってる怖話.jp（kowabana.jp）のシステム構成や開発方法についても公開していこうと思います。 怖話.jpはスマホ向けWebサービスなのでPC向けとはPVとかの傾向がちょっと違うかも知れません。 怖話.jpとは スマホで17,000話以上のサウンドノベル風の怖い話が閲覧・投稿できるサイト（アプリではありません）です。詳しくは下記エントリーを参照してください。 スマホでサウンドノベル風怖い話投稿サイト | FJORD, LLC（合同会社フィヨルド） 7月16日にRubyKaigi2011に合わせて無理矢理ベータテストオープンして、8月9日に正式オープンしましたので正式オープンからは１ヶ月経ってないまだまだのサイトです。開発期間は約１ヶ月ぐらいです。 サイト情報 （これAnalyticsを直接貼るのはどうやればいいんだろう？） 直近一ヶ
もっとよいGitチートシート - 西尾泰和のはてなダイアリー
世の中にGitのチートシートはいくつかあるけど「Gitを知らない人に渡して最初に読んでもらうのに適したもの」が見つからない。チートシートじゃなくてチュートリアルと呼ぶべきかもしれないけど、とにかく印刷してA4で1枚になるくらいの資料が必要だ。Gitに触れた技術者が軒並み同じ落とし穴でコケるのは正しい状態ではない。「Gitには、indexっていう『コミットする前にワークツリーで行った変更のうちのどの部分をコミットするか整理するための場所』があるんだよ」とか「git revertはsvn revertと違っていきなりリポジトリに変更を加えるから気をつけて」とか最初に言ってもらえればもっとスムーズに進めたはずだ。 というわけでどういうチートシートが必要かに関して考えてみる。 登場人物 http://www.ndpsoftware.com/git-cheatsheet.html このチートシートが
git.vimの便利な機能に気づいた - Guyon Diary
git.vimでaddする時に、選択してaddできたらいいのになぁと思っていたら、偶然その機能を発見してしまった。 後でdocを再確認したらしっかりと === In git-status buffer [] :GitAdd 記載されていました。 「おぉ！！実装されていた！！ヘルプきちんと読もうぜ俺。」という心の叫びが体の内から聞こえてきました。 どんな風に操作できるのかというと :GitStatus で表示したステータス表示画面で操作を行います。 操作方法 ファイル名の上にカーソルを合わせる Enter：コミットを予定する マイナス(-)：コミット予定から降ろす addするファイルや編集したファイルをコミット予定に入れたり降ろしたりする事ができて、最後にまとめてcommitすることができます。 操作のgifアニメーションを作ってみました。*1 いいなぁ。この機能。 Life Changin
git diff の使い方がほんの少し理解できた - murankの日記
いままでなんとなく使ってきたけど、ようやく使い方が分かったような気がするのでメモ。 前提知識 インデックスとワーキングツリーが理解できていること HEAD が何か分かっていること git diff ワーキングツリーとインデックスの差分を表示。 git add した後にさらに修正したけど、そういえばどの時点で git add したのかなー、というときに使う？ git add したらすぐにコミットする自分には関係なさそう。 git diff --cached HEAD とインデックスの差分を表示。 git add して、コミットする前に差分を確認したい時に使うんだと思う。 自分は git diff よりもこっちの方をよく使う。 git diff HEAD HEAD とワーキングツリーの差分を表示。 前にコミットした時からどれくらい編集したか確認したい時に使う。 HEAD の部分はコミット(HE
多人数開発で Git を使う場合の環境構築 | GREE Engineering
こんにちは、インフラやってる sotarok です。最近、社内でも「sotarok は そーたろっくと読む」という誤解が広がっていましたので改めて自己紹介しますと、sotarok と書いて「そーたろー」または「そーたろー・けー」と読みます。ロックしてないのでよろしくお願いします。 今日は、Git の話です。 GREE ではずっと Subversion を使っているという話を、以前開発環境の話をしたときに少し触れたことがあります。Subversion での運用方法も、GREE では割と面白い運用をしているのでその話もどこかでしたいのですが、まあ、それは今回は置いておきましょう。どこかで聞いてください。 GREE もその昔 CVS から Subversion に移ったのですが、時代は流れるもので、いよいよ Git 化という流れがきています。Subversion と Git の違いを今更あえて挙
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Git で不要になったローカルブランチ・リモートブランチの削除 - sotarokのお勉強
Welcome to nginx!
Vim-users.jp - Hack #67: Gitを使う
Perlゼミ(サンプルコードPerl入門)