(特に Git 併用ユーザには是非読んでおいて欲しい) Mercurial における『ブランチ』の概念 〜 その１ - 彷徨えるフジワラ
ここ暫く、Twitter や ML 等で、Mercurial の『ブランチ』に関する質問 (特に Git の『ブランチ』との対比) に答える機会が度々あったので、Mercurial における『ブランチ』の概念に関してまとめてみた。 実のところ、SCMBootCamp in Nagoya #1 での、稲田氏 (id:methane) の基調講演資料における Mercurial のブランチに関する説明 (30ページ目) を見て: 別途口頭での説明が無いと、初学者や他のツールからの移行者にとっては、誤解を招きやすいのではなかろうか？ と思ったのが、このエントリを書く元々の動機だったのだけれど、書き上げるのにかれこれ３ヶ月以上を要してしまったというのは、反省することしきり。 っつーか、ここ暫くは本家に (議論の叩き台としてリジェクト覚悟で) パッチ提案したりと、色々アレだったんで、その辺は勘弁して
CEDEC 2010「ネットワークゲーム開発における構成管理ソフトの活用方法」 - ゲームの花園
今回はSEGAさんのPERFORCEの導入事例のセッションをレポートします。 ネットワークゲームのデータ管理の複雑さと、PERFORCEとその他のソフト(静的解析・BTS・自動ビルド)との連携などなかなか興味深かったです。 ではレポートです。 概要 ファンタシースターシリーズでのPERFORCEの導入と、その他のソフトとの連携 なぜ構成管理ソフトを導入するのか？ PERFORCEを採用した理由 公式サイト ネットワークゲーム開発における構成管理ソフトの活用方法 〜ファンタシースターシリーズでのPERFORCE導入事例〜 はじめに セッション最後の質疑応答であった、PERFORCEと連動しているツールです。レポートに出てくる各種ツールは以下のものになると思います。 連動しているツール 静的解析 Coverity バグトラッキングシステム(BTS) Mantis タスク管理 Trac なぜ構成
hgwebと2つのリポジトリでpull requestを開発フローに組み込む - 放牧日記
http://connpass.com/event/445/:title=の成果です。 TODO: 動機付け 構成 hgwebでは次の二つのリポジトリを用意します。 http://hg.example.com/app (pull専用リポジトリ、レビュー済みの履歴を持つ) http://hg.example.com/app-work (push専用リポジトリ、未レビューを含む全ての履歴を持つ) 通常の作業者は一のリポジトリを用意ます 作業用リポジトリ pull requestを処理する人は二つのリポジトリを用意します。 作業用リポジトリ pull request取り込み用リポジトリ 0) hg clone (◆作業者/★pull request処理者) pull専用リポジトリをクローンして作業用リポジトリ(とpull request取り込み用リポジトリ)を作成します。 $ hg clone
Gitの仕組み - homebrewをフォークするためのGit&GitHub入門 中編 - A Way of Code
前回：Gitのセットアップ 前回、GitHubを使うためのセットアップをしていきました。 今回はGitとGitHubを学んでいきます。 （さらに次回はhomebrewをforkしていきます） 注意: Gitを知らない人がいきなりGitHubを触ったときのメモなので、間違っているところがあるかもしれません。 CVSやSubversion等のバージョン管理ツールの知識がある前提で書いています。 あくまでメモなので説明が至らないところが多々あります。ざっと読み流して、Gitを実際に触ってから読み返したほうが分かりやすいと思います。 目次 1. Gitの構成 1.1 リポジトリ 1.1.1 blobオブジェクト 1.1.2 treeオブジェクト 1.1.3 commitオブジェクト 1.1.4 tagオブジェクト 1.2 ステージングエリア 1.3 作業ツリー 2. リモートリポジトリとローカルリ
Gitのセットアップ - homebrewをフォークするためのGit&GitHub入門 前編 - A Way of Code
homebrewのFormulaを直したくてフォークしようと思いっ立ったものの、GitとGitHubの使い方が分からなかったのでメモしました。 フォーク homebrewを使っていると、欲しいパッケージ（Formula）が無かったり、オプションパラメータを直したくなることがあります。 そんなときはGitHubでフォークしましょう。 フォークをすると、homebrewのオリジナルを自分のGitHubにコピーして編集することが出来ます。さらに、追加あるいは編集したFormulaは、pull requestをすることで、本家にマージしてもらうように依頼できます。configureの調整で苦戦したあなたの労力は無駄じゃないんです！（鼻息荒く 目次 1. GitHubアカウントの作成 2. Gitのインストール 3. SSHキーの設定 4. Gitの設定 1. GitHubアカウントの作成⇒アカウン
継続開発のススメ - Twisted Mind
概要 開発をすればリリースがあり、リリースが終われば開発があります。継続開発をする以上はリリースと開発の繰り返しです。 開発手法やリリース手段は沢山あるのですが、あまりしっくりくるものが無かったので自分でまとめてみました。 これで完璧というものは残念ながらこの世にないと思うので、これからも臨機応変に良い流れを作って行ければと思います。 この文章は以下のような構成になってます。書き殴りですみません。 バージョンの付け方 ソースコード管理とリリース タスク駆動 環境方針 定義 いくつか事前に定義しておかないと話しが訳わからなくなりそうなので。 バージョン管理には git を採用しています。 開発というのはコードを書く事だけを指してはいません。 ここでいうフレームワークは「自身で開発している」として扱います。そうしないとちょっと難しいので。 ライブラリは自身の開発とそれ以外があると思いますので、
はじめてgitをつかったのでコマンドを復習します
はじめに こんにちは川崎です。最近はじめてgitを使う機会がありましたので復習してみます。 このエントリーは私がgitを使い始めたばかりのログを元にして、まとめた内容にしています。 gitをインストール、コマンドを使う準備 gitを使うにはgitのインストールが必要です。使っている環境に合わせてgitをインストールします。 私の環境はmacなのでportsでインストールしました。 $ sudo port -d selfupdate $ sudo port install git-core +gitweb +svn インストールが完了したかどうかはgit --versionコマンドで確認できます。 $ git --version git version 1.7.3 gitのversionが表示されたのでインストールされているようです。準備完了です。 はじめてgitを使うときは gitを使うた
Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering
こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います： ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ
Gitを使った分散開発管理15 – git-flowを使ってみる | DevelopersIO
git-flowを使ってブランチの管理 いままでGitについてのさまざまな機能をご紹介してきました。 まだまだほかにも機能があり自由なスタイルでソース管理できるGitですが、自由すぎてどうしようか迷うかもしれません。 今回ご紹介するものは、実際に開発を進めていく中での運用を補助するプラグイン、 git-flowについてご紹介します。 git-flowとは？ 「A successful Git branching model」※1 と呼ばれるGitのブランチモデルでの運用を補助するプラグインです。 このモデルにそったgit-flowのブランチモデルは下記のような特徴があります。 中央リポジトリとみなす、originを用意 originはmasterとdevelopのブランチを持つ masterはリリース用のブランチで、リリースしたらタグ付けする。（SVNでいう trunkとtag） deve
Bazzar の Push と Merge - at_yasu's blog
良いスレ(【bzr】Bazaarでバージョン管理 Rev 2)があって、pushとMergeの解りやすい説明があったからコピペ。 180 ：デフォルトの名無しさん：2010/05/12(水) 01:40:55 コミットログとpullの動作で質問 共有リポジトリにtrunkブランチをinitして、 そのtrunkを異なる３つのフォルダに落とす。 dir:work_T => trunkログ確認用。 dir:work_A => あるファイルを変更 dir:work_B => work_Aで触っていない別のファイルを変更 として、AとBをpushしたら、work_Aのコミットログが消えました。 すぐ試せるコマンド書くんで、自分がおかしいのかbazaarがおかしいのか（仕様）なのか 教えてください。 （改行多いので次のカキコ） 181 ：デフォルトの名無しさん：2010/05/12(水) 01:45
git-flow によるブランチの管理
今回は分散バージョン管理システムgitと共に用いる「ブランチモデル」について紹介していただきます。gitを使ってみて、その高機能さをどう使えば良いか悩まれた方は、ぜひ本稿をご一読ください。gitそのものの使い方については解説していませんので、その際には『 実用git 』などの書籍を参考にしてください。 git-flow は Vincent Driessen 氏によって書かれた A successful Git branching model (O-Show 氏による日本語訳) というブランチモデルを補助するための git 拡張です。 git-flow を利用する前には、まずこの文章を一読することをおすすめします。 その骨子については、 Voluntas 氏のブログ が参考になります。 git を使うメリットの 1 つは、そのブランチモデルです。しかし gitを使っていると、その高い柔軟性か
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入門 ゼロから始めるGitドリル
gitの勉強をしつつ取ったノートを記事化しました。一応これを読めばざっくりとした導入やSVNとの違いが分かってもらえるように書いたつもりです。svnを使った経験があることを前提に進めていきます。 svnの場合、一つのレポジトリに対して認証のあるユーザが変更を報告していくユースケースをとっています。gitの場合は、個々のローカルマシンにリポジトリが分散されて配置され、お互いに変更を報告しあうユースケース。これはLinuxの伝統的なバザール方式の開発を想定しています。そのため例えばカフェや電車で開発したり、マスターはgithubやgitfarm（Git Hosting参照）にしておいて時々ローカルの変更を報告することも可能です。 目次 インストール 基本操作 Gitリポジトリの作成 ブランチの作成。 タグ ファイルを無視する 索引の理解 取り消し 導入 --hardと--softの違い 一個の
msysGitのGit bashで日本語を使えるようになるまで - sinsengumi血風録
最近、ようやくGitを使い始めました。サクサク感があっていいですね。あとGithubの存在が大きい。 で、表題なんですが、 僕はWindows派でmsysGit使ってるわけですが、デフォルト状態（Git Bash）ではコミットログの日本語が化けて出たりと何かと不便です。 そこで、いろいろ設定して日本語が表示できるようになろうという感じです。 lessとnkfをインストール 以下を参考に、lessとnkfを導入します。 http://sourceforge.jp/magazine/09/02/12/0530242/3 inputrc set meta-flag on set input-meta on set output-meta on set convert-meta off set kanji-code utf-8 profile export GIT_PAGER="nkf -s |
Git日本語対応備忘録
※2012/4/12追記 UTF-8対応版のGitが正式にリリースされたので、この記事の手順は基本的に不要になります。 詳しくはこちらをどうぞ。 Git-1.7.10-preview20120409.exe のGit Bashで日本語入力する方法 — 久々にGit環境作ったら日本語対応方法を忘れていたので、自分のためにメモ。 Gitのインストール UTF-8ファイル名対応版 Git for Windowsからダウンロードし、msysGitをインストールします。 まずは日本語を扱えるようにする Gitのインストールが終わったら、次にGit Bashで日本語が扱えるようにしましょう。 nkfのダウンロード、インストール nkf.exe nkf32.dll Windows用の詳細情報 : Vector ソフトを探す！などからnkf.exeをダウンロードし、%ProgramFiles%\Git\b
コミットメッセージの書き方 - 2012-02-21 - ククログ
はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常
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 -
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ページを開く
エンタープライズ分野での分散バージョン管理システム
バージョン管理のワークフロー
