Git に関する良記事 - あどけない話
適宜追加します。 Pro Git 僕が読んだ Git の書籍の中では、一番分かりやすいと思いました。日本語版の書籍はありませんが、オンライン版が翻訳されています。 Pro Git 図解 Git Git の初心者が動作を理解するのにおススメ。 図解 Git こわくない git ブランチとマージの考え方がよく分かるスライド(@methaneさんから教えて頂きました)。 こわくない git あなたの知らないGit Tips 書籍には載ってない Tips の解説。知らないと損するかも。 あなたの知らないGit Tips ワークフロー、あるいはブランチング チームでブランチを使う際の取り決め。自分のチームで一から議論するより、すでにあるものを参考にしましょう。 git-flow github-flow Github Enterprise Github Enterprise は、企業内に設置して使うこ
GitlabをUbuntu11.10 Serverに導入 - ike-dai's blog
Githubのような環境をクローズドな環境に構築できるOSS Gitlabを試してみました。 Gitのリポジトリを集中的に管理するのには非常に便利だと思います。 今までviewgitとかでGitリポジトリをWebで見せれるようにしたりしていましたが、 全然UIもいいし、CommentやIssue機能など使い方次第でかなり便利に活用できそうです。 以下、インストールした際のログを残しておきます。 あまりまだ情報が少ないので、結構苦戦しました。 今回は、Ubuntu Server 11.10 64bitにインストールしていきました。 https://github.com/gitlabhq/gitlabhq ここのREADMEを参考にインストール 必要なもの OS:Ubuntu,Debian MW:Ruby 1.9.2,Rails 3.1.0,sqlite,git,gitosis,pygment
gitoriousをMacにインストールする - XANADU - the infinity code...
gitoriousは、githubクローンでなかなかよくできているのですが、いかんせんインストールがなかなか大変。 Macへのインストールにいたっては、ほとんど情報もなくそれなりに苦労したのでメモ。 この記事自体や設定ファイルなどを https://github.com/kmr/gitorious_mac_install にも置いてます。 ユーザの作成 gitユーザを作ります。 一般ユーザで普通にユーザ追加してください。 gitユーザでssh接続できるように、共有設定なども確認します。 gitユーザ環境周りの設定として以下のファイルを作成、記述します。 ~/.bashrc export PATH=/opt/local/bin:/opt/local/sbin:$PATH ~/.bash_profile if [ -f ~/.bashrc ] ; then . ~/.bashrc fi.pro
A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind
git-flow という git の運用を補助するプラグインを使ってみたので、その過程をメモしてみました。 そもそも git を採用理由なども書いていきたいと思います。 git を採用した理由 まず何よりも git を採用した理由ですが、日本語の本がたくさんある。Subversion のように気軽にブランチを切ったりマージが出来ない方法では「開発スピードにバージョン管理がついてこれない」という結論に至りました。 そこで svn から git へ以降の準備を進めています なぜ hg や bzr ではないのか git-svn を前々から使っていて rebase のありがたみや branch を気軽にきる運用になれていたからというのもありますが、なにより身近に詳しい人が多いというのが一番です。 Tower や GitX という素敵な GUI があるのも魅力の一つですね。 A successful
Git と GitHub を体験しながら身につける勉強会行ってきた - 予定は未定Blog版
9/18（土） 15：30～ GitとGitHubを体験しながら身につける勉強会（名古屋） : ATND 行ってきました。 なんかいろいろと話すことになったんですけど、あの場で言いそびれたこととか、もっとこう説明してればよかったなぁ、って部分の補足も兼ねたエントリです。 長文注意。 ショートカット git add の話 git add -p/git reset -p の話 リビジョン番号がない話 ブランチの話 git-completion の話、__git_ps1 の話 コミットの指定の話 reset の話 rebase と merge の話 公開したものの rebase の話 stash の話 TortoiseGit、HG、SVNのはなし 全体を通して git add の話 Git と SVN では、add に限らず、同じ名前のサブコマンドでも意味が異なるものがいくつかあります。 その中
git勉強会動画の見どころ - m-takagiの日記
昨日めでたく公開されたgit勉強会の動画(NEKOGETさんありがとう！)ですが、全部見ようとすると３時間がかりとなるなかなか手強い代物です。ということで、各動画の内容を簡単にまとめてみました。とりあえずつまみ食いしてみたいという方の参考になれば幸いです。なお、以下に登場する「資料」とは、こちらからダウンロードできるpdfファイルのことを指します。 git勉強会 2008.10.4 (1) 0000〜 挨拶、導入。gitの読み方(ぎっと)やその意味、これまでの歴史、メンテナを引き継いだきっかけなど。 0600〜 gitのサブコマンドの数。なぜそんなに多いのか。マニュアルをすべて読むなんて非効率的。その理由は？ 0900〜 gitの概念（資料P.3〜） 1900〜 基本コマンドの解説（資料P.12〜P.36） git勉強会 2008.10.4 (2) 0000〜 git rebase --i
アリスとボブのサーバー、git pushをちゃんと理解したい！ - ザリガニが見ていた...。
アリスとボブのGitシリーズが本になりました！ アリスとボブのGit入門レッスン アリスとボブになりきってgitをちゃんと理解したい！ アリスとボブのコラボレーション、gitをちゃんと理解したい！ 上記の日記から続く、アリスとボブの記録。 前提条件 アリスとボブは同じマシンにログインする異なるユーザー。 ファイルシステムからアクセスする分には、サーバーの設定は不要になるので、これで話がシンプルになる。 共通gitリポジトリの準備 最近、アリスにはちょっとした悩みがあった。 現在、このプロジェクトはアリスとボブの二人で、修正したら連絡を取り合って、お互いの変更をダウンロードする（git pullする）ことで同期をとっていた。 しかし、プロジェクトメンバーが増えた場合、このやり方では同期する手間が煩雑になってしまう...。 理想は、サーバーとなるgitリポジトリを決めて、作業前にそこからダウン
git-svnの使い方を覚えた - idesaku blog
分散SCMを使いたい！と思う今日この頃。 仕事ではSVN（Subversion）を使っているのだが、ちょっとしたお試し編集をするためにブランチを作ることに抵抗がある。ブランチは欲しい、大きめな変更をコミット無しで行いたくない、やはり少しずつコミットして進めていきたい。しかし、変更が全て記録されてしまうのがいただけない。ログが残るのは良いことなのだが、本当に使うかどうか未知数な実験的プログラミングのログまで残したくない。使うと決まってから初めて残すようにしたいのだ。 すまん、これまで一緒に仕事をしてきた人々よ。俺はこれまで「ログが残って困ることがなんかある？いらなきゃ無視すればいいだけなんだから、気にするな。ブランチでもなんでもバンバン作ってしまえ！」とうそぶいてきているわけだが…ハッタリかましてました！本当は俺も抵抗があるのだ。 そこで、分散SCMだ。さらにいうと、SVKがいまひとつ気に入
Subversionリポジトリと連携できるgit-svn | OSDN Magazine
「Gitを使いたいが、中央リポジトリにはSubversionを使わざるを得ない」という場合も多いだろう。そのような状況で便利なのが、SubversionリポジトリとGitリポジトリの橋渡しをする「git-svn」である。git-svnを利用することで、SubversionリポジトリとGitのローカルリポジトリを同期させることが可能だ。本記事では、このgit-svnの活用方法を紹介する。 git-svnのアーキテクチャ Gitの大きな特徴として、分散型アーキテクチャがある。分散型アーキテクチャでは、コミットはローカルのリポジトリに対して行い、ソースコードの同期はそれぞれの開発者間が持つローカルリポジトリ同士で変更点をやりとりすることで行う。もちろん公開リポジトリを利用したソースコードの同期も可能であり、柔軟な開発体制を取れるのが長所である。 しかし、一方でGitは非常に多数のコマンドがあり、
分散バージョン管理入門 (イラスト入り) - tcha.org
Kalid Azad、 2007 年 10 月 15 日、 原文 (original post) 従来のバージョン管理は、ファイルをバックアップ・追跡・同期するのに役立った。 分散バージョン管理を使うと、変更内容を共有するのが楽になる。 さぁ、両方の長所を活かすんだ。簡単なマージと一括管理されたリリースを。 分散だって? これまでのバージョン管理で何がまずいの? 別に…。 さっ、気を取り戻したければ、 バージョン管理へのビジュアルガイド(英語) を読んで。 もちろん、「古くさい」システムを使っているとバカにする人もいるだろう。 けれど、私はそれで全然かまわないと思う。 どんなバージョン管理システム(VCS)を使うにしても、プロジェクトにとっては前向きな一歩なんだから。 集中型バージョン管理システムは 1970 年頃に現れた。 その頃プログラマーには、シンクライアントと “big iron”
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://unicus.jp/skmk/archives/41