Work in ProgressパターンによるPull Requestを利用した開発フロー - Qiita
はじめに ソースコード管理ツールとしてGitlabやGithubを導入することで、ソースコードのバージョン管理に加えて、コードの変更前にコードレビューを実施するPull Requestを簡単に行うことができる。コードレビューの観点や手法は様々であるが、レビューを実施する前に幾つかのコンテキストをレビュー担当者とレビュー依頼者が共有しておくことでスムーズなコードレビューが期待される。 本文章ではWork in Progressパターンと呼ばれる手法を利用した、コードレビュー前のコンテキストの共有方法を紹介する。 コンテキストの共有 コードレビューを実施する前に幾つかのコンテキストを共有することは、レビュー担当者の負担削減や、レビューの品質向上またレビュー依頼者のタスクの明確化に繋がる。共有するべきコンテキストの一例として以下の物が挙げられる。 実装する機能の詳細設計 実装する機能の仕様 実装
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
GitHubを利用する際に注意したいOSSライセンスのポイントとは
GitHubに見るOSSライセンスの最新動向 現在、最も利用されているOSSホスティングサイトといえばGitHubです。 つい先日となる、 2013年12月23日のGitHubのblogでは、リポジトリの数が1,000万を超えたとされています。またリンク先のグラフを見るとリポジトリ数の増え方の伸びが著しく、今後も登録数の増加が予想されます。 1,000万という数字はあまりに大きいのですが、他のホスティングサイトと比較してみるとどのくらいの規模なのかが分かります。少し前まで世界最大といわれていたSourceForge.jpは、本稿執筆時点（2014年2月）で約20万プロジェクトです。これを見てもGitHubのプロジェクト数が飛び抜けていることがよく分かります。 これほどメジャーなホスティングサイトとなったGitHubですが、課題もあり、これまで2つの問題が指摘されていました。 1つ目の問題は
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - mixi-inc/JavaScriptTraining: Training course repository for JavaScript
