1️⃣ 가장 권장: git revert (히스토리 보존, 안전)
이미 원격(main/dev)에 반영된 커밋을 되돌릴 때 표준 방법
특정 커밋의 변경 내용을 반대로 적용하는 새 커밋을 생성합니다.
🔹 단일 커밋 롤백
|
1 2 3 4 |
git revert <commit-hash> git push origin main |
🔹 여러 커밋 한 번에 롤백
|
1 2 3 |
git revert <oldest-commit>..<latest-commit> |
🔹 충돌 발생 시
|
1 2 3 4 5 6 |
git revert <commit-hash> # 충돌 해결 git add . git revert --continue |
📌 장점
- 커밋 히스토리 유지 (감사·추적 가능)
- Azure DevOps PR / 정책과 완벽 호환
- 실서비스 브랜치에 안전
📌 단점
- 커밋 수가 늘어남
✅ 운영/협업 환경에서는 무조건 이 방법
2️⃣ Azure DevOps Web UI에서 Revert (GUI 방식)
CLI 없이도 가능 (PR 기반)
절차
- Azure DevOps → Repos
- Commits 탭
- 롤백할 커밋 클릭
- 우측 상단 Revert 버튼
- 자동으로 Revert PR 생성
- PR 승인 → Merge
📌 내부적으로는 git revert와 동일
📌 main 보호 정책이 있는 경우 가장 깔끔
3️⃣ 특정 시점으로 완전히 되돌리기 (git reset) ⚠️ 주의
공유 브랜치에서는 절대 비추천
|
1 2 3 4 |
git reset --hard <commit-hash> git push origin main --force |
📌 문제점
- 이후 커밋 기록이 완전히 삭제됨
- 다른 개발자 로컬과 충돌
- Azure DevOps에서 강제 푸시 차단되는 경우 많음
✅ 혼자 쓰는 feature 브랜치에서만 허용
4️⃣ 특정 커밋 상태로 새 브랜치 생성 (안전한 임시 대응)
“이 커밋 상태로 서비스 다시 띄워야 할 때”
|
1 2 3 4 5 |
git checkout <commit-hash> git checkout -b hotfix/rollback-20260112 git push origin hotfix/rollback-20260112 |
이후:
- 해당 브랜치로 Release / Pipeline 실행
- 또는 main으로 PR
📌 장점
- 기존 히스토리 보존
- 핫픽스/긴급 대응에 매우 좋음
5️⃣ Azure DevOps Pipeline / Release 롤백 관점
코드가 아니라 배포 결과만 롤백하는 경우:
✔ Build 기반
- Pipelines → Runs
- 이전 성공 Build 선택
Deploy재실행
✔ Release 기반
- Releases → 이전 Release 선택
- Redeploy
📌 코드는 안 바뀌고 배포만 되돌림
🔥 실무 추천 시나리오
| 상황 | 추천 방법 |
|---|---|
| main/dev에 이미 반영 | git revert |
| UI에서 처리 | Commit → Revert → PR |
| 긴급 서비스 복구 | 특정 커밋으로 브랜치 생성 |
| 배포만 문제 | Pipeline/Release 재배포 |
| 개인 브랜치 | git reset --hard |
✍️ 요약 한 줄
Azure DevOps에서 특정 커밋 롤백의 정답은
git revert+ PR 이다.
PR 이란?
PR = Pull Request (풀 리퀘스트)
“내 브랜치에서 만든 변경사항을, 지정한 브랜치(main/dev 등)에
검토 후 병합(Merge)해 주세요” 라는 요청
Azure DevOps / GitHub / GitLab 모두 동일한 개념입니다.
git revert + PR 흐름을 사람 말로 풀면
- revert 전용 브랜치에서
git revert a26e15a9- → “되돌리는 변경” 커밋 생성
- PR 생성
- “이 되돌린 내용을 main 브랜치에 반영해도 될까요?”
- 리뷰 / 승인
- Merge
- main 브랜치에 안전하게 롤백 완료
PR을 쓰는 이유 (중요)
| 이유 | 설명 |
|---|---|
| 🔒 안전 | main에 바로 push 안 함 |
| 👀 검토 | 누가 무엇을 되돌리는지 명확 |
| 🧾 기록 | 왜 revert 했는지 히스토리 남음 |
| ⚙️ 자동화 | Pipeline / Policy / 승인 규칙 실행 |
| 🚫 사고 방지 | force push 방지 |
👉 Azure DevOps에서는 main에 직접 push 자체가 막혀 있는 경우가 대부분
PR 없이 하면 안 되나?
❌ 권장 안 됨
|
1 2 3 4 5 6 |
git checkout main git revert a26e15a9 git push origin main |
이건:
- 보호 브랜치 정책 위반
- 승인/로그 없음
- 실수 시 바로 장애
Azure DevOps에서 PR은 이렇게 생김
PR 화면에서는 다음을 확인합니다:
- Source branch:
revert-a26e15a9 - Target branch:
main - Commits:
Revert "Commit message..."
PR 제목 예시:
|
1 2 3 |
Revert commit a26e15a9 – hotfix rollback |