【初心者向け】「コミットの粒度がわからない問題」の模範解答を考えてみた - Qiita
はじめに 先日参加したRails Developers Meetupの中で、「コミットの粒度がわからない問題」が少し話題になっていました。 「commitの粒度がわからない」すいません、私もです…！よく迷っちゃいます…！！！ #railsdm — まえとー (@maetoo11) July 20, 2017 commitの粒度がわからない問題、ある。（ほんとわからない） #railsdm — おおた (@ota42y) July 20, 2017 普段僕は感覚的に「それっ、ここでコミット！」とコミットしているんですが、具体的にどういうルールでやってるの？と聞かれると、きれいに明文化しづらいものです。 とはいえ、できるだけ明文化できるよう、模範解答を考えてみました。 この記事ではそんな「適切なコミット粒度」について解説します。 動画で明文化・・・！？ すいません、「明文化した模範解答」という
OSSにコミットし始めて、とてもいい感じのSpeeeさんに取材してきました!! 前編 - Happy Hiring !!
取材にあたって 取材の狙い エンジニア採用で使う19の募集チャネルの中の一つ、OSSをテーマに、いまOSSへの取り組みがとても話題になっているSpeeeさんに取材をお願いすると、よいですよー、という快いお返事! 早速、行ってきました! (繋いでいただいた須藤さん、ありがとうございます!!!) 取材の狙い:募集チャネル:自社OSSの公開 の施策を取材したい 取材に応じて頂いたお二方 デジタルコンサルティング事業本部 ネイティブアド事業 UZOU エンジニア 畑中 悠作さん (id:hatappi さん) エンジニア組織推進室 中野 賀奈さん (インタビュアー:広瀬) 最初は “Ruby、OSSやるぞ” に戸惑う社内 ーー今日は社内表彰式前の忙しい時間にありがとうございます!!! 今日はよろしくお願いします 畑中 よろしくお願いします 中野 よろしくお願いします！ ーーでは、早速、開発者個人が
人間らしくコードレビューするには(パート1) | Yakst
自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithubの
Macで使えるGitフロントエンド - たけぞう瀕死ブログ
元々IDEとか開発ツールは専門分野（？）なので、この手のものは以前からいろいろ試しているのですが、個人の感想をまとめておきたいと思います。IDEやエディタに統合されていて利用シーンが限定されるものや、GitHub for Windowsなどのように機能に制限の多いものは省いています。 SourceTree 信頼と実績のAtlassian製 無料で使用可能（要ユーザ登録） 日本語対応しており、書籍などの情報もある リポジトリごとにウィンドウが開く（Windows版はタブで開くのに…） 対話型リベースが可能 動作がかなり重い、特にブランチが増えると実用に耐えないレベルで重くなる ただし突然死などはしない Tower2 有料（買い切り$79） 履歴一覧でブランチの関連を把握するのが難しい気がする 1ウィンドウで複数リポジトリを切り替えて使用 動作はかなり軽い 時々突然死することがある ブランチを
1人で始めた職場での改善活動1年間を振り返ってみたメモ - 全力で怠けたい
職場で勝手にやっている改善活動のメモを取り出してから1年たったので振り返ってみたメモ。 書くこと 実際にやったこと 変わったこと 一番大きく変わったこと まとめ 実際にやったこと メモはハッシュタグ #俺俺改善活動 を付けて Twitter へツイートしていました。*1 今月の #俺俺改善活動．構成管理のブランチポリシーを整理してドキュメント化した．普段は見ないものだけど，ブランチ開発経験のない人が入ってきたときは効果すごいある— えび🦐 (@ebc_2in2crc) 2016年7月28日 今月の #俺俺改善活動．高コストな上に誤りが混入しやすい機能をエンドツーエンドでテストできるようにした．テストは自動化されているから CI に組み込めるし，安心して修正できるようになった(*'▽'*)— えび🦐 (@ebc_2in2crc) 2016年7月28日 今月の #俺俺改善活動 ・テストの2
コミットサブジェクト（題目）とメッセージ部分を分けるには - Qiita
本題 https://medium.com/@risacan/コミットメッセージの書き方-64aeadd92057 の[2行目に空行を設ける]の節をみて、意外と知らない人多いのかなぁ、と思ったので。 上のリンクでは、git commit打ってから、コミットログの編集画面に移行して、コミットメッセージをコミットサブジェクト（題目）とメッセージ部分に分けて書いているが、その時、2行目を空白にする必要があるという旨がかかれている。 これは、実はgit commitのmオプションを2つ重ねれば同じことができる。 つまり、git commit -m "short msg" -m "long description"を使えばよい。 どのように表示されるかは、上のリンクと参考を参照してください: 参考) https://saraford.net/2017/01/07/how-to-commit-an-o
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
