| sitelink1 | |
|---|---|
| sitelink2 | |
| sitelink3 |
당연히 타임 라인은 상단이 최신이다.
순서는 다음과 같다.
자세한 내용은 다음과 같다.
- 2db1e3bf - reapply 로 결국 대량의 merge로 원복
- 01e0d7cf - merge 로 revert 회수 (고육지책)
- b6a18bfd - revert 로 merge 회수 시도 (잘못된 접근)
- 20d6ad2a - 대량의 merge 발생
- e16f056b - merge 직전의 safety remote head
- daea3b8a - 작업자가 추가하려는 작업 (로컬은 장기간 구버전의 데이터인 상태)
- 973499eb - 분기 시작
위와 같은 타임라인이 만들어진 이유는 다음과 같다.
- 로컬에서 오래 pull하지 않아 대규모 merge 발생
- merge 커밋이 remote에 올라감
- 관리자가 revert 지시 → 일부 작업 이력 소실
- 작업자가 다시 merge 및 reapply 수행
이런 경우 copilot 은 다음과 같은 조치가 현명하다고 한다.
-> clean branch를 새로 만들어 필요한 커밋만 cherry-pick 하는 방식
위 방식도 이미 reapply까지 진행된 상태에서의 조치일텐데...
사실 대량의 merge 가 발생한 시점에 해당 이슈를 돌릴 방법이 먼저 급선무 였을 것이다.
그래서 위와 같이 대량의 merge 이슈 발생시의 대응 절차를 다음과 같이 정리하였다.
1. 작업 브랜치로 이동
git checkout 작업자브랜치 (현재 작업자가 쓰고 있는 브랜치)
2. rebase 기준을 e16f056b로 지정
git rebase --onto e16f056b 973499eb 작업자브랜치* 여기서 973499eb는 분기 시작점,e16f056b는 merge 직전의 기준점입니다.* 결과적으로 973499eb 이후의 작업 커밋(daea3b8a 등)만 e16f056b 위로 옮겨집니다.
3. 충돌 해결 후 push
git push origin 작업자브랜치 --force-with-lease
-- Copilot --
이렇게 하면 대량 merge가 유입되기 전의 깨끗한 환경(e16f056b)을 기반으로 작업자의 변경만 다시 적용할 수 있습니다.
즉, merge 흔적 없이 “직전 상태 + 작업자 수정”만 남는 브랜치가 만들어집니다.
참고로, 만약 e16f056b가 remote main의 HEAD 바로 아래라면, rebase 후 main에 병합할 때 충돌이 거의 없을 겁니다.
