第212回 Git/Bazaarブラウザあれこれ | gihyo.jp
明日から3月です。春です。春といえば出会いと別れの季節。「出会い(merge)」と「別れ(branch)」を初心者でも効率よく行うために、グラフィカルなインターフェースを備えたGit/Bazaarクライアントをいくつかご紹介します。 Gitクライアント Gitは世界でもっとも使われている分散型バージョン管理システムです。Recipeの読者であれば、LinuxカーネルやGitHubなんかでお世話になっている人も多いことでしょう。Ubuntuでもgitパッケージをインストールすることで簡単に導入できます。 ちなみに、Gitは初期状態だと日本語などのマルチバイトのファイル名を数値表現で表示します。git-gui/gitk以外のクライアントはこれを数値のまま表示してしまうため、日本語ファイル名を含む差分を見るときに不便です。以下のコマンドで、数値表現に変更せずそのまま表示するように設定を変更して
A Git Horror Story: Repository Integrity With Signed Commits — Mike Gerwitz
A Git Horror Story: Repository Integrity With Signed Commits 2012-05-22 (Note: This article was written at the end of 2012 and is out of date. I will update it at some point, but until then, please keep that in perspective.) It’s 2:00 AM. The house is quiet, the kid is in bed and your significant other has long since fallen asleep on the couch waiting for you, the light of the TV flashing out of t
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
GitのCommit中のAuthor名およびCommitter名を変える - idesaku blog
ローカルで持っているGitリポジトリをGitHubにpushしてしまいたいなぁ、と思ったのだが、pushする直前にAuthorおよびCommitterとして自分の本名を使っていることに気づいた。そういえば、Gitを使い始めたころはuser.nameに正直に本名を入れていたなぁ…。 そのままでも大した問題はないのだが、ネット上ではidesakuで通すことにしているので、こいつらを修正した。その際、あまり使わないコマンドを使ったので、作業ログなど残してみる。 さて、どうすればよいか。すぐに思いついたのは、git-rebaseを使うことである。 ところで、Gitは全てのコミットにAuthorとCommitterの二つの名前を記録している。これは、オープンソース分野でよくある「パッチを書いた人(Author)と、それをリポジトリにコミットした人(Committer)が違う」ケースに対応するための措
Git管理の神ツール「Gitolite」なら、ここまでできる！
「Git」使ってますか？ 近年、分散バージョン管理システム「Git」が急速にシェアを伸ばしています。筆者は、チケットシステムやバージョン管理の勉強会などを開催したりしていますが、Gitユーザーがかなり増えてきていると感じます。 しかしながら、そのような勉強会でアンケートを取ってみると、実案件では半分以上の人がSubversionを利用しており、Gitの導入はまだまだ進んでいません。移行コストが掛かったり、プロジェクトマネージャ層への知名度がまだまだ低いというのもありますが、理由の1つとして、ユーザー管理が煩雑であったり、アクセス制御に関する情報が不足しているということもあると思います。 そういうわけで本稿では、Gitリポジトリのユーザー管理やアクセス制御を簡単に行う「Gitolite」を紹介します。 なお、本稿ではGitの利用方法については紹介しませんので、Git自身の使い方については改め
DOMAIN ERROR
ドメインウェブの設定が見つかりません 考えられる原因 ドメインウェブの設定がまだ行われていない。 ドメインウェブの設定がまだ反映されていない。(反映には数時間～24時間かかることがあります) ドメインウェブ・DNSの設定が誤っている。 アカウントが存在しない、契約が終了している、削除されている。
Github – suVeneのアレ
Archives2018年4月 (1)2015年9月 (1)2015年8月 (2)2015年5月 (5)2015年3月 (2)2015年2月 (6)2015年1月 (1)2014年12月 (2)2014年9月 (2)2014年3月 (1)2014年2月 (1)2014年1月 (2)2013年12月 (1)2013年8月 (1)2013年7月 (3)2013年2月 (2)2012年10月 (1)2012年8月 (7)2012年7月 (3)2012年6月 (2)2012年5月 (9)2012年4月 (2)2012年3月 (6)2012年1月 (9)2011年12月 (1)2011年9月 (1)2011年7月 (1)2011年6月 (1)2011年3月 (1)2011年2月 (4)2011年1月 (1)2010年10月 (1)2010年9月 (4)2010年8月 (4)2010年3月 (3)20
Repo って何だろ? -- 複数 git リポジトリーのためのツール
Google が repo というツールをリリースしている。これは、Google が開発している Android プロジェクトのためのツールなのだけど、Android 専用のツールといふわけでもなさそうなので、少し調べてみた。 Get source (Android Open Source Project) Using Repo and Git (Android Open Source Project) repo は、git を補完するツール。 repo の仕事は主に 2 つ。1 つは、「複数の git レポジトリー」を管理すること。もう 1 つは、git のレポジトリーを取って来たり、レビュー・サーバーに変更点を送ったりということ (特に複数レポレトリーをサポートしている点がミソ)。 何が嬉しいの? 普通、バージョン管理ソフトは、一つのリポジトリーで一つのプロジェクトを管理する。開発規模
Latest topics > SubversionからGitに移行した - outsider reflex
Latest topics > SubversionからGitに移行した 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « Ubuntu 10.04LTSからUbuntu 10.10へのアップグレードとATOK X3 Main Jetpackへのモヤモヤを全部吐き出そう » SubversionからGitに移行した - Nov 01, 2010 アドオンの開発にはずっと須藤さんに用意してもらったSubversionのリポジトリを使ってたんだけど、 インターネットに繋がらない状態でコミットできないのが辛い 他の人からの変更を受け取りづらい（そんな事があればの話なんだけど） と思っていて、Git（あるいは他の分散型バージョン管理システム）ならそれが解消
git submodule - みずぴー日記
http://d.hatena.ne.jp/woremacx/20080308/1204986198のように、gitで外部レポジトリを扱えるようにする方法。 外部レポジトリの追加 git submodule addすると、外部レポジトリをサブモジュールとして取り込めるようになります。 # cloneする $ git clone git://example.com/repos/private/ $ cd private # git://example.com/repos/external/を追加する $ git submodule add git://example.com/repos/external/ # commitしておく $ git commit -m "Add submodule" $ git push 外部レポジトリ内での作業 外部レポジトリで作業したときは、そこでコミットする
git-svnでリモートブランチをmergeするときは–no-ffをつけるべし - Webtech Walker
git-svnでリモートブランチをきって作業しててtrunkにmergeしようと思ったら、mergeした先のローカルブランチの向き先がリモートブランチになる現象ではまった。またしてもtypester++であります。インクリメントされすぎてそろそろ2147483647超えるんじゃないと心配です。 # 今masterブランチにいる $ git branch * master # リモートブランチはtrunkを見てる $ git svn info URL: http://path/to/trunk ... # リモートブランチtopicを作成してローカルブランチtopic_localにコピー $ git svn branch topic $ git checkout -b topic_local topic # ローカルブランチはtopic_local $ git branch master *
アリスがチャレンジなコードを書く時、git branchをちゃんと理解したい！ - ザリガニが見ていた...。
アリスとボブのGitシリーズが本になりました！ アリスとボブのGit入門レッスン アリスは迷っていた。現状のshowメソッドは固定されたメッセージしか出力しないが、理想的にはユーザーの条件によって変化させたいと。 しかし、その機能を実装するためには結構な大改修になってしまう。果たして今の自分の技術でちゃんと完了させることが出来るだろうか？この機能追加をやるべきか、このままにするか...。 アリスはこの修正が失敗に終わった時のことを考えて、ボブに連絡しておくことにした。「失敗したらごめんね。」と。（なんて無責任なアリス...。） 連絡を受けたボブは、アリスの機能追加には大賛成。ボブ：「ただし、新しいブランチを追加して、そこで作業くれ。」と。アリス:「ブランチ？？？」 アリスはブランチを理解できていないが、とりあえず、ボブに説明された手順をそのままやってみることにした。アリス：「習うより、慣れ
git stash save で一時退避した変更を、誤って git stash clear で消してしまったときの回復法 - t-wada の日記（旧）
一年くらい前から git を使い始め、ここ半年くらいは毎日の開発に git を使っています。昨日 git stash という機能を使っている時に失敗してしまい、何人かの方にアドバイスいただくことによって無事回復することが出来たので、感謝の印として、そして運悪く同じ問題に遭遇してしまった人たち(私もまたやるかも)へのメモとして記しておきます。 御託はいいから、早く回復法を知りたい人のためのまとめ $ git fsck | awk '/dangling commit/ {print $3}' 候補の sha1 がいくつか出てくる(長く開発していると、結構多く候補が出てきます) $ git show --summary 候補のsha1 一つ一つの sha1 の内容を確認 $ git cherry-pick -n -m1 見つけたsha1 いきさつ 私の作業のやりかたでは、 タスク毎にブランチを切
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[git 1.6.0.2] submoduleを使おう！その2 - satoko's blog - s21g