特別な理由なしにgit-flowを新規採用するべきではない - Qiita
私がこれまでGitの研修講師やブランチ戦略のコンサルティングをおこなってきた経験に基づいて、この記事を書きます。 Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A succ
Git を学ぶ - チュートリアル、ワークフローおよびコマンド | Atlassian
Git は、元々 Linus Torvalds によって 2005 年に作られた、無料でオープンソースのバージョン管理システムです。他の SVN や CVS といった中央バージョン管理システムと違って、Git は分散型で、すべての開発者がローカル環境で彼らのコードのリポジトリの完全な履歴を持っています。これは、最初のリポジトリのクローン作成に時間がかかりますが、commit、blame、diff、merge、log といったこれに続く作業を劇的にスピードアップします。 Git は多くの革新的で強力なワークフローやツールにつながる、リポジトリ履歴のブランチ、マージ、および書き換えに非常に役立ちます。プル リクエストは、チームが Git ブランチでコラボレーションを行い、他のコードを効果的に見直すことができる、非常に人気のツールです。Git は現在世界で最も広く使用されているバージョン コント
Microsoft のブランチ・マージ作業ガイドライン
原文(投稿日：2012/04/23)へのリンク Microsoft は新たな Branching and Merging Guide のドラフト版をリリースした。表向きの対象は TFS ユーザだが，アドバイスの大部分はソース管理プロバイダに関係なく適用可能だ。まずその基本概念を紹介しよう。 ブランチとマージを扱うほとんどのガイドラインと同様に，すべてのブランチの親の役割を持つメインブランチが存在する。 "trunk" として知られることが多いが，Microsoft ではこれを MAIN と呼ぶ。MAIN には DEVELOPMENT と RELEASE という２つの主要ブランチがある。 最初のガイダンスでは開発ブランチ(DEVELOPMENT) について取り上げている。内容は比較的簡素で，基本的には企業のチームや機能の構成方法に帰着する，というものだ。ただし前のバージョンから継続している独
VSSからSubversionへの移行 - 情シスは何度でも甦るさ。
社内のバージョン管理をVisual Source Safe（VSS)から、Subversion(svn）にした経緯・苦労した点を書く。技術的な内容については、あまり書いてないので、ぐぐってくださいな。 1.VSSの課題 ユーザー毎にライセンス料がかかる Visual Studio,EclipseなどのIDEから使えない（つかいづらい） VSSのリポジトリがあちこちのサーバに点在してどこに何のリポジトリがあるかは担当者のみぞ知る サポートが切れてる（vss6。vss2005のメインストリームサポートは今年切れる） うちの会社は、昔vb6でアプリを作りまくっていたようです。その経緯からVSSが使われていました。（vb6にVSS6が付属してた）今でもvb6の資産も残ってますが、最近は.netもJavaも、さらにCOBOLのシステムもあったりします。 でも、そもそもユーザーごとに金かかるって、あり
数千人が利用する楽天Redmineの過去と未来 #47redmine
第二回 shinagawa.redmine勉強会で「数千人が利用する楽天Redmineの過去と未来」を発表させていただきました。資料はSlideShare、SpeakerDeckで公開しております。QAの時間が取れなかったため、質問などがあればTwitterでもなんでもご連絡ください。 数千人が利用するRedmine 来月、第3回RxTstudyでもRedmine事例の発表させていただくのですが、品川Redmineはシステム視点、RxTstudyではタスクマネジメント視点で資料を作りました。 はじまりは、使われてないサーバ上に作った仮想VMを使っていました。ユーザ数も少なかったので、WEBRickを利用し、ポートを分けることで複数Redmineを構築していました。WEBRickが固まることがあったので、cronで一日一回夜間に再起動して運用していました。 自分のグループで使ってみようという
あるプロジェクトのMercurial導入の軌跡 - 放牧日記
このエントリはMercurial Advent Calendar 2011 - PARTAKEの25日目です。 3月からMercurialを使い始めたので12月で9ヶ月目になります。一年の振り返りという事で、Mercurial導入の軌跡について簡単にまとめたいと思います。*1 Mercurialとの出会い Mercurialと出会う前はSubversionとちょっとだけGitを触っていました。とくにSubversionは仕事でかなりがっつりブランチの運用*2を行っていました。 嫌になるほどSubversionを使うプロジェクトでは次の問題が発生していました。 Subversionでのブランチマネジメントはマージ担当者の負荷が高すぎる リポジトリが巨大になりすぎてsvn stするだけでも20秒 リポジトリが巨大になりすぎてsvn upが終わらない 部分svn upし出す人が増え、整合性に関す
コミットコメントの書き方(我流) - 地平線に行く
Subversionのコミットコメントは、人によって多々書き方が違います。 ただ、後でコミットの内容を確認した時に 何も書かれていなかった 書いてあっても一行だけだった となっていて、詳細が分からず、本人に聞いたりドキュメントを探して確認する羽目になったことが何回もあります。 そうした経験から、コミットコメントを書く際には、あとで自分が困らないように、ほかの人が困らないように以下のようなポイントに気をつけて書いています。 一行目には、変更種別を書く 一行目には、必ず変更の種別を書くようにしています。 たとえば、 機能追加 仕様変更 不具合修正 リファクタリング などです。 また、仕事の時はそれと一緒に件名も書いて、太括弧【】に囲んで記述しています。 （例：【不具合修正：ログイン画面】） こうすると、変更理由をヒストリー一覧から探しやすくなります。 また、あとで見返したときに「このリビジョン
複数人(2-3人)でウェブサービスを開発するコツ - リート開発者ブログ
こんにちは。開発ブログ言いだしっぺの satoshi です。リートでは、AddClips と Lancers というサービスが現在の主力サービスですが、AddClips は1人のエンジニアが担当し、Lancers は2-3人 のエンジニアが開発を担当しています。 当たり前ですが、1人と3人では開発スタイルが大きく異なり、気をつけるポイントも全く違います。当たり前の事が多いのですが、リートで特に気をつけていることをご紹介できればと思います。 開発環境 VMware ESXi を使って開発環境は5秒で用意する 通常、VMwareはLinuxやWindows上で動作しますが、VMware ESXi はその上で直接、複数のVmware（仮想化マシン）を立ち上げることができます。 Vmwareを導入するために、Linuxを導入したりする必要はなく、その容量も32MBとコンパクト。しかも無償で利用可能
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オープンソースソフトウェアの育て方