抽象化によるブランチ - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/BranchByAbstraction.html 「抽象化によるブランチ」というテクニック1は、ソフトウェアシステムへの大規模な変更を徐々に進めていくときに使われるものだ。 これを使えば、変更がまだ完了していなくても、定期的にシステムをリリースできるようになる。 こんな状況を考えてみよう。システムのかなりの部分が依存しているモジュール（あるいはライブラリやフレームワーク）があって、それをリプレイスしようとしている。 ※Flawed Supplier…欠陥のあるモジュール 抽象化レイヤーを作って、クライアントのコードとモジュールとのやりとりをそこに閉じ込める。 クライアントのコードの中でモジュールを呼び出しているところをすべて書き換えて、この抽象化レイヤーを経由させる。 各クライアントについて、この抽象化レイヤーを使うよう徐々に書き
Trunk Based Development
One line summary A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’ *, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after. * main for the Git community since 2020 (master with unsavory connotations before) Sh
最強のGitフロントエンドはForkかもしれない - たけぞう瀕死ブログ
昨日Macで使えるGitフロントエンドの紹介を書いたところ、友人のPishenさんからForkというツールもあることを教えていただきました。 How about https://t.co/fDZq7jzQoo ?— Pishen Tsai (@pishen) 2017年8月30日 Webサイトはこちら。現時点ではMac版（動作にはMacOS X 10.11以降が必要）のみですが、Windows版も提供予定のようです。 git-fork.com リリースノートを見ると昨年から開発されていたようですが、完全にノーマークだったので早速試してみました。 1ウィンドウで複数リポジトリをタブ切り替えで操作できる ブランチの状況も把握しやすい履歴ビュー（見た目的にはSourceTreeに近い） コミット時点のファイルツリーを確認できる 動作は軽快（ただし安定度についてはまだ不明） ターミナルから起動する
まだエンジニアに文言修正なんか頼んでるの？ - クラウドワークス エンジニアブログ
プロダクト開発の中になぜか置いてもらっている非技術職の小林（週末は主夫、たまに会社でプロダクトオーナー）です。 日々、エンジニア OR デザイナー OR コピーライター に囲まれながら、プロダクトの成長を見守ってまっす。 ところで、プロダクトが成長していく過程で、新サービス・新機能のリリースに伴い LPや各種画面のちょっとした修正が増えていったりしませんか？ 事業戦略上で重要な機能・サービスを開発をしているチームに、飛び込みでキャンペーンLPのテキストの修正依頼が・・・。 仲間としては施策担当者がなんとかしたいと思う気持ちもわかる、でも、エンハンスに集中していて細かい修正をする時間が取りづらい。 そんな時に、同じチームメンバーとして非エンジニアでも手伝えることがあるかもしれません。 クラウドワークスでは、簡単な修正であれば施策担当者（非エンジニア）が行ってしまうこともあります。 我々と同様
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『脱ブランチファースト - 日々常々』へのコメント
Commit message will never die