GitHubライブラリを開発してオープンソースにして、npmやCocoaPodsといった場所へパッケージとして公開することはよくあることだと思います。それを業務とかチームで使うこともよくあります。いった事をしてた時に、後から権限を付与しようとしたりリポジトリの管理で問題が出てくることがあったので、それについてのメモです。この記事は、既に個人のアカウントで公開していたライブラリを後からどうやって権限の移譲や分配をしていくかという趣旨の内容です。最初からチーム用のアカウントでやるのが正解な気がするので、そういうのとはちょっと違う方向かもしれません。概要3行で個人でオープンソースのライブラリ公開してた後になってチームで更新出来るようにしたくなったそもそもライブラリとリポジトリで権限が別で何か面倒だねCocoaPodsの例SwiftとObjective-Cのパッケージ管理ツールであるCocoaPodsを例にしてみます。CocoaPodsはRubyGemsやnpmと同じように、パッケージをpublishして公開する形なので、CocoaPodsを公開する用のアカウントがリポジトリとは別に必要です。パッケージはパッケージで権限を付与する必要があります。ArsScaleもしくはCocoaPods.orgで検索するなど。一覧が確認できたら、公開の権限を付与したい人のCocoaPodsアカウントへ権限を与える。add-ownerで権限を付与する。"付与するメールアドレス"という感じでまとめて付与できる。コマンドの詳細は以下に書かれています。Trunknpmとかでもパッケージ毎に管理出来るユーザ(npmアカウント)を追加できるので同じですね。DocumentationGitHubリポジトリの移譲GitHubでリポジトリを公開してる場合に、そのリポジトリもチームで共有しやすい形にしたいと思います。GitHubの場合は方法がいくつかあると思います。リポジトリのcollaboratorsに加える現状維持的なアプローチCollaborators権限でコミットも可能OrganizationをCollaboratorsに追加はできない(=>移譲するしかない)Collaboratorsがたくさんいる場合は組織アカウントへ移譲した方がいいOrganizationアカウントを作ってそこへリポジトリを移譲するGitHubがリダイレクトしてくれるので最低限はそのまま維持されるURLが変わるので関連サービスなどが追従できない可能性はあるけど、リダイレクトされるので大抵は動くREADMEやpackage.jsonやpodspecのような関連ファイルを順次書き換えていく必要がある引き継ぐ人がforkして管理する積極的なメリットはないリポジトリが分散する問題リポジトリを移譲していくのが今後としてはいい気がしますが色々書き換えが面倒だったり、APIがないので自動化しにくかったりするので、必要に応じてやっていくのがいい気がします。今回は既に個人で公開していたものをチームで共有して更新しやすくするようにするという感じでしたが、やっぱりパッケージとリポジトリの権限が別だったり、リポジトリも移譲が面倒だったりします。この辺は普通のオープンソースプロジェクトでも良く問題になる気がするので、リポジトリとパッケージ管理の権限が別れてる問題は何かいい方法があるといいなーという感じがします。タグ:オープンソースGitHubObjective-CcocoapodsnpmiOSお知らせ欄JavaScriptに関する最新情報は週一でJSer.infoを更新しています。efcl/efcl.github.ioからご意見下さい関連記事コメントを。