タグ

バージョン管理とprogrammingに関するakishin999のブックマーク (5)

  • Semantic Versioning 2.0.0

    Semantic Versioning 2.0.0 Summary Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backward compatible manner PATCH version when you make backward compatible bug fixes Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. Introductio

  • コミットメッセージの書き方 - 2012-02-21 - ククログ

    はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常

    コミットメッセージの書き方 - 2012-02-21 - ククログ
  • 変更前をコメントアウトして残す習慣は未だ根強い (2012年現在) - 日々常々

    2020-03-11追記: タイトルの「未だ」がいつなのかわかりづらいので「2012年現在」を追加しました。 バカバカしい話ですが、ソースコードをSubversionなどでバージョン管理しているにもかかわらず、未だ修正前をコメントアウトして残す習慣は残っているところも多々あります。こういうのです。 // 2012/08/15 irof 修正開始 // hoge = fuga(1); hoge = fuga(2); // 2012/08/15 irof 修正終了 見た事無い方は、そのまま見ないままで生きていかれることを切に願います。 コメントの修正がある場合 2012/07/21にあった、SCMBCでこんなツイートがありまして。 この時点でお見せしたのはこんな感じ。 // 2012/07/21 削除開始 // // 間違ったコメント // 2012/07/21 削除終了 someMethod

    変更前をコメントアウトして残す習慣は未だ根強い (2012年現在) - 日々常々
  • 僕が社内ライブラリを OSS 化すべきだと思う3つの理由 - 鳩舎

    こんばんは、台風がヤバいですね。 こんな風に命の危険がそこそこあるときは、なんとなく人生について考えてしまいます。私はどこからやってきて、どこへ消えてゆくのか…… そんなことを考えていた折に、「社内ライブラリって OSS にしてしまうべきだよなー」と、ふと思ったので、考えていることをメモしておこうとおもいます。 「社内ライブラリ」 とりあえずこの社内ライブラリの前提を並べると 1つまたは複数のプロジェクトが参照しているライブラリである 製品的なビジネスロジックを内包しておらず、汎用的で、利用されているプロジェクトと密結合でない バージョン管理されている の3点は満たしておく必要があります。例えばニコニコ動画を OSS にするのはちょっとアレですし、課金部分を OSS にするなんてもってのほかだなーと思います。 そんなプロジェクトがあなたの会社にあるかないかはわかりませんが、いわゆる「この言

  • gitをテキトーに使って生産性を向上したユースケース - 西尾泰和のはてなダイアリー

    バージョン管理とかgitとかが「おおげさでめんどくさいもの」だと思う人は多い。でも、それは生産性向上のチャンスを逃していると思う。特に業務として多人数で開発している人たちの「変更前にはまずトピックブランチ」というやり方が、それはそれでよい方法なんだけど、いかにもめんどくさそうで尻込みさせてしまうのではないか。 先日の日曜日に、テキトーなgitの使い方をして、とても役に立ったのでユースケースとして報告しておこう。ただし、若干特殊な環境なのでここでやった方法が直接そのまま皆さんの所で使えるとは限らないが。 まず環境の説明。プロジェクトは「次の日曜日、新感覚シューティングゲームを展示します」で紹介している、テーブル型ディスプレイで動くシューティングゲーム。メインは @tokoroten で、ソースコードをバリバリ変更している。土曜日にとりあえず動くところまでは行った。改善点は山積みだ。使える時間

    gitをテキトーに使って生産性を向上したユースケース - 西尾泰和のはてなダイアリー
  • 1