Skip to content

chore: well-known 파일에 대한 dev main 각기 다른 버전 갖도록 gitattributes 적용 #2202

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ljh0608 merged 1 commit into from
Feb 18, 2026
Merged

chore: well-known 파일에 대한 dev main 각기 다른 버전 갖도록 gitattributes 적용 #2202

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions .gitattributes
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
# dev → main merge 시 대상 브랜치(main)의 .well-known 버전 유지
functions/.well-known/** merge=ours
public/.well-known/** merge=ours
Comment on lines +2 to +3
Copy link

@coderabbitai coderabbitai bot Feb 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

merge=ours 드라이버는 단방향 변경 시 동작하지 않습니다

이 설정은 실제 merge 중에 병합이 필요한 파일에만 적용됩니다. 중요하게도, merge 중에 해당 파일이 merge base 이후 병합 대상 브랜치에서만 수정된 경우 실제 병합이 필요하지 않으므로 수정된 버전이 그대로 적용됩니다.

즉, dev 브랜치에서만 .well-known 파일이 수정되고 main 브랜치는 공통 조상 이후 해당 파일을 변경하지 않았다면, Git은 충돌로 인식하지 않고 dev 버전을 그대로 main에 적용합니다. 드라이버는 호출되지 않습니다.

🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In @.gitattributes around lines 2 - 3, 현재 .gitattributes의
"functions/.well-known/** merge=ours" 및 "public/.well-known/** merge=ours" 항목은
단방향 변경(한 브랜치에서만 수정)일 때 드라이버가 호출되지 않아 기대한 동작을 하지 않습니다; 수정 방법은 .gitattributes에서 해당
패턴의 merge=ours를 제거하거나 이름을 바꿔(예: merge=keepMine) 커스텀 병합 드라이버를 정의한 뒤 사용하도록 변경하는
것입니다; 구체적으로는 .gitattributes에서 "functions/.well-known/** merge=keepMine" 및
"public/.well-known/** merge=keepMine"로 바꾸고 레포지토리 또는 전역 Git 설정(예: .git/config 또는
.gitconfig)에 "keepMine" merge driver를 등록하여 항상 현재 브랜치(ours)를 유지하도록 하는 드라이버를
구현/참조하세요.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

GitHub PR merge custom merge driver gitattributes

💡 Result:

GitHub’s Pull Request “Merge” button does not run your repo’s custom merge drivers (the merge=<name> entries in .gitattributes that rely on merge.<name>.driver), so you can’t make GitHub’s server-side PR merge automatically apply your custom merge tool.

  • Why: A custom merge driver’s executable command is defined in Git config (merge.<name>.driver in .git/config or ~/.gitconfig), not in .gitattributes, and GitHub can’t safely execute arbitrary, repo-supplied programs during merges. Git docs explicitly place the driver definition in config, not attributes. [1]
  • GitHub behavior: GitHub does not support custom merge drivers for PR merges; recommended workaround is to merge locally (or with a bot) if you need that behavior. [2]
  • Related limitation reported by users: GitHub PR conflict handling historically hasn’t honored user-defined .gitattributes in the web conflict editor/merge flow in the way people expect. [3]

What you can do instead

  1. Merge locally (recommended): Pull the PR branch and run git merge in your own environment where the driver is configured, then push the result. [2]
  2. Use a bot/CI merge: Have a GitHub Action (or external service) check out the branches, configure merge.<name>.driver, perform the merge, and push back (or open an updated PR). This is the usual way to get deterministic “server-side” merges while still using custom drivers. [2]
  3. If you only need built-in behaviors: GitHub merges will respect normal Git merge behavior, but anything requiring merge.<name>.driver execution won’t happen unless you do (1) or (2).

Sources:
[1] Git documentation: custom merge driver is defined in Git config, invoked via .gitattributes merge=<name>. https://git-scm.com/docs/gitattributes.html
[2] Stack Overflow: “GitHub does not support custom merge drivers… use a bot / merge locally.” https://stackoverflow.com/questions/65309426/how-to-enable-custom-merge-driver-gitattributes-in-github
[3] GitHub Community discussion referencing GitHub Support response about not considering user .gitattributes in PR conflict handling. https://github.com/orgs/community/discussions/9288

🌐 Web query:

GitHub server-side merge gitattributes merge=ours driver

💡 Result:

GitHub’s server-side merge (the merge that happens when you click “Merge pull request”) does not run custom Git merge drivers, because merge-driver commands are defined in Git config (e.g., merge.<name>.driver) and GitHub will not execute arbitrary programs based on repository content for security reasons. So a repo-only .gitattributes line like:

path/to/file merge=ours

won’t be honored on GitHub unless the server is explicitly configured with a matching driver (which GitHub.com does not support for arbitrary repos). (stackoverflow.com)

What does work:

  • Locally / in CI (where you control Git config), you can implement “keep ours” by defining a driver and referencing it from .gitattributes (merge drivers are configured in Git config, not shipped in the repo). (stackoverflow.com)
  • On platforms where the server is configurable (example: GitLab via server-side Git config), admins can set merge.<name>.driver globally so .gitattributes can take effect during server-side merges. (docs.gitlab.com)

Practical workaround on GitHub: perform merges via a bot/GitHub Action (checkout → set merge.ours.driver → merge → push), and restrict merges to that automation. (stackoverflow.com)

Citations:

🌐 Web query:

GitHub API merge behavior custom merge drivers 2024 2025

💡 Result:

  • GitHub’s merge APIs only let you choose the PR merge method (not a custom Git merge driver). In the REST API “Merge a pull request” endpoint (PUT /repos/{owner}/{repo}/pulls/{pull_number}/merge), merge_method can only be merge, squash, or rebase. [1]
  • Those correspond to GitHub’s UI merge options (merge commit, squash, rebase), and GitHub’s “rebase and merge” rewrites commits (new SHAs / committer) rather than behaving exactly like a local git rebase. [2]
  • Custom Git merge drivers (e.g., .gitattributes merge=… with a [merge "..."] driver = ... command) are not supported on GitHub.com/GitHub-hosted merges, because the driver command lives in Git config (not in the repo) and running arbitrary commands server-side would be a security risk. [3]
  • If your base branch requires a merge queue, the merge method is controlled by the merge queue configuration (merge/rebase/squash), not chosen per-merge at the time you call the merge API/UI. [2][4]
  • Practical workaround if you need “custom merge-driver-like” behavior: do merges in a controlled environment (CI/bot) where the driver is installed/configured, then push the result (or have the bot perform the merge via the API after preparing the branch). This is commonly recommended when custom drivers are required. [3]

Sources:
[1] GitHub REST API – “Merge a pull request” (merge_method: merge/squash/rebase) (docs.github.com)
[2] GitHub Docs – merge methods + note on rebase-and-merge behavior and merge queue controlling merge method (docs.github.com)
[3] Stack Overflow (bk2204) – GitHub does not support custom merge drivers; config not shipped; security hazard; use a bot (stackoverflow.com)
[4] GitHub Docs – Managing a merge queue (merge method selection in queue settings) (docs.github.com)

Citations:

GitHub PR 병합은 커스텀 merge driver를 실행하지 않습니다

GitHub는 사용자가 정의한 .gitattributes의 merge=ours 설정을 PR 병합 시 적용하지 않습니다. 이는 GitHub의 알려진 플랫폼 제한 사항으로, 커스텀 merge driver의 명령어가 Git 설정 파일(.git/config 또는 ~/.gitconfig)에 정의되어 있고, GitHub가 보안상의 이유로 저장소 콘텐츠 기반의 임의 프로그램 실행을 허용하지 않기 때문입니다. 따라서 이 접근 방식으로는 dev → main 병합 시 .well-known 버전을 보호하는 목표를 달성할 수 없습니다.

실제 대안:

  • GitHub Actions 워크플로우로 병합 자동화: 브랜치를 체크아웃한 후 Git 설정에 driver를 등록하고 병합을 수행한 뒤 푸시하는 방식으로, 서버 환경에서 커스텀 driver를 실행할 수 있습니다.
  • .well-known 파일을 배포 워크플로우에서 관리: 환경별 버전을 배포 시점에 주입하도록 변경하여, 소스 코드 병합과 배포 관리를 분리합니다.
🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In @.gitattributes around lines 2 - 3, The .gitattributes entries
"functions/.well-known/** merge=ours" and "public/.well-known/** merge=ours"
won't be honored by GitHub PR merges because GitHub doesn't run custom merge
drivers; remove or stop relying on these patterns in .gitattributes and instead
implement one of the recommended alternatives: create a GitHub Actions workflow
that checks out the branch, registers the custom merge driver in the runner's
git config and performs the merge/push, or remove .well-known from source merges
and manage/inject the correct .well-known files during the deployment workflow
(e.g., in your deploy job), updating CI/CD workflows accordingly to ensure the
intended .well-known versions are preserved.

1 change: 1 addition & 0 deletions package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@
"playground-common"
],
"scripts": {
"prepare": "git config merge.ours.driver true || true",
Copy link

@coderabbitai coderabbitai bot Feb 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

CI/CD 환경 및 드라이버 미등록 시 무음 실패(silent failure) 위험

git config merge.ours.driver true는 --global 없이 실행되므로 로컬 .git/config에만 설정됩니다. 이는 yarn install이 실행된 로컬 워크스페이스에서만 동작하며, 다음 상황에서는 드라이버가 등록되지 않습니다:

  • CI/CD 파이프라인에서 yarn install --immutable(Yarn Berry 기본 CI 플래그) 사용 시 lifecycle scripts 실행 여부에 따라 등록되지 않을 수 있음
  • 새로 클론한 환경에서 yarn install을 실행하기 전에 merge를 수행하는 경우

더 중요한 것은, 드라이버를 등록하지 않으면 merge=ours가 동작하지 않더라도 Git이 자동으로 무시하며 아무런 경고를 출력하지 않습니다. 이로 인해 보호가 실패해도 인지하기 어렵습니다.

위 .gitattributes 댓글에서 언급한 GitHub 서버 사이드 PR 병합 제한으로 인해 이 prepare 스크립트의 실효성이 제한적임도 함께 고려하십시오.

🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@package.json` at line 9, The current prepare script ("prepare": "git config
merge.ours.driver true || true") only writes to the local repo config and
silently ignores failures; change it to explicitly register the driver globally
and fail loudly if registration fails (e.g., replace the command with one that
uses --global: git config --global merge.ours.driver true && git config --global
merge.ours.name "ours merge driver" || exit 1), and/or add a verification step
in the prepare script that reads back the config and exits non‑zero if the
expected key is not present (so CI runs like yarn install --immutable cannot
silently skip registration); reference the "prepare" script and the existing
command string "git config merge.ours.driver true" when making the change.

"analyze": "cross-env ANALYZE=true next build",
"build": "next build",
"build-storybook": "cross-env NODE_OPTIONS='--max-old-space-size=4096' storybook build",
Expand Down
Loading