コード共有・バージョン管理サービス比較｜GitHub・GitLab・Bitbucket

コードをZIPで送った後、次の担当者が不具合を直せない。履歴と権限が制作者個人に残っていたためだ。GitHub、GitLab、Bitbucketの差は画面の好みだけではなく、レビュー・CI・組織所有の設計に表れる。ここでは納品後の保守まで含めた選び方を整理する。

GitHub｜Issueとレビューを納品履歴にする

GitHubはリポジトリにIssue、Pull Request、Projectsを関連付けて変更をたどれる。Freeプランにも非公開リポジトリがあるため、案件の初期管理に使いやすい。ただし企業側の組織所有へ切り替える時点を契約書に明記しておかないと、個人所有のまま運用が続きやすい。 公開や納品の環境を整えるなら、レンタルサーバー エックスサーバーのようなレンタルサーバーも候補になります。

GitLab｜CI/CDと開発管理をまとめる

GitLabはコード管理に加え、Merge RequestやCI/CDの開発工程をまとめて扱える。テストを実行する仕組みを一体で設計したい案件には有力だが、各プランの実行枠とストレージは公式の上限を照らして算定する。

Bitbucket｜Jira利用企業への親和性

BitbucketはAtlassianのJiraとの連携を前提とするチームで特に候補になる。課題番号とコミット、レビューを結ぶ運用は、開発依頼が頻繁に入る受託案件で役立つ。顧客がJiraを使っていないなら連携の利点だけで決めない。

ソースを渡すだけでは、保守は始まりません。履歴とREADMEがあって初めて、別の担当者が続きを触れます。

顧客にソースを渡すだけでは保守できない

納品するリポジトリにはソース本体だけでなく、環境構築手順、必要なシークレットの管理方法、テスト実行コマンドも必要になる。クローンした担当者がREADMEだけで開発環境を作れるか試す。秘密鍵をGitの履歴へ誤って含めていないかを確認する作業は、見積の検収工程に入れておきたい。

開発用のサンプルデータを置くとき、顧客の本番データをコピーして配布しない。個人情報を除いた架空データで動作確認できる仕組みを作ることも、コードを他の保守担当へ渡すための品質条件になる。

新しい開発者が参加する場面を想定し、ゼロから環境を用意させてみる。リポジトリのクローンはできても、環境変数の意味が分からない、テスト用データがない、デプロイ先の接続権限がないという理由で作業が止まることがある。この失敗はコードの品質問題とは別の引継ぎ不備だ。環境構築時間も記録し、受託開発の納品項目に再現性を含める。

個人アカウントに納品物を残すリスク

個人所有のリポジトリから顧客の組織へ権限を移す際は、単なる招待と所有権の移転を区別する。保守会社が交代しても管理者が追加・削除できる仕組みを顧客側で保持するのが基本だ。請求方法や有料機能の利用主体もコードの引渡しより前に合意しておく。

権限の移転前に、組織の二要素認証と請求権限を整える。管理者が一人だけだと退職や休職の際に対応できないため、顧客内での引継ぎ方針と緊急時の復旧経路を文書にして残しておきたい。 帳簿づくりまで見据えるなら、マネーフォワード クラウド確定申告のようなクラウド確定申告も役立ちます。

レビューの単位は、納品物でそろえること。変更の理由が履歴に残ると、後からの確認が速くなります。

Pull RequestとMerge Requestの使い分け

GitHubやBitbucketで用いられるPull Request、GitLabのMerge Requestは、変更の差分をレビューしてから統合する実務を支える。名称が違っても要点は「誰が、どのテストを見て、何を承認したか」。本番ブランチへの直接書込みを制限し、重要修正にはレビュー記録を残す。

レビューで自動テストが成功していても、仕様が正しいと判定できるわけではない。動作が変わる箇所には発注者の承認を紐づけ、変更の意図と再現した結果を別の欄へ記録すると後日の調査が容易になる。

レビューを省略する緊急修正が必要になった場合は、その例外を履歴から追えるようにする。どの障害に対応するために統合し、誰が事後確認を行うのかを残せば、通常時の承認ルールも形骸化しにくい。GitHub Actions、GitLab CI/CD、Bitbucket Pipelinesのようにサービスごとに仕組みが異なるため、既存の自動テスト資産を移す費用も評価対象になる。

CI実行時間と保存容量の上限

テストを自動化できても、CIの実行分数や成果物の保存容量が無限という意味ではない。画像処理を含む重いパイプラインでは、利用量と課金主体を把握しておく。自動実行に失敗したときの通知先を個人メールだけにしないことで、保守の停止を防ぎやすくなる。

パイプラインの実行環境を外部サービスへ移す際は、課金条件と秘密情報の管理先を区別する。実行時間の上限に達したときの停止影響も、開発中の遅延か本番サービスへの影響かで優先度が変わる。

権限は、契約終了と同時に外すのが原則です。個人アカウントに納品物を残すと、保守もセキュリティも崩れます。

退職者や外注先の権限剥奪

外注先が開発を終えても、組織への招待やデプロイ用トークンが残れば事故につながる。契約終了日に消す対象を、アカウント権限、SSHキー、アクセストークン、CI変数に分けて棚卸しする。取り消し後のデプロイを誰が試すのかまで決めて、終了処理を完了させたい。

外注先が保守から離れた後も、Webhookやデプロイキーを通じて更新できる状態が残る場合がある。ユーザーの一覧だけで完了とせず、連携サービス側の認証を含めた取消を一括点検する。

顧客の組織で管理するなら、保守会社が変わる際に旧担当者の個人トークンを使い続ける状態を解消しておきたい。外部サービスとの連携で使う認証情報は新管理者へ引き継ぎ、秘密情報そのものをチャットへ貼らない。退職者の権限を外しても本番の更新が動くことを確認し、そのログを検収記録にする。

納品物としての履歴とREADME

履歴があってもコミットメッセージが「修正」だけでは、後任者が変更理由を追えない。大きな仕様変更はIssueとレビューを関連付け、公開版にはタグやリリースノートを付ける。READMEへ保守窓口と更新手順を記せば、担当交代後も調査に費やす時間を抑えやすい。

READMEを納品するときは、技術者向けの構築手順と顧客向けの問い合わせ先を分ける。ソースの管理場所を伝えるだけでなく、更新の依頼窓口を明らかにすると保守契約の範囲も整理できる。 体系立てて学びたい場合は、Webスキルを学ぶオンラインスクール デイトラのようなオンラインスクールも選択肢になります。

判断に使う比較表

現場で試すための補足

顧客が保守会社を変更するとき、組織の管理者が新しい担当者へアクセスを付与できるかは、引渡し品質の試金石になる。差分レビューの記録が残れば不具合原因の追跡にも使える。リポジトリの所有と保守対応を分けて見積もることで、コーディング以外の価値を料金に反映しやすい。

小さなECサイトの改修を外注したとする。制作側は個人のGitHubアカウントで作業し、顧客は完成した画面だけを検収した。ところが翌月、決済画面の不具合が起き、別の開発者がコードを見られない。変更履歴を引き渡す合意がなかったことが原因なら、リポジトリの機能比較だけで問題は解決しない。案件開始時点で顧客組織に作業場所を用意し、外注担当者を招待する形を検討する。

GitLabのCI/CDを使う場合には、テストを実行する条件を明示したい。すべての変更を本番へ反映するのではなく、レビューを終えたブランチだけをデプロイ対象にする。Bitbucketを選ぶなら、Jiraに登録された課題とレビューを結ぶ運用が顧客の既存体制に合うかを考える。どのサービスでも、秘密情報をリポジトリに直接保存しない運用が欠かせない。

作業の最終日には、顧客が自分の権限でコードを取得し、必要な環境を再現できるか試す。これが可能なら制作者が変わった後も案件を継続しやすい。アクセス権の棚卸しやドキュメント整備を契約へ含めることは、受託単価を値下げせずに説明できる専門的な価値になる。

見積の段階で開発リポジトリの作成者を誰にするか決める。顧客側の組織で管理するなら、制作者は必要な期間だけ権限を与えられる形にできる。Issueの一覧、レビューが必要な変更、テストを自動化する範囲を予め決めれば、利用料だけでなく運用の手間を比較できる。保守引継ぎ用のREADMEに重要な環境情報を記し、パスワードなど秘密情報を直接書かないことも徹底したい。

出典

– GitHub 公式情報– GitLab 公式情報– Bitbucket 公式情報

CTA

仕事の取り方や単価の決め方で迷ったら、HYPEへご相談ください。→ お問い合わせはこちら※本記事にはプロモーションを含みます。

合わせて読みたい

– 仕様変更の履歴の残し方｜決まったことと変わったこと– 納品物のファイル管理の型｜名前と場所の決め方