0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Ringoame196

めんどくさがりがmain直pushをやめるために自動化した話

0
Posted at

この記事では、最近自分が行ったGitHub運用の改善（ブランチ運用の自動化やGitHub Actionsの導入）について、自分用のメモも兼ねてまとめます。

軽く自己紹介

普段、KotlinでMinecraftのBukkitプラグインを趣味で開発しているりんご飴196です。

これまでに作ったプラグインの例👇

背景

これまで個人開発が中心だったため、mainブランチに直接pushする運用をしていました。

一人で開発する分には特に問題はありませんでしたが、今後チーム開発をする可能性が出てきたため、このままではチーム開発で困ると感じ、運用を見直すことにしました。

あらかじめチーム開発を想定したブランチ運用に慣れておくため、一人開発の段階から同じ開発フローで進めることにしました。

やったこと

とりあえずブランチを切ってみた(失敗)

タイトル通り、とりあえず git checkout -b develop を実行してブランチを切ってみました。

これでうまく運用できると思っていたのですが、そう簡単にはいきませんでした。

まず、めんどくさがりな自分は、次の日には普通にmainブランチへpushしてしまいました。
その結果、developブランチとmainブランチの内容が混ざり、履歴がぐちゃぐちゃになりました。

さらに一人開発ということもあり、「わざわざPRを作るのが面倒」という気持ちもあり、ブランチ運用自体が続きませんでした。

結果として、ブランチ構成が崩壊してしまい、この方法は失敗に終わりました。

ブランチ作成を自動化(自動化の第一歩)

このような経緯もあり、一度はブランチ運用を諦めていました。

しかし、「毎回ブランチを切るのが面倒なのが問題なのでは？」と考え、ブランチ作成を自動化することにしました。

普段使っているテンプレートの setup タスクに、以下の処理を追加しました。

private fun setupBranch(git: Git) {
        try {
            git.checkout()
                .setName("developer")
                .setCreateBranch(true)
                .call()
            logger.lifecycle("🌱 developer ブランチを作成＆切替")
        } catch (e: RefAlreadyExistsException) {
            git.checkout().setName("developer").call()
            logger.lifecycle("🔁 developer ブランチへ切替")
        }
    }

この処理では、developer ブランチが存在しない場合は新規作成し、すでに存在する場合はそのまま切り替えるようにしています。

これにより、セットアップ時に自動で開発用ブランチへ移動できるようになり、手動でブランチを切る手間がなくなりました。

ただ、ブランチ作成を自動化しただけでは、「わざわざPRを作るのが面倒」という問題は解決されませんでした。

PRのチェックをしてもらう（自動化の第二歩）

PRが面倒なら、「PRを通さないと困る状態にすればいい」と考えました。

そこで、テンプレートに含まれていた shadow プラグインの存在を思い出しました。
このプラグインでは、ビルド時にコードが整っていないと失敗するようになっています。

これを利用して、PR時にビルドチェックを行い、問題があればmainにマージできないようにする仕組みを作ることにしました。

GitHub Actionsに以下の設定を追加しました。

name: Kotlin Lint & Build Check

on:
  pull_request:
    branches:
      - main
      - master

jobs:
  build:
    runs-on: ubuntu-latest

    permissions:
      contents: write
      pull-requests: write

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-java@v4
        with:
          java-version: '22'
          distribution: 'temurin'

      - uses: actions/cache@v4
        with:
          path: |
            ~/.gradle/caches
            ~/.gradle/wrapper
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
          restore-keys: |
            ${{ runner.os }}-gradle

      - name: Lint & Build
        run: |
          ./gradlew lintKotlin
          ./gradlew build

この設定により、PR作成時に自動でLintとビルドが実行され、問題がなければそのままマージされるようになります。

結果として、「PRを出さないとmainに反映されない」状態になり、自然とPRベースの運用ができるようになりました。

正直これでも十分でしたが、一つだけ小さな不満がありました。
それは、Lintとビルドが通った後に手動でマージをしなければならない点です。

ここまで自動化したなら、すべて自動化したい。
そう考え、最後にマージの自動化も行いました。

マージの自動化（最後の自動化）

PRのGitHub Actionsに以下の処理を追加しました。

- name: Auto Merge
  if: success() && github.event.pull_request.head.repo.full_name == github.repository
  run: |
    curl -L \
      -X PUT \
      -H "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" \
      -H "Accept: application/vnd.github+json" \
      https://api.github.com/repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/merge \
      -d '{"merge_method": "merge"}'

これにより、PR作成 → Lint・ビルドチェック → 問題なければ自動マージ、という一連の流れがすべて自動化されました。

結果として、「pushするだけでmainブランチが常にきれいに保たれる」状態を作ることができました。

まとめ

  • ブランチ運用が面倒で続かなかった
  • → ブランチ作成を自動化
  • → PRに意味を持たせるためにチェックを導入
  • → 最終的にマージまで自動化

めんどくささを減らすことで、ブランチ運用を無理なく続けられるようになりました。

やっていること自体は、よくある運用だと思います。

ただ、自分の中では「めんどくさい」をちゃんと潰して仕組みにできたのは大きな変化でした。

結果として、無理なくブランチ運用を続けられるようになり、開発の流れもかなり楽になりました。

同じように「ブランチ運用が続かない」と感じている人の参考になれば嬉しいです。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?