これからはGitHubが必須

これからはGitHubが必須ということで、GitHub実践入門を読んでみました。書籍に書いてある内容はわかりやすく、納得しやすいものです。

GitHubというのは、Pull Requestの概念というのが非常に良い、と聞いていて興味はあるのですが、なかなか使いこなせていません。Gitの方は仕事や個人でそこそこに使っていますが、衝突はほとんど発生しない状況が多いので、なんとなく使っているぐらいの感じです。

それで、チーム開発をするにあたってGitが便利なのは賛成なのですが、肝心のチーム開発がそもそも難易度が高いと感じていて、なんというのか、利用する機会というのがなかなかありません。

開発者間のコミュニケーションがそもそも難しくて、世の中で成立している理由というのがよく分かっていません。OSSではGitHubを使った開発というのが流行っているので、優秀な開発者がそこに集まってきているのは確かなのでしょうが、世の中の優秀な開発者の全員がそういった開発を好んでいるというわけではないという点が大きな課題なのでしょう。ここでつまづいてしまうので、なんとかならないかなぁ、と日々感じています。きっとプロジェクトマネージャが各開発者ときちんとした会話ができればいいのでしょうが、それを実現するというのも、大変そうですよね… 何事も結局のところ人だなぁ、とよく思います。

さて、本書ではGitHubフローやGitフローが紹介されています。RedmineやTracを使ったワークフローとはまたちょっと違ったものになります。ここに興味があったので、大変勉強になりました。一度GitHubフローを勉強会などで使ってみたい気がします。仕事で導入するとしたらGitフローなので、そちらも小さなツールの開発とかで一度はやってみたいところです。

課題管理システムの導入により、課題はたくさん出てくるのですが、それを解決する実装チケットの方まで展開できていないことが多く、チケットの内容が混沌とすることも多くありますし、ソフトウェアのバージョン管理というのも微妙な感じになることも多くあります。全体的になんとなく開発は進んでいるので良いのですが、なかには全体的になんとなく進まない開発というのも出てくるわけで、そのあたりをうまくピックアップできてうまく進むようなことができるといいな、と思っていたりします。うまく進まないというのがワークフローに起因するのか、内容によるものなのか、関係者のモチベーションによるものなのか、よくわからないのですが、普通は原因がいろいろあるはずなので、まずはうまく進んでいないということがキャッチできればいいと考えています。

このあたりの機能はGitHubフローやGitフローで解決する話ではないのですが、開発者に負担が少ないワークフローの採用により、開発がうまく進まなかったものが、進むようになるということはありえます。いくつかの原因のうちのひとつに、ワークフローが開発者にとって負担が高いものがある場合に、ワークフローを変更することで改善できるかもしれないので、興味を持っているわけです。

書籍で紹介されているフローはどちらも、Pull Requestが必要なようなので、GitHubの利用が前提となりますが、OSSプロジェクトへ参加するときは、OSSプロジェクトを立ち上げるときにはこういう知識は必要になるので、対応できるようになっておきたいところです。

Gitのプライベートリポジトリを使いたいときは、GitBucketとかGitLabを使うという選択肢もありますが、その場合はGitHubと同じことができるわけではないようなので、また違ったワークフローになりそうです。

いずれにせよ、やりかたはチーム構成員によって変わるので、チームにあった方法がとれればいいのですが、それを見つけるまでが大変だということで、日々精進が必要なのでしょう。

またいろいろと考えてみようっと。

同じタグの記事: Git
同じタグの記事: GitHub
同じカテゴリの記事: Book
関連書籍: Git