https://team-edo.github.io/tags/git/Recent content in Git on 얼쑤 · Team EdoHugoko-krFri, 06 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/split-manual-web-deployment/Fri, 06 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/split-manual-web-deployment/<p>얼쑤의 Jenkins는 개발 브랜치 변경을 감지하면 백엔드를 검사하고 배포했습니다. 뒤이어 웹 잡도 자동으로 예약되는 구조여서, 백엔드 변경을 운영에 올릴 때도 별도의 웹 빌드가 시작됐습니다. 웹 배포 시점을 따로 정할 수 있게 트리거를 나누되, 운영 웹이 어떤 소스에서 나왔는지는 계속 확인할 수 있어야 했습니다.</p> <h2 id="수동으로-실행해도-소스를-지정하게-했다">수동 배포에서 소스 SHA 지정</h2> <p>백엔드의 자동 배포는 두고, 웹은 트리거가 없는 전용 잡으로 옮겼습니다. 운영자는 성공한 백엔드 빌드에서 검증한 전체 커밋 SHA를 웹 잡에 입력합니다. 웹 잡은 체크아웃 결과가 입력과 같고 해당 SHA가 개발 브랜치 이력에 포함되는지 확인한 뒤 빌드를 시작합니다. 기존 웹 잡은 비활성화해 이력 조회용으로 남겼습니다.</p>https://team-edo.github.io/posts/2026/11/guard-git-ref-updates/Mon, 02 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/guard-git-ref-updates/<p>병합 뒤 로컬 기준 브랜치를 정해진 커밋으로 옮겨야 했습니다. 다른 작업을 열어 둔 상태라 기준 브랜치로 체크아웃하지 않고 처리했습니다. 이때 필요한 확인은 브랜치가 아직 제가 확인한 커밋에 있는지, 그리고 옮길 커밋이 현재 이력을 그대로 포함하는지였습니다.</p> <h2 id="움직여도-되는-참조인지-확인했다">현재 참조와 조상 관계 확인</h2> <p>먼저 <code>git merge-base --is-ancestor &quot;$old&quot; &quot;$new&quot;</code>로 이전 커밋이 새 커밋의 조상인지 확인했습니다. 종료 코드가 0이어야 빨리 감기입니다. 다음으로 <code>git worktree list --porcelain</code>에서 옮길 브랜치를 사용하는 체크아웃이 없는지 확인했습니다. 체크아웃한 브랜치의 참조를 직접 바꾸면 그 폴더의 인덱스와 파일이 새 커밋에 맞춰 갱신되지 않기 때문입니다.</p>https://team-edo.github.io/posts/2026/10/coco-1-3-0-til-primary-checkout/Fri, 30 Oct 2026 09:12:48 +0900https://team-edo.github.io/posts/2026/10/coco-1-3-0-til-primary-checkout/<p>기존 <code>coco-learn</code>은 실행한 worktree 아래에 노트를 저장했습니다. 작업이 끝난 worktree를 정리하면 Git이 추적하지 않는 개인 TIL도 함께 사라질 수 있는 구조였습니다. 1.3.0에서는 작업 폴더의 수명과 학습 기록의 수명을 분리했습니다. 어느 worktree에서 <code>coco-til</code>을 실행하든 기본 체크아웃에서 기록을 다시 찾을 수 있게 했습니다.</p> <h2 id="작업-트리의-상태와-폴더에-남은-파일을-각각-본다">워크트리에 있던 가상 환경이 사라졌습니다</h2> <p>병합을 끝낸 워크트리를 <code>git worktree remove</code>로 제거한 뒤, 그 아래에 만든 Python 가상 환경 <code>.venv</code>가 함께 사라진 것을 확인했습니다. 브랜치 참조는 별도로 남았지만, Git이 무시하던 파일의 내용은 커밋에 없었습니다. 기본 <code>git status</code>가 깨끗해도 삭제할 폴더에 이런 파일은 남아 있을 수 있습니다. 제거 전에는 <code>git status --short --ignored</code>로 확인합니다. 가상 환경처럼 잠금 파일로 다시 만들 수 있는 산출물과 사본이 없는 작업 기록을 여기서 구분할 수 있습니다.</p>https://team-edo.github.io/posts/2026/10/verify-git-merge-beyond-conflicts/Wed, 28 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/verify-git-merge-beyond-conflicts/<p>진행 중인 작업을 바꾸지 않고 기준 브랜치와 충돌할지 미리 보고 싶을 때 <code>git merge-tree --write-tree HEAD origin/develop</code>를 사용했습니다. 작업 트리와 인덱스를 그대로 두고 두 커밋을 병합한 결과를 확인할 수 있습니다. 한 브랜치에서는 기준 브랜치에 새 커밋이 23개 들어왔을 때 검사에 충돌이 없었습니다. 이후 다른 변경이 먼저 병합되자 다시 실행한 검사에서 문서 충돌이 나타났고, 기준 브랜치를 실제로 합쳐 그 파일을 정리했습니다. 미리 본 결과는 그때 비교한 두 커밋에 대한 것이었습니다.</p>https://team-edo.github.io/posts/2026/10/coco-0-2-0/Tue, 20 Oct 2026 10:32:34 +0900https://team-edo.github.io/posts/2026/10/coco-0-2-0/<p>얼쑤에서 AI에 푸시를 맡기려면 먼저 무엇을 확인해야 할지 정해야 했습니다. 개발 브랜치가 바뀌었는지, 기존 테스트 결과를 재사용해도 되는지, Jira에는 언제 무엇을 남겨야 하는지가 모두 판단 대상이었습니다. HTTPS 전환 작업에서는 최신 개발 브랜치가 이미 작업 브랜치에 포함돼 검사 19개의 결과를 재사용했습니다. 서버 점검 작업에서는 새 변경을 통합한 뒤 테스트 13개를 다시 실행했습니다. 두 사례를 놓고 보면 팀별 기록 규칙과 검증을 다시 할 조건을 각각 어디에 둘지가 문제였습니다.</p>