私たちの残りのためのGitHub

ソフトウェア開発者が不均一に分散した未来の最先端に住んでいるのには理由があります。彼らの作業成果物は常にデジタルアーティファクトであり、ネットワークの黎明期から作業プロセスは接続されてきました。

ソフトウェア開発者が作業できるようにするツールと、それらのツールの使用を取り巻く文化は、主流になりがちです。振り返ってみると、電子メールとインスタントメッセージング(どちらも開発者が他の誰よりも先に使用していた)が大衆に届いたことは明らかです。これらのコミュニケーションモードはすべての人に関係がありました。

Linuxカーネルの開発を調整するために発明されたツールであるGitと、それを取り巻くツールベースの文化であるGitHubが、同様に広く関連していることは明らかではありません。ほとんどの人は生計を立てるためにコードを投げつけません。しかし、すべての職業の作業成果物とプロセスがますますデジタル化されるにつれて、私たちの多くは、共有デジタルアーティファクトに関する作業を調整するために設計されたツールに引き寄せられるでしょう。そのため、GitとGitHubは、コード以外の、またはコードに加えてアーティファクトを生成するワークフローへの道を模索しています。

Wired、ReadWriteなどで報告されているように、GitHubは、レシピ、楽譜、本、フォント、法的文書、レッスンとチュートリアル、およびデータセットの共同開発を管理するために使用されます。Gitの悪名高い複雑さを考えると、これはどのように可能ですか?

その理由の1つは、GitHubがWebインターフェイスで基盤となるGit機能を徐々に公開していることです。もう1つは、GitHubをプラットフォームとして使用するWebアプリケーションの出現です。次に、文化的な要素があります。GitHubは、特定の共同作業方法を具体化しています。デーブ・ワイナーはそれを「あなたの仕事を語る」というフレーズで説明しています。私は「観察可能な仕事」を使用しました。レスポンシブ組織運動は、「プライバシーに対する透明性」を祝います。 GitHubの政府の伝道者であるBenBalterにとって、それは「オープンコラボレーション」です。 

ベン・バルターがその用語を提案しているブログ投稿は、私が読んだときに非公開でした。しかし、ブログは公開GitHubリポジトリでホストされているため、ドラフト形式の投稿を読むだけでなく、招待されたレビュー担当者とのディスカッションをフォローし、そのディスカッションがドラフトにどのように影響したかを観察できました。もちろん、リポジトリは一般に公開されている必要はありませんが、すべての組織は、内部プロセスがこのスタイルのオープンコラボレーションを活用することを望んでいる必要があります。GitHubの戦略担当副社長であるBrianDollによると、まさにそれを実行している企業が増えています。

今日では、すべての会社がソフトウェア会社であるとよく言われます。知的財産をソフトウェアとして定義する場合、それは抽象的な方法で真実です。しかし、社内で開発したソフトウェアに価値が具現化されている多くの企業にも文字通り当てはまります。

コード、テスト、QA、およびドキュメントの従来の分野を超えて、その開発への参加を拡大することが常に望まれていました。しかし、あなたができる貢献がビジネスや顧客の理解に基づいている場合、直接関与することはできません。

「それは非常識です」とブライアンドールは言います。「あなたは、銀行であれば、あなたの従業員や顧客が使用する資産管理ツールがある製品、どのようにそれらの人々はそれを改善するには直接手を持つことはできません?」GitHubを使用すると、すべての利害関係者が一流の参加者になることができます。記録システムを周回する電子メールを作成するのではなく、プルリクエストを送信して、そのシステムで直接関連する問題について話し合うことができます。 

Gitの獣を飼いならす

GitHubの内部にある分散型バージョン管理エンジンであるGitは、プログラマー以外の人だけでなく、集中型システムからやってくるプログラマーも驚かせる方法で機能します。

これらのシステムでは、アーティファクトのセットの代替バージョンを探索するために、リポジトリ内にブランチを作成することは非常に重要です。Gitでは、ブランチは軽量の構造であり、データの代わりにポインターを移動することによって作成された錯覚です。従来のシステムでは、ドキュメント内の1つの単語を変更するためのブランチを作成することは、考えられないほどコストがかかります。Gitは、その操作を簡単に安くします。GitHubは、変更のディスカッションをカプセル化し、ドキュメントの変更履歴に関連付けるワークフロー(プルリクエスト)に埋め込むことができます。

Gitの変幻自在な機能により、Gitはワークフローの革新のための実験室になり、出現した多くのアプローチは、さらに複雑な層を提示しています。分岐とマージの仕組みは十分に注意が必要ですが、分岐とマージをいつどのように行うかについてもさまざまな考え方があります。これはすべてプログラマーにとって挑戦的であり、他のほとんどの人をはるかに超えています。技術者以外の利害関係者が参加できるように、この獣をどのように飼いならすことができますか?

GitHubの回答:コアアクティビティのWebサイトを強化します。法的文書の1つの単語を変更したい弁護士は、恐ろしいGitクライアントを使用する必要はありません。彼女はブラウザでファイルを編集できます。このアクションにより、提案された変更専用のブランチの作成を自動化するプルリクエストワークフローが開始されます。GitHubbersは、「何かを変更する方法は1つしかない」と言いたいです。誰もその黄金のルールに従う必要はありませんが、そうすることは最も抵抗の少ない道をたどります。

その結果、GitHub対応企業の誰もがこのベストプラクティスを簡単に採用できます。「ソフトウェアがひどいので、ウォータークーラーでうめき声を上げる代わりに、それを変更する方法があります」とブライアンドールは言います。そのエンゲージメントは顧客にも及ぶ可能性があります。

GitHub自体の変更は別の問題です。SoftwareCarpentryプロジェクトの創設者であるGregWilson氏は、「そこで採用されるのは簡単です。GitHubが権限を管理する方法を修正したり、ユーザーがリポジトリの複数のフォークを作成できるようにしたりする方法はありません」と述べています。

ただし、GitHubスタイルのインタラクションが有効になっている場合は常に、変更への貢献がコード、ドキュメント、法的アドバイス、ビジネスパースペクティブ、顧客フィードバックのいずれであっても、変更メカニズムは同じように機能します。 

その共有コンベンションの価値は、おそらくGitHubの最も重要なイノベーションであり、ソーシャルメディアからインポートされた他のコンベンションによって強化されています。たとえば、Twitterでは、ユーザー名を指定することで、別のTwitterユーザーの注意を引くことができます。この@メンション手法は、個人およびチームのGitHubで機能します。

GitHubリポジトリの上にWebサイトをホストするサービスであるGitHubPagesもあります。これは、Gitに精通していて、Jekyllと呼ばれるRubyベースのサイトジェネレーターをインストール(およびローカルで使用)する意思のある技術ブロガーに好まれています。しかし、他の人が発見したように、Jekyllをインストールする必要はありません。GitHub Pagesサイトを完全にブラウザーで管理し、バージョン履歴と問題のディスカッションのメリットを享受することができます。