如何提出 PR (Push Request)
===
###### tags: `git`, `gitlab`, `git-lab`, `github`, `git-hub`, `git-submodules`, `git lfs`, `git stash`, `git push`, `github issue`

<br>

[TOC]

<br>

## 流程

# 1. 安裝 gh CLI 指令
sudo apt  install gh  # version 2.45.0-1ubuntu0.3

# 2. 在當前 device 登錄 GitHub.com
gh auth login

# 3. Fork 專案 (需要 gh CLI)
gh repo fork SlinkyProject/slurm-exporter --clone=false
git clone [e-mail]:tsungjung411/slurm-exporter.git
cd slurm-exporter

# 4. 新增您的 fork 作為 remote
git remote add myfork [e-mail]:tsungjung411/slurm-exporter.git
git remote show

# 5. 建立並切換到新分支 (如果還沒做)
git checkout -b feature/servicemonitor-custom-labels
git branch -a

# 6. 提交變更 (如果還沒做)
git add helm/slurm-exporter/values.yaml helm/slurm-exporter/templates/metrics/service-monitor.yaml
git commit -m "feat: add custom labels support to ServiceMonitor

- Added exporter.serviceMonitor.labels configuration option
- Updated service-monitor.yaml template to merge custom labels
- Added documentation and reference links

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <[e-mail]>"


# 7. 推送到您的 fork
git push -u myfork feature/servicemonitor-custom-labels

# 8. 建立 PR 到上游專案
gh pr create --repo SlinkyProject/slurm-exporter --title "feat: Add custom labels support to ServiceMonitor" --body "$(cat <<'EOF'
## Summary

This PR adds support for custom labels on the ServiceMonitor resource, enabling Prometheus to discover the ServiceMonitor using label selectors.

## Changes

- Added `exporter.serviceMonitor.labels` configuration option in `values.yaml`
- Updated `service-monitor.yaml` template to merge custom labels with existing labels
- Added comprehensive documentation and reference links

## Motivation

When using Prometheus Operator, Prometheus instances typically use label selectors (e.g., `serviceMonitorSelector`) to discover which ServiceMonitors to scrape. Without the ability to add custom labels to the ServiceMonitor resource, users cannot configure their Prometheus instances to discover this exporter.

## Usage Example

Users can now configure custom labels in their `values.yaml`:

``yaml
exporter:
  serviceMonitor:
    enabled: true
    labels:
      prometheus: kube-prometheus
      release: prometheus-operator
``

This allows Prometheus with matching selectors to discover and scrape the slurm-exporter metrics.

## Testing

- [ ] Verified Helm template rendering with custom labels
- [ ] Confirmed labels are properly merged with existing labels
- [ ] Tested with Prometheus Operator in Kubernetes cluster

## References

- [Prometheus Operator ServiceMonitor Documentation](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/design.md#servicemonitor)

🤖 Generated with [Claude Code](https://claude.ai/code)
EOF
)"

- ### 執行範例

    $ sudo apt  install gh  # version 2.45.0-1ubuntu0.3


    $ gh repo fork SlinkyProject/slurm-exporter --clone=false
    To get started with GitHub CLI, please run:  gh auth login
    Alternatively, populate the GH_TOKEN environment variable with a GitHub API authentication token.


    $ gh auth login
    ? What account do you want to log into? GitHub.com
    ? What is your preferred protocol for Git operations on this host? SSH
    ? Upload your SSH public key to your GitHub account? /home/tj/.ssh/id_ed25519.pub
    ? Title for your SSH key: GitHub CLI
    ? How would you like to authenticate GitHub CLI? Login with a web browser

    ! First copy your one-time code: XXXX-XXXX
    Press Enter to open github.com in your browser... 
    Opening in existing browser session.
    
    > 1. Enter the code displayed in the app or on the device you're signing in to. Never use a code sent by someone else.
    > 2. Enter: XXXX-XXXX
    > 3. Click "Authorize github"
    > 4. Confirm access: OOO OOO  (2FA)
    > 5. Congratulations, you're all set!

    ✓ Authentication complete.
    - gh config set -h github.com git_protocol ssh
    ✓ Configured git protocol
    ✓ SSH key already existed on your GitHub account: /home/tj/.ssh/id_ed25519.pub
    ✓ Logged in as tsungjung411


    $ gh repo fork SlinkyProject/slurm-exporter --clone=false
    ✓ Created fork tsungjung411/slurm-exporter

    # ??
    $ git clone https://github.com/tsungjung411/slurm-exporter

    $ cd slurm-exporter
    slurm-exporter$ git remote add myfork [e-mail]:tsungjung411/slurm-exporter.git


    $ git checkout -b feature/servicemonitor-custom-labels
    Switched to a new branch 'feature/servicemonitor-custom-labels'


    # modify code
    # test code


    $ git status
    On branch feature/servicemonitor-custom-labels
    nothing to commit, working tree clean
    
    $ git status
    On branch feature/servicemonitor-custom-labels
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git restore <file>..." to discard changes in working directory)
        modified:   helm/slurm-exporter/templates/metrics/service-monitor.yaml
        modified:   helm/slurm-exporter/values.yaml


    $ git diff


    $ git add helm/slurm-exporter/values.yaml helm/slurm-exporter/templates/metrics/service-monitor.yaml


    $ git status
    On branch feature/servicemonitor-custom-labels
    Changes to be committed:
      (use "git restore --staged <file>..." to unstage)
        modified:   helm/slurm-exporter/templates/metrics/service-monitor.yaml
        modified:   helm/slurm-exporter/values.yaml

    $ git commit -m "feat: add custom labels support to ServiceMonitor

    - Added exporter.serviceMonitor.labels configuration option
    - Updated service-monitor.yaml template to merge custom labels
    - Added documentation and reference links

    🤖 Generated with [Claude Code](https://claude.ai/code)

    Co-Authored-By: Claude <[e-mail]>"
    [feature/servicemonitor-custom-labels e3971d1] feat: add custom labels support to ServiceMonitor
     2 files changed, 10 insertions(+)


    $ git push -u myfork feature/servicemonitor-custom-labels
    Enumerating objects: 15, done.
    Counting objects: 100% (15/15), done.
    Delta compression using up to 4 threads
    Compressing objects: 100% (7/7), done.
    Writing objects: 100% (8/8), 1.10 KiB | 1.10 MiB/s, done.
    Total 8 (delta 6), reused 0 (delta 0), pack-reused 0
    remote: Resolving deltas: 100% (6/6), completed with 6 local objects.
    remote: 
    remote: Create a pull request for 'feature/servicemonitor-custom-labels' on GitHub by visiting:
    remote:      https://github.com/tsungjung411/slurm-exporter/pull/new/feature/servicemonitor-custom-labels
    remote: 
    To github.com:tsungjung411/slurm-exporter.git
     * [new branch]      feature/servicemonitor-custom-labels -> feature/servicemonitor-custom-labels
    branch 'feature/servicemonitor-custom-labels' set up to track 'myfork/feature/servicemonitor-custom-labels'.

- [**建議**] 直接在 web 上建立 pull request，好處可以 review markdown 結果
> https://github.com/tsungjung411/slurm-exporter/pull/new/feature/servicemonitor-custom-labels
- **參考範例**
- [feat: add custom labels support to ServiceMonitor #6](https://github.com/SlinkyProject/slurm-exporter/pull/6)

<br>

---

## Q & A
### ERROR: Permission to SlinkyProject/slurm-exporter.git denied to tsungjung411.
- ### Question

    $ git push -u origin feature/servicemonitor-custom-labels
    ERROR: Permission to SlinkyProject/slurm-exporter.git denied to tsungjung411.
    fatal: Could not read from remote repository.

    Please make sure you have the correct access rights
    and the repository exists.

- ### Claude (2025/10/13)
您沒有直接推送到 SlinkyProject/slurm-exporter 的權限。需要先 fork 這個專案。

<br>

### github PR 為何是 Pull Request (拉下請求)？ 為何不是 push request ?
- ### gpt-5 (2025/10/15)
簡單說：**因為你無法直接把東西「推（push）」進別人的儲存庫**。
在分散式版本控制（Git）的典型協作裡，你：

1. 在自己的 fork／分支上完成修改並「push 到自己的遠端」。
2. 接著向上游提出「請你們**拉（pull）**我的這些提交來合併」的**請求**。
→ 這個請求就叫 **Pull Request（PR）**：請對方執行「git pull」把你的分支抓去合併。

### 為什麼不是 “Push Request”？

* **權限模型**：沒有寫入權限的人不能 push 到上游；因此只能「請求上游來拉」。
* **動作的主體**：push 是你對自己的遠端做；要進別人的儲存庫，必須由對方發生「pull/merge」。
* **歷史慣例**：Git 本身就有 `git request-pull` 這個指令，產生一段變更摘要給上游維護者，意思也是「請你拉我的變更」。

### 那為什麼在同一個儲存庫、同組織內也叫 PR？

* 即便你有寫入權限，團隊仍常用 PR 作為**評審與測試的工作流程**（討論、審核、CI），名稱沿用一致的「請求拉取並合併」語意。

### 補充：不同平台的命名

* GitHub、Bitbucket：**Pull Request**
* GitLab：**Merge Request（MR）**（強調結果是「合併」）。概念等同，只是命名不同。

### 小圖示（方向感）：

    你本地 ──push──> 你的 fork 分支
                         │
                         └──(建立 PR：請上游「pull」這個分支)
    上游儲存庫 <──pull── 上游維護者審核後合併

<br>

## 參考資料
- [一起來學 Git 吧！(29) - 使用 GitHub - Pull Requests (PR)](https://ithelp.ithome.com.tw/articles/10339487)

<br>

{%hackmd vaaMgNRPS4KGJDSFG0ZE0w %}