I'll leave the implementation of this until the Schema has been accepted

All of the ForceNew: true, will be removed once Update is implemented, see previous comment

I could see an argument for having fields for both default_branch and all_branches_and_tags as boolean values to get around users needing to learn that they are referenced as ~DEFAULT_BRANCH and ~ALL.

Changing this would be trivial if anyone strongly feels they should be their own fields (updating this after this PR is merged wouldn't be difficult either, if the functionality is wanted down the line)

Maybe go-github needs a version bump for this one? It's a weird one though, because both the API docs and go-github expects update_allows_fetch_and_merge, but when I ping the API, I get back a response looking like this (where the update field is the most important, the rest is just there for context):

"rules": [
  {
    "type": "deletion"
  },
  {
    "type": "non_fast_forward"
  },
  {
    "type": "required_status_checks",
    "parameters": {
      "required_status_checks": [
        {
          "context": "SonarQube Code Analysis",
          "integration_id": 95502
        }
      ],
      "strict_required_status_checks_policy": true
    }
  },
  {
    "type": "pull_request",
    "parameters": {
      "require_code_owner_review": true,
      "require_last_push_approval": true,
      "dismiss_stale_reviews_on_push": true,
      "required_approving_review_count": 3,
      "required_review_thread_resolution": true
    }
  },
  {
    "type": "required_signatures"
  },
  {
    "type": "required_deployments",
    "parameters": {
      "required_deployment_environments": [
        "terraform"
      ]
    }
  },
  {
    "type": "required_linear_history"
  },
  {
    "type": "update"
  },
  {
    "type": "creation"
  }
],

I don't know why this is, or if I'm missing something. I'll look into this more later, after a bumo of go-github has been made.

Relevant discussion thread here: google/go-github#2836

When I started implementing this, I played around with a nested rules field, which wrapped all the rule_* fields you can see below here. It proved to require a bunch of boilerplate code when implementing the actual Create/Read/Destroy logic, so I instead opted into moving them to the root, and instead using a rule_* naming convention for them.

The rule_* addition might be overkill (and requires a little bit of parsing logic in the actual implementation), but since the schema is quite large, I think it's worth having it just to make it clear that these are the rules (a creation field doesn't really mean much, rule_creation is clearer IMO) .

I'm open for feedback here though. Baking all of them into a nested structure is possible, just somewhat tedious.

As mentioned in the PR description, this one is broken currently. go-github needs a release bump. As opposed to the rule_update field, I'm confident will be solved by this bump 😓

It shouldn't be that hard to build on this to also implement Org level Rules. Leaving this until the schema has been finalized and go-github has been bumped

Or another PR, idk what makes sense. We'll see

I have seen both fmt.Errorf() and errors.New being used to throw errors across this project. What is the recommended way?