デバッグ用のコードが残っているとGitでコミットできないようにする - Masteries
PerlでWebサービスやライブラリを開発している際, ｢今, この変数の中には何が入っているんだろう?｣となった時にはよくData::Printerを使っています. Data::Printerは非常に便利なのですが, 先日誤って勢い良くData::Printerを使って変数をダンプするコードを混入したままにcommit/pushをしてしまって, いろいろと大変なことになったので, これを防げるようにしようという気持ちになりました. Data::Printerを使う時は, 大抵Vimのスニペットで｢DDP｣をuseして使うようにしています. なので, Gitでcommitする際に, Perlのコードの中に｢DDP｣という文字列が含まれていれば, commitに失敗するようにすれば良さそうです. ｢commit時に処理を走らせる｣, となればGitのpre-commitのhookを使ってやれ
ポエム/GitとGithubについて(by taea)
元ネタ: 生存戦略の話 · Issue #51 · ppworks/pplog > GitとGitHubについてGitとGitHubについて GitとGitHubのいい所は、コードレビューがはかどるとか色々あるのですが、一番の本質は「意思決定プロセスの民主化」であると思ってます。何かを変えようと思えば変えられる手段が、Gitのお陰でプレイヤー全員が手にすることができた。このことがスゴイ事だなと思ってます。 口頭やドキュメントでのコミュニケーションを介した、わずらわしくて敷居の高い合意形成を経ることなく、各プレイヤーが実際動くコードを書いてプルリクエストという改善提案をできる。 またそれが、色んな人の手や意見が入りいい感じでチームの合意ができたところでマージされる。 commitログを介して、各プレイヤーがコードに含めた意図を主張し、歴史に残すことができる このプロセスによって、デザインはコ
レビューしやすいPRの作り方 - 大きいPRを複数に分割する - - Qiita
こんにちは、freee でエンジニアをしている @nasa4w です。 この記事は freee Engineers Advent Calendar の10日目です。 今回は大きな機能を複数のPRに分割する話をします。 freeeでも絶賛模索中の取り組みなので現在進行形の話ですm(_ _)m まとめ - 今回作ったブランチとPR - 長くなってしまったので結論をさきに置いておきます。PRを複数に分割する場合のゴールはこんな感じ。 Why?（なぜこうしたか） こうすることで、常に work ブランチを使って動作確認ができる レビューする PR を２つに分割できる view の PR と logic の PR レビュー指摘の反映は、topic_view, topic_logic ブランチに commit すればOK work ブランチにはこの2つのブランチを merge しなおすだけでOK PR
Git 作業における commit と push の頻度について - Qiita
注意 この記事は、2014年に投稿されたものです。 時代は変わっても運用におけるベースは大きくは変わっていませんが、投稿としては古い内容ですのでご注意下さい。 未だにストックなど多くいただきますので注意事項として、追記させていだきます。 以下本文です。 はい、今更かもしれませんが。俺としてはGitを扱う上で結構重要だと思っている commitやpushの頻度 について書きたいと思います。はじめに断っておきますが技術的なテクとかの話ではないです。ほとんどが 言われてみれば当たり前じゃん 程度の内容だと思って下さい。 ですが、flowとか運用方法 とか gitを使いこなすちょっとしたテク なんかより重要だと思っているのは俺だけでしょうか...？ どの単位でコミットしたりプッシュしていますか？ みなさん、どのような単位でコミットしたりするようにしていますか？未だに 適当にやってる みたいな人がい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
