タグ

GitHubに関するmtmt101jpのブックマーク (6)

  • Zube | Agile project management with a seamless GitHub integration

    Agile project management with a beautiful and blazing fast interface. The kanban board provides an Agile workflow out of the box. Get a clear overview of your project, or take a closer look with advanced filtering. The source of truth. Never copy and paste another developer task. Seamlessly work between Zube and GitHub Issues. Attach one or multiple GitHub repositories to your Zube project and you

    Zube | Agile project management with a seamless GitHub integration
    mtmt101jp
    mtmt101jp 2015/10/07
    Free while in beta!
  • GitHub FlowでPull Requestベースな開発フローの進め方 - Qiita

    弊社、日CAWでの開発フローはGitHub Flowをベースにしてpull requestを活用したスタイルを採用しています。 最近、有志のチームでサクっと行きたいラーメン屋さんを見つけることができるアプリ「めんこれ」というのを開発しているのですが、そろそろ開発フローを整備しようという話になったので、今まではクローズドでやってましたが、公開しちゃおうと思ったわけです。 普段はdevelopブランチをメインブランチにしているんですが、スピード感あるデプロイサイクルにするためにmasterブランチをメインにします。 実装者のフロー GitHub Flowについてはこちらの日語訳を参照のこと。 https://gist.github.com/Gab-km/3705015 GitHubのissueで開発タスクを管理していますので、開発対象のリポジトリで自分にAssignされているタスクを確認し

    GitHub FlowでPull Requestベースな開発フローの進め方 - Qiita
    mtmt101jp
    mtmt101jp 2015/06/26
    いまはほぼこの流れではあるんだけど、ちょっと曖昧な部分もあるから明文化することで少しでも確度を高めたい
  • 開発フロー研修 @ Wantedly - Qiita

    Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、

    開発フロー研修 @ Wantedly - Qiita
    mtmt101jp
    mtmt101jp 2015/04/10
    すばらしい
  • より良いプルリクエストのための10のヒント | Yakst

    GitHubなどの普及により、プルリクエストを使った開発フローは非常に一般的になった。一方でプルリクエストの品質も色々だ。オープンソースプロジェクトや業務でたくさんのプルリクエストをレビューするMark Seemann氏から、良いプルリクエストを作り、スムーズにマージしてもらうための10のヒント。 原文 10 tips for better Pull Requests by Mark Seemann 良いプルリクエストを作ることには、良いコードを書くこと以上を含んでいる。 プルリクエストモデルは、チームでソフトウェアを開発するための素晴らしい方法になりつつある。チームメンバーが分散している場合は特にそうで、オープンソースの開発だけでなく、企業においてもそれは同じことだ。2010年頃から私は、オープンソースプロジェクトにおいてだけでなく、クローズドソースのソフトウェア開発のために内部的にプル

    より良いプルリクエストのための10のヒント | Yakst
    mtmt101jp
    mtmt101jp 2015/01/19
    無意識にできるようになりたい
  • GitHubに会社の就業規則を公開した - terurouメモ

    これです。 ちゃんと社労士チェックを入れて、2014年時点の法運用Validな感じにしてあるので、下手な中小企業はおろか、ろくにメンテされていない大企業の就業規則よりマトモな内容になっているはずです。 なんで就業規則を公開したのか マトモな規則が作ってあれば公開しても特にデメリットはない むしろマトモな会社アピールができてよい 個人的には「無限RedBullです!!!!」みたいな事をアピールする会社よりマトモな広報・求人活動の一環だと思っている 自分で就業規則を作ろうにも、良いサンプルがなかった(後述あり) いわゆるOSS的な話。就業規則にも再利用性が合っても良いはず これを書いてて、就業規則にライセンスを明示するのを忘れていたことに気が付いた GitHubだと、就業規則の改定にプルリクを飛ばせて楽しいし、改定履歴も一目瞭然 零細企業に就業規則って要らないんじゃないの? 従業員が10人未満

    GitHubに会社の就業規則を公開した - terurouメモ
    mtmt101jp
    mtmt101jp 2014/09/11
    就業規則、ともすれば従業員に見せたくないみたいな姿勢の企業もある中で、この試みは素晴らしい。Github のもたらした(またはこれからもたらすであろう)利益の大きさよ
  • 1