はじめに みなさまのプロジェクトではどのようにバージョン管理を行っているでしょうか。 ここでのバージョン管理とは具体的にはどのようなブランチを作ってどこにマージするか、リリースはどのように進めるかといった事柄を指しています。 今日は数あるバージョン管理戦略の中で比較的新しく提唱されたGitlab flowというフローを中心にして話していきたいと思います。 最近アプリの開発においてこのGitlab flowが個人的には一番しっくり来ているのでオススメしたいです。 有名なフロー gitは分散型のバージョン管理システムとして一世を風靡しており、いまや事実上のデファクトスタンダートです。 名前のとおり分散している（ローカル・リモートが明確に分かれている）ことやブランチ・コミットの編集も非常に容易で柔軟性が非常に高いです。 一方でその柔軟さゆえにルールをきちんと決めなければ各個人のフローが大きく異な
Yosuke Furukawa @yosuke_furukawa @sonots masterは絶対に安定して動作させたいとかそういう思想だよね。developブランチ、 develop で安定してきたらmasterにmergeするって思想だけど、僕も最近作ってない… 2014-05-30 11:16:02 そのっつ (Naotoshi Seo) @sonots @yosuke_furukawa master ブランチが絶対安定してるなら、今度は release ブランチいらない感ある。で、どちらかというと release ブランチを安定させて master ブランチで開発すれば良い。そのほうが github とも親和性高い感ある。 2014-05-30 11:38:51
GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点について指摘していた記事があったのでメモ。 【参考】 GitHub でチケット駆動開発とプルリクエスト駆動開発を併用する - mallowlabsの備忘録 GitHub の Issue をあとから Pull Request にする (あとからコードを添付する) - Qiita [キータ] Fujimura ? GitHubで既存のissueに対してpull requestする hub コマンドで github から fork して pull request をさくっと - #生存戦略 、それは - subtech Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記 bleis-tift/Git-Hooks かんばん！～もし女子高生がRedmineでスクラム開発をしたら（6）：Redmine×Gitのハー
こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います： ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ
この記事は会社内の別チームの方に、 僕の今のチームで git をどう運用してるかを ワークショップ形式で説明するための資料である。 事前準備 git と git-flow を入れておくこと 参考資料(Macでgitとgit-flowインストール) - xcode cli toolインストール -- https://daw.apple.com/cgi-bin/WebObjects/DSAuthWeb.woa/wa/login?appIdKey=d4f7d769c2abecc664d0dadfed6a67f943442b5e9c87524d4587a95773750cea&path=%2F%2Fdownloads%2Findex.action - homebrew のインストール -- https://github.com/mxcl/homebrew/wiki/installation - b
ソースコードのレビューはシステムの品質を高めるのに大切な作業だ。GoogleやVMWareでも使われており、ブラウザを使って差分を確認してコメントができるようになっている。社内向けには拙作のSubversionソースコードレビューシステムの宍道湖がある（Rails製）。 Git向けソースコードレビューシステム この手のツールはSubversion向けのものが多かったが、Gitでも使いたいならGerritに挑戦してみよう。 今回紹介するオープンソース・ソフトウェアはGerrit、Git向けソースコードレビューシステムだ。 GerritはGoogleが大々的に発表している訳ではないが、Google社員が開発しておりAndroidのオープンソースプロジェクトにおけるソースコードレビューにも利用されている。他のシステム同様に差分を見て、そこにコメントすることが可能だ。 差分を見てコメントする 差分
tbaggery - A Note About Git Commit Messages A successful Git branching model » nvie.com Commit Often, Perfect Later, Publish Once—Git Best Practices だいたいこれらに書いてあることを考えている。 基本的にGit Successful Branch Modelで運用する。git-flowを入れて使っているけど、手でやってもそんなに面倒ではないし好きなようにしたらよさそう。 Subversionを個人で使っていたころはブランチはよくわからないけど恐しいものだったけど、Gitを使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう
今年から新たにペパボで導入された、技術者向けの評価制度については、こちらのエントリ で書いたのですが、本日、その一次評価が完了しました。 評価のプロセスは、一次はテクニカル・マネージャーによる評価、二次は経営会議メンバーによる評価、と二段階の評価となっています。 自分が担当した一次評価の詳細は、以下のようになっています。 シニア、またはアドバンスドシニアに上がりたい人には、自ら立候補してもらう。 立候補する人は、定められたフォーマットにしたがって、自分がそのポジションにふさわしいと思う理由や実績について Markdown で書き、指定した Git リポジトリに push する。（「定められたフォーマット」と言っても、最初に名前、次に希望のポジションを書いてもらうだけで、それ以外は自由。） 文書に提出後、一人一人と面談を行う。 文書の内容と面談の結果にもとづいて、各人が提出した文書の末尾に、
＠IT編集部 2009/3/23 分散型のバージョン管理システム「Git」が注目されている。msysGitはGitをWindows環境で試してみるのに丁度いい（編集部） ソフトウェア開発を複数のメンバーによる共同作業で進める場合、効率よく情報（設計書やソースコードなど）を共有するために、何らかの構成管理ツールを利用することが多くなっています。 これまではSubversion（SVN）がデファクトスタンダードとなっていましたが、ここに来て分散型のバージョン管理システムが勢力を伸ばしています。主な分散型バージョン管理システムとして、Git、Mercurial、Bazaar、Darcsなどが挙げられます。詳細については、「分散バージョン管理Git/Mercurial/Bazaar徹底比較」を参照してください。 今回紹介するmsysGitは、GitをWindows環境で使うためのソフトウェアです。
「Git」使ってますか？ 近年、分散バージョン管理システム「Git」が急速にシェアを伸ばしています。筆者は、チケットシステムやバージョン管理の勉強会などを開催したりしていますが、Gitユーザーがかなり増えてきていると感じます。 しかしながら、そのような勉強会でアンケートを取ってみると、実案件では半分以上の人がSubversionを利用しており、Gitの導入はまだまだ進んでいません。移行コストが掛かったり、プロジェクトマネージャ層への知名度がまだまだ低いというのもありますが、理由の1つとして、ユーザー管理が煩雑であったり、アクセス制御に関する情報が不足しているということもあると思います。 そういうわけで本稿では、Gitリポジトリのユーザー管理やアクセス制御を簡単に行う「Gitolite」を紹介します。 なお、本稿ではGitの利用方法については紹介しませんので、Git自身の使い方については改め
Kalid Azad、 2007 年 10 月 15 日、 原文 (original post) 従来のバージョン管理は、ファイルをバックアップ・追跡・同期するのに役立った。 分散バージョン管理を使うと、変更内容を共有するのが楽になる。 さぁ、両方の長所を活かすんだ。簡単なマージと一括管理されたリリースを。 分散だって? これまでのバージョン管理で何がまずいの? 別に…。 さっ、気を取り戻したければ、 バージョン管理へのビジュアルガイド(英語) を読んで。 もちろん、「古くさい」システムを使っているとバカにする人もいるだろう。 けれど、私はそれで全然かまわないと思う。 どんなバージョン管理システム(VCS)を使うにしても、プロジェクトにとっては前向きな一歩なんだから。 集中型バージョン管理システムは 1970 年頃に現れた。 その頃プログラマーには、シンクライアントと “big iron”
※ 翻訳用のリポジトリ、作業状況は「マニュアルの翻訳状況」参照。 翻訳作業に協力してくださる方がいてくれるとうれしいです。
ずっと gitとsvkの違いってなんなのよ？ と思ってたんですが、この図とか説明読んでようやくわかりました。 Gitでは旧来のCVS型とGit型の二つの共同作業のモデルが使えます。これが混乱の元でした。 Gitのすごさを本当に体感するなら、gitを使うだけでは不十分でGit型のモデルにそって開発することが必須です。 CVS型 従来のSVN(CVS)のモデルです。pullをしてきて、pushで更新を戻します。 1つの公開リポジトリに対し、複数人がpushを行う pushにより他の人と競合するかも メインのリポジトリにpushすることを目指す 能動的 → 悪意のあるpushも可能 → "コミッター"を絞る必要あり Git型 githubっぽいモデルです。pullをしてきて、pullで更新を持って行ってもらいます。 全体がpullでまわるため、pushがプライベートな操作として隠蔽されてるのがポ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く