chore: well-known 파일에 대한 dev main 각기 다른 버전 갖도록 gitattributes 적용#2202
chore: well-known 파일에 대한 dev main 각기 다른 버전 갖도록 gitattributes 적용#2202
Conversation
Summary by CodeRabbit릴리스 노트
개요이 PR은 Git 병합 전략을 설정하여 dev에서 main으로 병합할 때 변경 사항
코드 리뷰 예상 소요 시간🎯 1 (Trivial) | ⏱️ ~5분 관련된 가능성 있는 PR
추천 리뷰어
시
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
🚀 프리뷰 배포 확인하기 🚀 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.gitattributes:
- Around line 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)를 유지하도록 하는 드라이버를 구현/참조하세요.
- Around line 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.
In `@package.json`:
- 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.
| functions/.well-known/** merge=ours | ||
| public/.well-known/** merge=ours |
There was a problem hiding this comment.
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)를 유지하도록 하는 드라이버를
구현/참조하세요.
🧩 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>.driverin.git/configor~/.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
.gitattributesin the web conflict editor/merge flow in the way people expect. [3]
What you can do instead
- Merge locally (recommended): Pull the PR branch and run
git mergein your own environment where the driver is configured, then push the result. [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] - If you only need built-in behaviors: GitHub merges will respect normal Git merge behavior, but anything requiring
merge.<name>.driverexecution 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=ourswon’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>.driverglobally so.gitattributescan 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:
- 1: https://stackoverflow.com/questions/65309426/how-to-enable-custom-merge-driver-gitattributes-in-github?utm_source=openai
- 2: https://stackoverflow.com/questions/53429202/git-recursive-merge-strategy-options-within-gitattributes?utm_source=openai
- 3: https://docs.gitlab.com/user/project/repository/files/git_attributes/?utm_source=openai
- 4: https://stackoverflow.com/questions/65309426/how-to-enable-custom-merge-driver-gitattributes-in-github?utm_source=openai
🌐 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_methodcan only bemerge,squash, orrebase. [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.,
.gitattributesmerge=…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:
- 1: https://docs.github.com/enterprise-cloud%40latest/rest/pulls/pulls?utm_source=openai
- 2: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github?utm_source=openai
- 3: https://stackoverflow.com/questions/65309426/how-to-enable-custom-merge-driver-gitattributes-in-github?utm_source=openai
- 4: https://docs.github.com/enterprise-cloud%40latest/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue?utm_source=openai
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.
| "playground-common" | ||
| ], | ||
| "scripts": { | ||
| "prepare": "git config merge.ours.driver true || true", |
There was a problem hiding this comment.
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.
1 participant
🤫 쉿, 나한테만 말해줘요. 이슈넘버
🧐 어떤 것을 변경했어요~?
🤔 그렇다면, 어떻게 구현했어요~?
❤️🔥 당신이 생각하는 PR포인트, 내겐 매력포인트.
📸 스크린샷, 없으면 이것 참,, 섭섭한데요?