GitHubを初めてちゃんと触った人の備忘録とAzure DevOpsとの比較感想(初歩)

# はじめに
GitHubをちゃんと使う機会がありました。
ので、どんなことができたかのまとめ。
普段はAzure DevOpsを使っているので、Azure DevOpsを使ってる人から見た比較感想も。

# 環境
- GitHub Enterprise

# GitHub Projects
Azure DevOpsのBoardsにあたる部分。

1. Projectsを選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/40e02910-3064-629f-e534-aa7aaf8f4098.png)

1. Add projectを選択して、new projectを選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/c6575134-16a0-5c24-7eee-c00ad6019873.png)

1. 続いて表示されるページで「New project」をクリック
1. 作成されるとこんな感じでViewが作成されます
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/e66af1bb-f19e-04ed-50c9-fa282b00802d.png)

Viewタブの横の▽をクリックすると、レイアウトが変えられたりします
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/a56e94cb-5972-0928-e08d-30ed7f4c5b1c.png)

Milestoneを使ってフィルタリングとかしてあげるとAzure DevOpsのようにsprintごとに表示とかができます。


Milestoneの設定方法は次の通り

1. IssuesタブをクリックしてMilestoneをクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/6b3db6f2-f6c0-5d6e-5247-9f5d6b2fb2be.png)

1. New milestoneをクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/0de25427-586d-bb75-53f5-3ab1b67331e7.png)

1. Titleにはsprint名を入れて期限はsprintの終了日を入力
説明にはsprintゴールとかいれるといいんですかね
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/f4df047e-eb9d-f674-78c2-c36cdb195140.png)

1. Create milestoneをクリックで作成できました
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/51d5b302-34fb-83a7-3791-dd149ffa3d88.png)

1. projectに戻ると、Milestoneからsprintの設定ができるようになっています
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/32280452-f9e3-65f0-5bc4-f7f84efadfbf.png)



自分好みにラベルを駆使すればさらにいろいろできそう。

- [GitHub Projects Beta (Table View) を用いたタスク管理](https://zenn.dev/t4t5u0/articles/githubprojectsbeta)

# ブランチルール

SettingsタブのBranchesから変更できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/947bc357-9fdb-4e62-a932-61f80c13a074.png)

よくAzure DevOpsで設定されるであろうものがGitHubだとどれにあたるのか比較してみました。

## マージの承認
どちらもマージ時の必須レビュアー人数を設定しています。この設定では2人です。

Azure DevOps
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/ab307975-9d55-1776-d915-e9bc0b2fa81d.png)

GitHub
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/781e037d-945b-01f3-a09e-f7443f62cffc.png)

## ビルドの検証

マージをする前にビルドが通るかの検証ができます。

Azure DevOps

Build Validationの+ボタンをクリックしてポリシーを追加。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/898356a0-6f96-c556-1007-a6f9879294ca.png)

検証で使用したいpipelineを選択します。ビルドチェック用のpipelineを作成しておく必要があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/90f5cf21-60af-4368-776d-f7ff6113d16d.png)

GitHub

「Require status checks to pass before merging」をクリックすると、マージ前に実行したいpipelineが選べます。
こちらも事前にビルドチェック用のGitHub Actionsを登録しておく必要があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/764ba784-41d3-bed0-b1ff-a0c9c19f56e3.png)

トラブルシューティングドキュメント
[Troubleshooting required status checks](https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks)

## マージタイプの制限
マージタイプを設定できます。設定すると設定したタイプのマージしかできません。どちらもSquashマージを設定しています。

Azure DevOps
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/3a014153-8761-c58a-4f3a-0d23fa5bcebb.png)

GitHub
Settingsの中にあります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201826/b5008925-2298-9ffd-36c3-5a36c0e4c410.png)


# おわりに
基本的にGitHubもAzure DevOpsと同じようなことができるなと感じました。
どっちをやることになっても直感的に触れそうですね。

# 参考(Azure DevOpsとGitHubのブランチポリシードキュメント)
- [Gitブランチのポリシーと設定(Azure DevOps)](https://learn.microsoft.com/ja-jp/azure/devops/repos/git/branch-policies?view=azure-devops&tabs=browser)
- [Managing a branch protection rule(GitHub)](https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)