変更前をコメントアウトして残す習慣は未だ根強い (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
「うわっ…私のバージョン管理、ダメ過ぎ…？」を解決するGitの使い方“超”入門
「うわっ…私のバージョン管理、ダメ過ぎ…？」を解決するGitの使い方“超”入門：かんばん！～もし女子高生がRedmineでスクラム開発をしたら（5）（1/3 ページ） 本連載は、ちょっととぼけた女子高生の姉妹が今注目のアジャイル開発手法であるスクラムとプロジェクト管理ソフトの「Redmine」を使って、システム開発をするというフィクションです。 これまでのお話 本連載は、ちょっととぼけた女子高生の姉妹が今注目のアジャイル開発手法であるスクラムとプロジェクト管理ソフトの「Redmine」を使って、システム開発をするというフィクションです。 ひょんなきっかけから電子目安箱（カウンセラー）を開発することになった「ぷりん」と「まいん」の姉妹。第1回の『高校生になって初めてスクラムを始めました～「ストーリー」で何を作るかまとめよう』、第2回の『スプリントと“かんばん”でチームのビートを刻め!! ～ス
イラストでわかる！git入門の入門
こんにちは、アシアルの志田です。 社内でもgitが浸透し、皆バージョン管理といえばgitだよね、という空気になってきました。 ですが、これまでバージョン管理システムを使ったことがない人にオススメしても、 「gitて…まあ…そりゃ…ねえ、いつかやらないといけないけど…」 「ギット？ジット？俺はgiはジと読む派なので、gitは胡散臭いと思う」 「そもそもバージョン管理して何が嬉しいの？なんか難しそうでいやだ」 というような反応ばかりでした。 きっとみんな、gitって難しくて訳のわからんもんだと思っているのでは？と思い、 今回はgit入門の入門、gitってなんだ？というところから、簡単にgitを使う際の流れについてご説明します。 ちょっと不安を覚えるようなイラストがついていますので、頑張って読んでください。 バージョン管理ってなに？ プログラムを書いていて、こんなことありませんか？私はあります…
【旧版】git入門 (全22回) - プログラミングならドットインストール
旧版のレッスンは更新を終了しており、現状と異なる場合があります。サポートも終了しておりますので、最新版への移行をお願いします。
Subversion・Git・Mercurialの比較 - プログラマの思索
Subversion・Git・Mercurialの比較のために過去の記事や関連資料をリンクしておく。 【比較】 SVN / Git / Hg 比較表 ? TortoiseGit Japan 【Subversion】 Subversion によるバージョン管理 svnbook.ja.pdf Subversionを見直せ: プログラマの思索 Subversion/運用方法 - ピノキヲ IT Wiki 【Git】 Pro Git 日本語版: プログラマの思索 A successful Git branching model: プログラマの思索 git-flow による構成管理とRedmineの関係: プログラマの思索 【Mercurial】 Mercurialの資料: プログラマの思索 hgbook 日本語版のHTML公開: プログラマの思索 CVS→SVN→Git・Mercurialへ至る歴
UTF-8 対応の msysGit 1.7.10 リリース！ いよいよ Windows で git できるよ!!! - てっく煮ブログ
git先日、msysGit（Git for Windows）がいよいよ公式に UTF-8 をサポート！ という記事で「UTF-8 対応のコードがコミットされた」ことをお伝えしましたが、ついに、UTF-8 対応の新バージョン、msysGit 1.7.10 がリリースされました。いよいよ Windows でも日本語ファイル名を扱えるようになったので、「git では "詳細設計所仕様書.xlsx" をコミットできないんでしょ？」とブーブーいってた人を説得できる材料はそろいました!!!!それを記念して、この記事では UTF-8 対応の msysGit 1.7.10 を試してみた ブーブーいう人を黙らせるための「GUI で git する Windows 向けツール」まとめの2本立てでお送りしたいと思います。UTF-8 対応の msysGit 1.7.10 を試してみたさっそく Google Code
クリアなコードの作り方: 意図が伝わるコミットのしかた - 2012-03-13 - ククログ
コミットメッセージの書き方ではコミットをわかりやすくするためには以下の2つの条件を満たす必要があると書きました。 コミットの内容が分かりやすく説明されていること コミットの内容が小さくまとまっていること このうち「コミットの内容が分かりやすく説明されていること」についてはすでに説明済みです。今回は「コミットの内容が小さくまとまっていること」について説明します。 めざすところ 単純にコミットの内容を小さくするだけではわかりやすくなりません。それでは、どのような基準で小さくすればよいのでしょうか。 よく言われることは1つのコミットには1つの小さな論理的にまとまった変更だけにする、というものです。たしかにこれは重要です。しかし、これだけを基準とすると、人によっては大きめなコミットになってしまいます。人それぞれで論理的なまとまりの大きさが異なるからです。 1つのコミットでどうすればよいかを考えるの
5分で分かるデプロイ自動化への道
12月20日に第1回ワンクリックデプロイ勉強会で、デプロイの自動化について好き勝手に喋ったりデモしたりする予定なのですが、当日話す内容の概略について以下に載せておきます。 以下にあげることをやっておけばデプロイ自動化、ワンクリックデプロイはそんなに遠くないところにあると思います。 ソースコードのバージョン管理いわずもがな。全ての起点はここにあるコードの共同所有の原則への理解このソースコードは本番環境または開発環境などで同じように動作しなければならないテストを書く習慣、コミット前に他のテストも含めて通してからコミットする習慣設定ファイルのバージョン管理環境によって異なる設定値（接続先データベース情報など）が書かれた設定ファイルもバージョン管理する開発環境用、ステージング環境用、本番環境用などに分けて定義し、容易に切り替え可能にする本番環境に配置する際に、アプリケーションの各所を書き換えなけれ
gitをテキトーに使って生産性を向上したユースケース - 西尾泰和のはてなダイアリー
バージョン管理とかgitとかが「おおげさでめんどくさいもの」だと思う人は多い。でも、それは生産性向上のチャンスを逃していると思う。特に業務として多人数で開発している人たちの「変更前にはまずトピックブランチ」というやり方が、それはそれでよい方法なんだけど、いかにもめんどくさそうで尻込みさせてしまうのではないか。 先日の日曜日に、テキトーなgitの使い方をして、とても役に立ったのでユースケースとして報告しておこう。ただし、若干特殊な環境なのでここでやった方法が直接そのまま皆さんの所で使えるとは限らないが。 まず環境の説明。プロジェクトは「次の日曜日、新感覚シューティングゲームを展示します」で紹介している、テーブル型ディスプレイで動くシューティングゲーム。メインは @tokoroten で、ソースコードをバリバリ変更している。土曜日にとりあえず動くところまでは行った。改善点は山積みだ。使える時間
ナウなヤングのためのgithub入門講座 -基本機能からdotfiles管理まで- - tumblr
gitによるバージョン管理 バージョン管理システムはつかってますか？ 僕は前に自分の作成したコードを元に、後輩にプログラムを作らせようとしてまずは僕のコードをコピペしろと指示したところ、コピペしかしてない(と言い張る)割にはコピペしたコードは動かず、さらに何故かコピペ元の僕のコードが滅茶苦茶に荒らされて当然のごとく動かなくなるという、なんかもう幽霊の存在を認めない限り説明がつかないような怪奇現象に遭遇したことがあります。しかもそのときはcpコマンドによるバックアップに頼っていて運悪くバックアップを忘れたために僕の貴重な１日が消え去ってしまった訳でして、それから僕はバージョン管理システムに頼ることを固く心に決めました。また僕はその目を覆いたくなるような残虐な事件以来、建設業界に見習って、IT業界でもプロジェクトキックオフ時にお祓いはすべきだと訴え続けています。 まぁそれはいいとして、いやまだ
継続開発のススメ - Twisted Mind
概要 開発をすればリリースがあり、リリースが終われば開発があります。継続開発をする以上はリリースと開発の繰り返しです。 開発手法やリリース手段は沢山あるのですが、あまりしっくりくるものが無かったので自分でまとめてみました。 これで完璧というものは残念ながらこの世にないと思うので、これからも臨機応変に良い流れを作って行ければと思います。 この文章は以下のような構成になってます。書き殴りですみません。 バージョンの付け方 ソースコード管理とリリース タスク駆動 環境方針 定義 いくつか事前に定義しておかないと話しが訳わからなくなりそうなので。 バージョン管理には git を採用しています。 開発というのはコードを書く事だけを指してはいません。 ここでいうフレームワークは「自身で開発している」として扱います。そうしないとちょっと難しいので。 ライブラリは自身の開発とそれ以外があると思いますので、
もうファイル管理で困らない！ デザイナーのためのSubversion/TortoiseSVN入門
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめに はじめまして、Yahoo!検索のデザイナー担当の竹内美帆と申します。 今Yahoo! JAPANでは、プロジェクト毎にバージョン管理システムを使い分けていますが、Subversionを使用しコードを管理しているプロジェクトもあります。2011年1月～3月には、デザイナーが所属する部署でもデザイナーが作成するHTML・CSS・JavaScriptファイルなどをバージョン管理システムであるSubversion（サブバージョン）で管理しようという動きがありました。 デザイナーにとってはとっつきにくい印象がある「バージョン管理」ですが、うまく利用すれば「あのファイルどこいった？（汗）」「いつこのファイル書きかえたっけ？（汗）」「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Mercurial 対 Git：なぜ Mercurial を選ぶのか？ - Atlassian Japan
Subversion/運用方法 - ピノキヲ IT Wiki
分散リポジトリ型時代のソフトウェア構成管理