ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ
ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える
分散バージョン管理で間違いないって、ベイビー - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2010年3月17日 水曜 しばらく前に、ジェフと私はStack Overflowポッドキャストにエリック・シンクを迎え、バージョン管理について騒がしく議論し、とくにトレンディな分散バージョン管理システムであるMercurialやGitのことを取り上げた。 そのポッドキャストで私はこんなことを言った。「私に言わせれば、ブランチやマージが簡単にできるようになるというのは、単に同僚たちがもっとブランチやマージをするようになるということで、余計混乱させられるだけのことだよ」 わかると思うけど、あのポッドキャストは前もって入念に準備したりはしていない。単に2、3人集まって、いい加減なおしゃべりをしているだけだ。そのため、しばしば我々の主張する内容が、少し専門的な言い方をするなら、「ちげーよ」ということになる。間違っているのはたいてい細かい部分か趣旨のどちら
JoelもMercurialを使っている - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
私がSubversionをやめてGitに移った理由 | エンタープライズ | マイコミジャーナル
Javalobby - The heart of the Java developer community バージョン管理システムにGitやMercurialなどの比較的新しい分散型バージョン管理システムを採用する事例が増えている。もともとOSSプロジェクトで採用するバージョン管理システムは中央集権型のCVSが多かった。しかしCVSは厄介な面もあり、こうした問題を解決した同じく中央集権型のSubversionがCVSの次期候補として注目されていた。 CVSからGitへ、Fedora 13以降 止まらないGit人気、JRubyも移行 - 対抗馬はMercurial Git人気が止まらない、今度はGnome Gitバージョン管理システム採用拡大、Perl 5も移行 7つのバージョン管理システムを知る しかし現在のところ、バージョン管理システムは分散型のMercurialとGitに注目が集まって
コミットコメントの書き方 - wyukawa's diary
ソースコードのコメントの書き方についてある程度情報が出回っているように思うが、コミットコメントの書き方についてはあまり情報が無い気がするのでちょっと書いてみる。自分が出来ているかはおいといてｗ で、これはリポジトリとバグ管理システムとセットで考えなくちゃいけないと思っている。まあ要するにTracやRedmineを使ったチケット駆動開発前提の話です。つまりコミットコメントにはチケット番号を書け。以上、って話でもあるｗ コミットにはタグやブランチ作成のコミットを除くと大きく分けて２種類あると思う。１つ目はバグ修正のためのコミットで２つ目は機能追加のためのコミット。リファクタリングは２つ目に属するとする。 コミットはバグ修正、機能単位つまりチケット単位で行うべきだと思ってる。複数のバグ修正のためのコミットを１回でやられるとどのコミットがどのバグ修正に関連付いているのかわからない。こうなっちゃうと
SVNリポジトリの管理方法の追記 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
入門Mercurialの感想 - プログラマの思索
Mercurial本「入門Mercurial Linux/Windows対応」の著者フジワラさんから献本して頂いたので感想をメモ。 【元ネタ】 Mercurial の利用 特集：Mercurialではじめる分散構成管理｜gihyo.jp … 技術評論社 スィンプロ (sinproject) Windows Vista 環境で TortoiseHG（Mercurial）を利用してバージョン管理とバックアップを行う (3) ダウンロード - TortoiseHg - SourceForge.JP 「入門Mercurial Linux/Windows対応」は分散バージョン管理Mercurialの入門本。 平易に書かれていてとても読みやすい。 また、Mercurialのコマンド一覧が付録にあるので、リファレンスとしても使える。 エピローグに「あ！構成管理って楽しいんだ？！」という節がある。 Mer
SVNリポジトリの管理方法 - プログラマの思索
かおるんさんの記事のコメントで、誤った意見を書いてしまったので修正しておく。 【元ネタ】 Subversion のフォルダ構成 - かおるんダイアリー Subversionのフォルダ構成 | Ryuzee.com Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所 InfoQ: 複数のアジャイルチームでのバージョン管理 【問題】 SVN直下のディレクトリは、branch/tag/trunkになっている。 ソースやドキュメントはどこに配置すべきか？ 【結論】 管理したい一つのまとまり(プロジェクト)単位で、trunk/branch/tag を作った方がブランチを管理しやすいと思っていた。 最初はtrunkの中にソースやら仕様書を配置して、管理方法がよく分からなかった。 でも、さかばさんと議論してみて、ryuzeeさんのやり方が良いと思う。 思い出してみたら、下記の
ドキュメントも構成管理すべきだ - プログラマの思索
SVNで構成管理する時の良い記事が公開されたのでメモ。 【元ネタ】 Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所 SVNの使い方の記事はネット上にいくらでもある。 しかし、上記の記事で重要と思われる内容は、構成管理や変更管理の考え方を初心者向けに分かりやすく説明している点と、ドキュメント管理に構成管理の考え方を入れるべきだという主張だ。 CMMIの観点では、ソフトウェア構成管理は「変更管理を含むソフトウェアの構成を制御・管理できていること」と定義されている。 この考え方に基づくと、バージョンとは実はプロセスのベースラインを意味する。 つまり、リリース時にバージョン(又はタグ)を付けるタイミングは、開発者から顧客へ、あるいは営業チームから顧客へ、などのように、他者へ成果物を手渡すタイミングと同一なのだ。 構成管理が変更管理と密接に関係する理由は、上記のような
Google CodeがGitではなくMercurialを採用へ － ＠IT
2009/04/28 米グーグルは4月24日、ソフトウェア開発プロジェクトのホスティングサービス「Google Code」で、これまでのSubversionに加えて分散バージョン管理システム（DVCS）の「Mercurial」のサポートを開始すると発表した。現在はプレビューリリースで、一部のプロジェクト利用者に提供。一般リリースに向けて、いくつかの課題を解決していくという。Google Codeでは、Mercurialサポートのために、一般のMercurialがオブジェクトの保存に使うOSネイティブのストレージに代えて、グーグルの分散データベースシステム「BigTable」を使うように書き換えたという。 DVCSとしては、MercurialのほかにGitやBazaarが知られている。従来からある中央管理型のバージョン管理システムに比べて、分散開発がやりやすいことから、普及が進んでいる。例え
これからGitを始める人が読むべき記事のまとめ : akiyan.com
これからGitを始める人が読むべき記事のまとめ 2009-05-13 candycane(RedmineをCakePHPでPHPに移植するプロジェクト)の開発でGitの素晴らしさを痛感したので、これはもう全力でGitを広めるべきだと思いました。そこで、これからGitを始める人が読むべき記事をまとめてみたいと思います。 なお、Gitの発音は「ぎっと」です。 目次 Gitの開発者による45ページの特集記事「WEB+DB PRESS vol.50 はじめてのGit」 WEB+DB PRESS Vol.50 このサイトから -人 が購入しました 全体で -人 がクリック posted with amazlet at 09.05.13 WEB+DB PRESS編集部 技術評論社 売り上げランキング: 380 おすすめ度の平均: 森田創特集(?) perl, PHP, SQL Amazon.co.jp
分散バージョン管理システムGitの使い方入門 | OSDN Magazine
バージョン管理システムと言うとSubversionやCVSが有名だが、近年急速にユーザーを増やしているバージョン管理システムに「Git」 がある。GitはLinuxカーネルの開発リーダーとして知られるLinus Torvalds氏が中心となって、Linuxカーネルの開発に使用する目的で開発した分散型バージョン管理システムである。2005年に開発が開始されて以来さまざまなプロジェクトでの採用が進み、現在ではPerl 5やRuby on Rails、Android、Wine、X.orgなど、有名な大規模プロジェクトで採用されるに至っている。 本記事では、このGitを使用するのに必要な「分散型バージョン管理システム」の基本的な考え方を紹介するとともに、Gitの導入方法や基本的なGitの使い方について解説する。 分散バージョン管理システムとは？ GitはLinuxカーネル開発で用いられることを前提
分散バージョン管理Git/Mercurial/Bazaar徹底比較
分散バージョン管理Git/Mercurial/Bazaar徹底比較：ユカイ、ツーカイ、カイハツ環境！（3）（1/5 ページ） Subversionとは一味違う「分散バージョン管理」とは？ 最近、Linuxをはじめ、Ruby on Rails、MySQL、OpenSolarisなどのオープンソースプロダクトが次々と分散バージョン管理システムを導入し始め、「Git」「Mercurial」「Bazaar」といった、分散バージョン管理システムが注目を浴びています。 本稿では、バージョン管理ツールのデファクトスタンダードであるSubversion（以下、SVN）と分散バージョン管理システムを比較しながら、メジャーな分散バージョン管理システムであるGit、Mercurial、Bazaarについて紹介していきます。 集中型と分散型 最初に、集中管理方式（または、集中型）のバージョン管理システムと分散管理
チケット駆動開発の本質はバージョン・ファースト - プログラマの思索
チケット駆動開発(TiDD)について考えていることを書く。 ※注意：チケット駆動開発(Ticket Driven Develpment)の略語は、「TDD」だとテスト駆動開発(Test Driven Develpment)と間違えやすいので、「TiDD」と以降呼ぶことにする。(命名者：えと～さん) 【元ネタ】 チケット駆動開発は、まちゅさんによって提唱されている。 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) 【1】チケット駆動開発のプラクティス チケット駆動開発は定義そのものがあやふやなのだが、僕は下記4個ののプラクティスがあると思う。 ※注意・下記のプラクティスはあくまでも僕個人の考えであることを断っておく。 【1-1】チケット・ファースト(Ticket First) プロジェクト内部の作業は、チケットを受け取ってから始まる。 つまり、工数が発生す
ソフトウェア構成管理に至るまでの道のり - プログラマの思索
「何故、設計書をバージョン管理するのか？」という疑問から、ソフトウェア構成管理について考え直してみる。 ＃あくまでもメモ書き。 【元ネタ】 ■[development][trac]構成管理ツールをいかにして導入するか ■[システム開発][構成管理]構成管理ツールはどのようなタイミングで導入し、どのように活用すべきなのだろうか？ ■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理 ソフトウェア構成管理 【1】バージョン管理が無かった頃 今でも多いが、WordやExcelの設計書をバージョン管理していないプロジェクトは多い。 その時の最大の問題点は、■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理 にその理由が書かれている。 ほっておくと自然増殖してくるのが、下記のような形式のドキュメント
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
