GitLab flowから学ぶワークフローの実践 | POSTD
Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys
ソフトウェアエンジニアに働く慣性の法則 - id:anatooのブログ
なんでもいいのだけれども、例えばだけどバージョン管理システムつかって開発してないです、みたいな人がいた時に、傍から見たらすごく良くないことをやっているように見えるけど、当人からすれば今までこれで開発してきたし、別にバージョン管理システムなんか使わなくてもいいよ、みたいなふうな反応をされる。また、こういう反応はその当人だけじゃなくてその人の周りの人も同じ様な反応をする。 もうすこし卑近な例で言うと、コードの質なんかに関しても、汚いコードで書くのが普通で今まで数多くの案件をこなしてきました、みたいな場合だと、綺麗なコードなんて犬に食わせろ的な態度を取って逆に綺麗にコードを書く人をすこし敬遠した態度を取るような人も見られる。そしてそういう人の周りには似たような態度を取る人が多い。そういう考え方みたいなものは、長い間過ごす同じ開発チームのなかで浸透していくからだと思う。 基本的に綺麗なコードを書く
変更前をコメントアウトして残す習慣は未だ根強い (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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
