Gitを使った開発・運用フローの紹介
私の所属している会社では、2年程前にバージョン管理システムをSubversionからGitに移行し、現在まで開発フローを試行錯誤してきました。ようやく形になってきたということで、守秘義務に接触しない程度に紹介＆考察していきたいと思います。 形になってきたとはいえ、まだまだ試行錯誤中ですので色々なツッコミは大歓迎です。 現在の開発フローの俯瞰図# 現在の開発フローを俯瞰してみると大体下記図のような感じになっています。途中で図を書くのが面倒になった都合上、Jenkinsさんが１人しか居ませんが、実際はmasterブランチの他にreleaseブランチも監視してもらっています。 以降この図を元に話を進めていきたと思います。 Gitoriousを利用して自由に開発# GitoriousというGitHubに似たサービスがあります。このGitoriousはオープンソースとしても公開されていますので社内に
【翻訳】Gitをボトムアップから理解する
John Wiegleyさんの "Git from the bottom up" を翻訳しました。 元PDFはこちらからダウンロードできます： http://newartisans.com/2008/04/git-from-the-bottom-up/ 元記事のライセンスがクリエイティブコモンズのBY-SAであったため、この翻訳もBY-SAとなります。 ライセンスを守って自由にご利用ください。（詳しくは記事内の最初にも書いてあります） 翻訳ミスの指摘や改善の提案等があればブログコメントやTwitter(@oshow)などで遠慮なくどうぞ。 Git をボトムアップから理解する Wed, 2 Dec 2009 by John Wiegley 私が Git を理解しようと調査した時、高級なコマンドの視点から眺めるよりボトムアップ式に理解することが役立った。そしてボトムアップ視点で見る Git が
Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering
こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います： ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ
多人数開発で Git を使う場合の環境構築 | GREE Engineering
こんにちは、インフラやってる sotarok です。最近、社内でも「sotarok は そーたろっくと読む」という誤解が広がっていましたので改めて自己紹介しますと、sotarok と書いて「そーたろー」または「そーたろー・けー」と読みます。ロックしてないのでよろしくお願いします。 今日は、Git の話です。 GREE ではずっと Subversion を使っているという話を、以前開発環境の話をしたときに少し触れたことがあります。Subversion での運用方法も、GREE では割と面白い運用をしているのでその話もどこかでしたいのですが、まあ、それは今回は置いておきましょう。どこかで聞いてください。 GREE もその昔 CVS から Subversion に移ったのですが、時代は流れるもので、いよいよ Git 化という流れがきています。Subversion と Git の違いを今更あえて挙
Git使いがMercurial使いに転職するとき設定しておくべきMercurial拡張 | Webシステム開発／教育ソリューションのタイムインターメディア
Mercurialは、Merucurial拡張という拡張モジュールを使って、Merucrialの挙動をいろいろ拡張できるようになっています。 デフォルトのままだと使いにくいので、Mercurialを使う上で便利にしてくれる拡張を設定しておきましょう。 デフォルトでバンドルされているMercurial拡張は、Using Mercurial Extensionsにまとめられています。 今回はGit使いがMercurial使いに転職するときに、Gitで実現できたことをMercurialで実現するための、組み込み拡張、および、サードパーティ製の拡張について紹介します。 色づけしよう ブランチの確認、diff、パッチ等々、色づけされていないとつらいです。 というわけでGit同様に色づけしましょう。 Color Extensionはすでにバンドルされているので、.hgrcに次の記述を加えましょう。 こ
Gitリポジトリ中のサブディレクトリを別のリポジトリにする - Pixel Pedals of Tomakomai
clone して filter-branch を使うと、サブディレクトリを別のリポジトリにできます。 例えば、/tmp/hoge にあるリポジトリに hoge と subdir/foo と言うファイルがあって、ログが以下とすると、 % git log -p --pretty=oneline ac27f0a1f18108cd81be52634b07228c6bb95a0b Added foofoo diff --git a/subdir/foo b/subdir/foo index 257cc56..b4c9d55 100644 --- a/subdir/foo +++ b/subdir/foo @@ -1 +1,2 @@ foo +foofoo a6cc83ca5cec477444f0d63359ef12dede648eb5 Added hogehoge diff --git a/hoge
tmp コミットのための独自サブコマンド git-now - アジャイルSEを目指すブログ
追記[2011/09/26] git-now のurlをgistからgit-hubに変更しました。 追記[2011/10/17] ライセンスはGPLです 一時的なtmp コミットや、簡単なログメッセージのコミット（push 前にログメッセージを整えています）を作るとき、今まで↓みたいな事をしていました。 で、これを使いながら「〜〜も出来たら便利かもー」とかつぶやいていたら、隣の人が一晩で（ｒｙ と、そんな感じで出来たgit-now の紹介 簡単な実行例 コマンド $ git now これで、版管理されているファイルのtmp コミットが作成できます。 コミットメッセージ例 [from now] Tue Dec 7 23:00:24 2010 diff --git a/hello.py b/hello.py index 51cff9f..9e84b86 100644 --- a/hello.p
MercurialとGitのブランチの違い - wyukawa's diary
MercurialのブランチというのがどういうものでしかもそれがGitと同じなのかどうかもいままでよくわからなかった。 その辺のモヤモヤがこれを読んで理解できた（気がする）。 experimentalworks » Blog Archive » Mercurial bookmarks A Guide to Branching in Mercurial / Steve Losh まずMercurialでは以下の4種類のブランチがある。 リポジトリをcloneしてつくるブランチ hg bookmarkで作るブランチ hg branchで作る名前付きブランチ 名無しブランチ リポジトリをcloneしてつくるブランチは hg clone test-project test-project-feature-branch というように単純にcloneして新機能を開発してあとでマージなりリベースなりする
Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記
id:bleis-tiftによるgitのフックスクリプト集がマジ便利。 gitとredmineを使ってる人はぜひ使うべき 機能 チケット番号付加 id/12というブランチで作業してるときは、コミットメッセージの末尾にrefs 12を自動でつけてくれます Redmineのチケットごとにブランチを切るようにすると、マジ便利 masterブランチへのコミット拒否 masterブランチへのコミットを拒否する 必ずトピックブランチを切るようになる pushされたときにチケットIDのないコミットの拒否 チケットIDのないコミットのpushを拒否します ダウンロード・インストール方法 https://github.com/bleis-tift/Git-Hooks に書いてある通りにすれば簡単にインストールできます
Git入門 ゼロから始めるGitドリル
gitの勉強をしつつ取ったノートを記事化しました。一応これを読めばざっくりとした導入やSVNとの違いが分かってもらえるように書いたつもりです。svnを使った経験があることを前提に進めていきます。 svnの場合、一つのレポジトリに対して認証のあるユーザが変更を報告していくユースケースをとっています。gitの場合は、個々のローカルマシンにリポジトリが分散されて配置され、お互いに変更を報告しあうユースケース。これはLinuxの伝統的なバザール方式の開発を想定しています。そのため例えばカフェや電車で開発したり、マスターはgithubやgitfarm（Git Hosting参照）にしておいて時々ローカルの変更を報告することも可能です。 目次 インストール 基本操作 Gitリポジトリの作成 ブランチの作成。 タグ ファイルを無視する 索引の理解 取り消し 導入 --hardと--softの違い 一個の
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 に限らず、同じ名前のサブコマンドでも意味が異なるものがいくつかあります。 その中
Better Subversionとしてのgit-svn
普段のプログラミングにgitを使用しているのだけど、実際の現場ではまだまだsvnが主流だったりする。svnを直接使ってもいいのだけど、やはりローカル上でコミットしたいとか、複数のコミットを1つにまとめたいとか、トピックブランチを切りたいとかあるのでそれはsvn単体だと厳しい。そんなわけでBetter SVNとしてのgit svnの紹介、と言うよりメモ。 リポジトリのクローン git svn clone repository_url これでsvnリポジトリをgitリポジトリとして取得できる。大きめのリポジトリだと結構時間がかかるのでのんびりと。svnリポジトリの構成がtrunk/branches/tagsという一般的な構成であればオプション-を付けるのがおすすめ。trunkをmaster、branches/tagsをremote branchとして扱うようになる。個別に指定する方法もあるので
プロジェクトで Git を使ってみた感想とか - miauのブログ
2009/12〜2010/06 くらいまでの案件で Git を使ってみたので、その感想その他です。毎度長くてごめんなさい。 Subversion の経験はそこそこある状態でのスタートです。 リポジトリ構成のポイント ソースコードは Git、ドキュメントは Subversion で Git はファイル名をバイト列で管理するので、Windows と Linux の両方で使いたい場合は日本語名のファイルは使えません。（今のところ対応予定もないとのこと。ファイルのコンテンツやコミットログについては UTF-8 で統一できるので問題ありません。） ソースコードについては日本語名のファイルは含まれないので Git 管理でいいと思いますが、ドキュメントに関しては難しいので Subversion 管理にしました。 リポジトリの単位は細かく Git では Subversion と違ってリポジトリの一部をチェ
プログラミング/gitosis による git サーバーの管理
gitosis について † gitosis は、（複数の）git リポジトリの管理を容易に行うためのソフトウェア。 詳しい説明は、http://openbooth.org/archives/60.html あたりを参照のこと。 gitosis により管理されるサーバーには git clone gitosis-account@some.your.server.com:some-project のような形でアクセスすることになる。 some.your.server.com gitosis をインストールしたサーバーのアドレス gitosis-account some.your.server.com に(通常は)１つだけ作成された gitosis 用のアカウント名 すべてのユーザーはこのアカウントを通じてリポジトリにアクセスする some-project git リポジトリの名前 １つの gi
PukiWiki 【FrontPage】
なんだかやけに長い説明ばかり検索に引っかかったので書きました。 Linuxのローカル環境でDockerコンテナ内のXアプリ（GUIアプリ）を利用するには $ xhost localhost + を実行した後に $ docker run --rm --net host -e "DISPLAY" container_image_name x_app_binary_path とすれば良いです。 もっと読む SSHなどよく知られたサービスポートで何も対策せずにいると数えきらないくらいの攻撃リクエストが来ます。不必要なログを増やしてリソースを無駄にし、もし不用意なユーザーやシステムがあると攻撃に成功する場合もあります。 SshguardはC作られており、flex/bisonのパーサールールを足せば拡張できますがカスタム版をメンテナンスするのも面倒です。必要なルールを足してプルリクエストを送ってもマー
git-svnの使い方を覚えた - idesaku blog
分散SCMを使いたい！と思う今日この頃。 仕事ではSVN（Subversion）を使っているのだが、ちょっとしたお試し編集をするためにブランチを作ることに抵抗がある。ブランチは欲しい、大きめな変更をコミット無しで行いたくない、やはり少しずつコミットして進めていきたい。しかし、変更が全て記録されてしまうのがいただけない。ログが残るのは良いことなのだが、本当に使うかどうか未知数な実験的プログラミングのログまで残したくない。使うと決まってから初めて残すようにしたいのだ。 すまん、これまで一緒に仕事をしてきた人々よ。俺はこれまで「ログが残って困ることがなんかある？いらなきゃ無視すればいいだけなんだから、気にするな。ブランチでもなんでもバンバン作ってしまえ！」とうそぶいてきているわけだが…ハッタリかましてました！本当は俺も抵抗があるのだ。 そこで、分散SCMだ。さらにいうと、SVKがいまひとつ気に入
rebase について - ぐるぐる～
rebase 便利だよ、というだけのエントリです。 AA で書いてる部分は時間があれば画像に置き換えます。 rebase とは ブランチを作成した場所を変更することと理解しています。つまり、そのブランチの「親」を変更する、ということです。 もう少し動作に踏み込むと、指定したコミットの後ろに現在のブランチで行ったコミットをリプレイするように適用します*1。単なるリプレイではなく、その過程をいじくれるのが rebase のすごいところです。 単純な rebase はたとえばこんな感じです。 以下のようなリポジトリの状態があったとして (現在チェックアウトされているブランチは dev ということを表すのに * を使っています)、 1---2---3 *dev / A---B---C---D master次のコマンドを実行します。 $ git rebase masterこれにより、リポジトリの状態
TDD と Git についてメモ - ぐるぐる～
ついったーにつぶやいたものを中心にまとめました。 まだこれで正しいという確信を持てていないので、メモという位置付けでお願いします*1。 なので追記する可能性が高いです。 TDD でドキュメンテーションコメントを書くタイミング カテゴリを指定して実行するテストを分ける git stash の使い道 TDD でドキュメンテーションコメントを書くタイミング ここでは Git を前提にしますけど、rebase 使えるならほかのものでも大丈夫なはずです。 TDD でいつドキュメンテーションコメントを書けばいいのか、というのは、 Re:TDD を理解するためのまとめ - ぐるぐる〜 TDD Boot Camp の参加報告とか読んで - ぐるぐる〜 と、過去 (といっても半年も経ってないけど) ずっともやもやしてたんですが、 事前条件で楽できないかなーという考え - Logic Dice に対する自分な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
showmetheco.de steht zum Verkauf
Git + WinMerge + Cygwin