クリアなコードの作り方: 意図が伝わるコミットのしかた - 2012-03-13 - ククログ
コミットメッセージの書き方ではコミットをわかりやすくするためには以下の2つの条件を満たす必要があると書きました。 コミットの内容が分かりやすく説明されていること コミットの内容が小さくまとまっていること このうち「コミットの内容が分かりやすく説明されていること」についてはすでに説明済みです。今回は「コミットの内容が小さくまとまっていること」について説明します。 めざすところ 単純にコミットの内容を小さくするだけではわかりやすくなりません。それでは、どのような基準で小さくすればよいのでしょうか。 よく言われることは1つのコミットには1つの小さな論理的にまとまった変更だけにする、というものです。たしかにこれは重要です。しかし、これだけを基準とすると、人によっては大きめなコミットになってしまいます。人それぞれで論理的なまとまりの大きさが異なるからです。 1つのコミットでどうすればよいかを考えるの
コミットメッセージの書き方 - 2012-02-21 - ククログ
はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常
The importance of commit messages | Wildbit
Once you get past the prototyping, unit tests and the code what you have is the only real documentation anyone is going to update.— Something that sounds like “Code Complete” or another McConnell classic. A good software development process is all about communication.— 37 Signals about Basecamp. Thank you, Captain Obvious— Anonymous lolcat. Communication is the mantra of two of my long-time feeds.
On commit messages
In the last few weeks, I've had a surprising number of discussions about commit messages. Many of them were with developers new to a project, trying to get them started. So here's a list of things you should do when committing, and why you should do it. Hint: the linux kernel mailing list gets it right, go there to learn. Any software project is a collaborative project. It has at least two develop
Writing better commit messages by Louis Brandy
If you and your team are in the habit of writing good commit messages, it can save everyone a tremendous amount of time and effort. Other developers can very quickly see what you’ve done. It’ll also save tons of time tracking down commits from the past when you need to find them. A good commit message serves exactly two purposes: it gives other developers an explanation of the commit, and it gives
バージョン管理システムの歴史 - karasuyamatenguの日記
TortoiseCVSの作者がバージョン管理システムの歴史を各イノベーションがもたらした「驚き」を語りながらふりかえる： http://www.flourish.org/blog/?p=397 以下、自分の体験とごっちゃ混ぜにして要約する。原文を読むことを勧める。 ソースコードをテキストファイルとして保存する! (60年代) これすら常識でない時代があったこということがASCIIの歴史を読むとうかがえるらしい。 人力バージョン管理! (60年代) ソース管理部門にディスクを持っていくとそこのスタッフが顧客用の製品をビルドしてくれた… SCCS： 複数のバージョンを一つのファイルに保存! (70年代) McIlroy先生の“An Algorithm for Differential File Comparison”によって可能になったらしい。 http://en.wikipedia.org/
Martin Fowler's Bliki in Japanese - フィーチャーブランチ
@@ -1,25 +1,29 @@ http://martinfowler.com/bliki/FeatureBranch.html -gitやMercurialの様な分散バージョン管理システム(DVCS)の台頭と共に私はブランチとマージ、どの様に継続的インテグレーション(CI)に適合に向けての戦略に関して、より多くの会話を見てきた。ここ、特にフューチャーブランチのプラクティスとどの様にCIに適合させるかに関して、少し戸惑いがある。 +gitやMercurialの様な分散バージョン管理システム(DVCS)の台頭と共に私はブランチとマージ、どの様に継続的インテグレーション(CI)に適合に向けての戦略に関して、より多くの会話を見てきた。ここ、特にフィーチャーブランチのプラクティスとどの様にCIに適合させるかに関して、少し戸惑いがある。 -シンプルな(分離した)フューチャーブランチ +
Zed ShawがFossilを使う理由 - karasuyamatenguの日記
http://sheddingbikes.com/posts/1276624594.html mongrelと「Ruby is Ghetto」で有名なハッカーZed ShawはバージョンコントロールにFossilというSCMを使っている。 http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki とりあえず使ってみたい人はここを見るといいでしょう： http://d.hatena.ne.jp/Jxck/20100714 テングはgitを使っているので、新しいscmの話とかあまり関心ないが、sqliteの作者Chris Newmanが作ったものであるのなると興味がわく。 fossilを一言で言うと「誰でも簡単にホスティングできるプロジェクト管理ソリューション」だろう。githubやbitbucketのようなSCMのフルサービスが提
分散バージョン管理で間違いないって、ベイビー - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2010年3月17日 水曜 しばらく前に、ジェフと私はStack Overflowポッドキャストにエリック・シンクを迎え、バージョン管理について騒がしく議論し、とくにトレンディな分散バージョン管理システムであるMercurialやGitのことを取り上げた。 そのポッドキャストで私はこんなことを言った。「私に言わせれば、ブランチやマージが簡単にできるようになるというのは、単に同僚たちがもっとブランチやマージをするようになるということで、余計混乱させられるだけのことだよ」 わかると思うけど、あのポッドキャストは前もって入念に準備したりはしていない。単に2、3人集まって、いい加減なおしゃべりをしているだけだ。そのため、しばしば我々の主張する内容が、少し専門的な言い方をするなら、「ちげーよ」ということになる。間違っているのはたいてい細かい部分か趣旨のどちら
Wikihub :: wikihub-wiki
Wikihub (wikihub.org) の使い方 Wikihub は，Git や Subversion にて文書を管理したいコマンドライン大好きなプログラマーさんたちが，文書を自分にあったやり方で更新しつつ，バージョン管理しつつ，でもウェブでも見たい，という欲張りな要望をかかえているだろうと勝手に判断し作成された，バージョン管理連携wikiインターフェースです． 現在クローズドベータとして運営中． この文書もGithubをリポジトリとした，wikihub上で管理されています． http://github.com/sotarok/wikihub-wiki/tree/master ログイン/ユーザ登録 OpenIDのみ対応しています． 現在クローズドベータなので，使ってみたい方は，twitter にて，@sotarok までお声がけください．DMにて Closed beta registe
実用レベルに達したWindows向けGitクライアント「TortoiseGit」でGitを始めよう | OSDN Magazine
Windowsで利用できるGUIのGitクライアントの1つに「TortoiseGit」がある。TortoiseGitはまだ開発段階のソフトウェアではあるが、2009年6月5日にリリースされたバージョン0.7.2.0では多くの機能が実装され、実用的に動作するようになった。本記事ではこのTortoiseGitを用いて、Windows環境でGitによるバージョン管理を行う方法について解説する。 近年、「Git」という分散バージョン管理システムが注目を浴びている。しかしGitはWindowsサポートが弱く、またGUIで利用できる使いやすいクライアントがなかったため、特にWindowsユーザーには導入や利用へのハードルが高かった。そこに登場したのが、Windowsのエクスプローラに統合され、GUIでGitによるバージョン管理が行えるツール「TortoiseGit」である。TortoiseGitはまだ
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
プログラマだけじゃない。ライターな方にも便利なバージョン管理の使い方·Flashbake MOONGIFT
元々バージョン管理システムはプログラマが利用していたシステムだ。だが、その便利さゆえにシステム開発会社などではデザイナの方も利用している。さらにそれが広まると全社的に使われることもある。 ライターの方に便利なバージョン管理の使い方 バージョン管理を使えば、間違っても戻ることができるので思い切った作業も行えるようになる。それを活かしたライター向けのソフトウェアがFlashbakeだ。 今回紹介するオープンソース・ソフトウェアはFlashbake、Gitを使ったライター向けバージョン管理システムだ。 FlashbakeはベースとしてGitを使っている。Gitであればローカルにリポジトリがあるので手軽にはじめられるのが良い。さらにGitHubなどに公開するという手もある。Flashbakeの使い方はまずGitのリポジトリを作成後（もしかすると不要かも）、Flashbakeコマンドを実行して進めら
tortoisegit - Project Hosting on Google Code
TortoiseGit provides overlay icons showing the file status, a powerful context menu for Git and much more! Learn more about TortoiseGit. Download News2024-04-30 | Released TortoiseGit 2.16.02024-04-15 | Security issue in PuTTY (CVE-2024-31497), please install TortoiseGit 2.15.0.1 hotfix2023-10-03 | Released TortoiseGit 2.15.0 @TortoiseGit
bzrの使いかた - PukiWiki
別の場所からリポジトリをコピーする † データを置くディレクトリに移動する bzr branch （コピー元のリポジトリ） 「使用手順」へ ↑ 自分のデータをリポジトリにする † 該当するディレクトリに移動する bzr init 必要に応じて .bzrignore を作っておく bzr add 引数にファイル名やディレクトリ名を指定できる． ディレクトリを指定するとデフォルトではリカーシブに処理されるので， find . -name '*.tex' | xargs bzr add とかすると良いかも． ↑ まずローカルリポジトリにて † bzr merge （リモートリポジトリ） → リモートリポジトリのファイルをコピーする bzr status → 他人が何を更新したかを確認する ファイル編集・ファイル追加・ファイル削除などを行う bzr status → 自分が変更したファイル
Bazaar
はじめに Bazaar(以下bzr)はSCMと呼ばれるリビジョン管理システムの一つです。 CVSやSubversionなんかと違うのはbzrが分散SCMであるということです。 いつもはネットワークが使える環境でばりばり開発しているけど、 オフラインでも作業したいときには便利です。 Subversion+svkを使うのと似ています。 Bazaarを個人的に使う理由 レンタルサーバでコンパイルとかせずに導入できそうなバージョン管理ツールを探していたときに見つけたのが Bazaarでした。(当時はまだBazaar-NGという名前だった気がする) 分散だとかってのは正直どうでもよかった。 今だと、Mercurialが優勢なのかな。 実際に使ってみて、こんなあたりが気にいっている。 これは、Bazaarに限らないかもしれないことに注意。 導入コストWindowsでもバイナリパッケージが用意されている
Bazaarの紹介 : DSAS開発者の部屋
私は以前までバージョン管理システムには Mercurial を利用していたのですが、 最近 Bazaar に移行しました。 先日 1.9 がリリースされましたので、これを機に Bazaar を紹介します。 現在、日本で一番使われているバージョン管理システムはSubversionだと思うのですが、 最近は分散型のバージョン管理システムがオープンソース界で人気になっていて、Bazaarはその一つです。 分散型バージョン管理システムの利点はたくさん有るのですが、個人的に便利だと 感じる点は、(1)ネットワークにつながっていなくてもバージョン管理できる、(2)Subversion よりもマージが楽、(3)リポジトリのバックアップが楽、というところです。 分散型バージョン管理システムでよく使われているものに、git, Mercurial (hg), Bazaar (bzr) があります。git は
Git入門 - トップページ
※ 翻訳用のリポジトリ、作業状況は「マニュアルの翻訳状況」参照。 翻訳作業に協力してくださる方がいてくれるとうれしいです。
JapaneseMercurial - Mercurial
Latest News 2024-02-23 Mercurial 6.7rc0 released! (download) 2024-02-12 Mercurial 6.6.3 released! (download) 2024-01-11 Mercurial 6.6.2 released! (download) 2023-12-07 Mercurial 6.6.1 released! (download) 2023-11-21 Mercurial 6.6 released! (download) 2023-10-06 Mercurial 6.5.3 released! (download) 2023-09-06 Mercurial 6.5.2 released! (download) 2023-08-07 Mercurial 6.5.1 released! (download) 2023-
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Discover gists
