이전에 블로그에 " 생존을 위한 Git" 이라는 주제로 블로그 글을 발행한 적이 있다
이번 글은 예시를 통해 왜 해당 명령어를 쓰는지 와닿게 작성하려고 한다
Q. 어! 원격 브랜치(타인과 공유되어 있음)의 커밋을 취소해야 할 것 같아요
reset과 revert중에 무엇을 사용해야 하나요?
두 명령어의 차이점을 예시로 알아보자
둘 다 취소하는 명령어지만 revert는 커밋 취소를 내역으로 남긴다
초기 상태에서 reset을 진행해보자
잘못된 커밋은
소리 소문 없이 사라지고
--soft HEAD~1 옵션으로 인해
staging 영역에 변경 사항이 있음을 알 수 있다
초기 상태에서 revert를 진행해보자
revert를 진행하니
revert가 일어났음을 표시하는 커밋을
추가하는 창이 떴다
기존 잘못된 커밋 히스토리는 유지된 채
revert가 일어났음을 표시하는 커밋이 추가되고
잘못된 커밋(1)이라고 readme에 적어뒀던 것도 사라졌다
한 마디로
revert는 잘못된 커밋 이력을 유지한 채 변경 내역을 되돌리는 작업을 진행한다
reset는 커밋 이력이 달라진다(잘못된 커밋이 사라짐)
만약에 reset을 공유하는 브랜치에 사용했다면 커밋 이력이 달라지고
독을 푼게 (?) 된다
주의하자
Q. A브랜치(아직 공유 x)에 A-1브랜치의 변경 내역을 받아오고 싶어요
rebase vs merge 차이
test/main-branch에서 첫번째 커밋 작성 후
feature-branch로 checkout해서 로컬 브랜치 최초 커밋을 작성
다시 test/main-branch에서 리모트 브랜치 두번쨰 커밋 작성
(커밋 메시지는 신경쓰지 말것)
merge를 진행해보겠다
merge 커밋이 feature-branch에 생겼다
rebase를 진행해보겠다
feature-branch 보면 로컬 브랜치 첫번째 커밋 완료했는데
test/main-branch에서 변경 커밋이 생긴 상황
main-branch의 커밋 내용을 앞에 붙이고
이후에 로컬 브랜치의 커밋이 붙는다
이때 로컬 브랜치의 커밋 해시 값은 변경 된다
-> 선형으로 커밋 로그를 유지할 수 있지만
커밋 내역에 변경이 생긴다
즉, 공유하는 브랜치로 이러면 일이 복잡해질 수 있다
그외의 원격 저장소의 변경사항을 로컬에 반영하는 다양한 방법
fetch : 원격 저장소의 변경 사항을 로컬로 가져온다. 단, 로컬 브랜치에는 영향을 미치지 않는다.
merge : 다른 브랜치의 변경 사항을 현재 브랜치에 병합한다.
pull (fetch + merge)
이번 배포에는 개발된 A, B, C 기능 중 B 기능만 들어갈거에요
B기능을 cherry-pick 해보자
test/cherry-pick-main-branch에 B기능을 cherry-pick하여 적용하려 한다
test/cherry-pick-main-branch 로 옮겨가서
git cherry-pick b9277df
git cherry-pick --continue
test/cherry-pick-main-branch에 B 기능만이 반영된 것을 볼 수 있다
끝
https://github.com/Eundms/learn-git
GitHub - Eundms/learn-git: Git 직접 해보기
Git 직접 해보기 . Contribute to Eundms/learn-git development by creating an account on GitHub.
github.com
[git] 생존을 위한 git : 파일의 상태, 커밋 히스토리
[git] 생존을 위한 git : 파일의 상태 , 커밋 히스토리
Tracked (관리대상) = Unmodified (수정하지않음) + Modified (수정함) + Staged (커밋으로 저장소에 기록할 상태) Untracked (관리대상이 아님) 처음 저장소를 Clone하면 모든 파일은 Tracked이면서 Unmodfied 상태이
eundms.tistory.com
[git] 생존을 위한 Git : merge, rebase, cherry-pick, squash and merge
[git] 생존을 위한 Git : merge, rebase, cherry-pick, squash and merge
이런 상황과거의 나 : (무지성) commit, merge 현재의 나 : (아! 생각보다 커밋 기록을 확인할 일이 있네.. 커밋 메시지랑 기록을 잘 남겨놔야 하는 것을 깨달은 상태)그래서, merge, rebase, cherry-pick, squa
eundms.tistory.com
[git] 생존을 위한 Git : 되돌리기 시리즈 --amend, reset, revert
[git] 생존을 위한 Git : 되돌리기 시리즈 --amend, reset, revert
reset1. staging area에 올라간 파일을 unstaging 할 때 이용 (git add 취소)2. 다른 사람간 코드가 공유되지 않는 경우 (ex - 혼자만 사용하는 브랜치) git reset [commit hash] : 해당 commit으로 브랜치의 참조를
eundms.tistory.com
[git] git branch 전략 : develop, release, hotfix
[git] git branch 전략 : develop, release, hotfix
1. Main 브랜치 출시 가능한 프로덕션 코드를 모아두는 브랜치 / 배포된 각 버전을 Tag를 이용해 표시 2. Develop 브랜치 다음 버전 개발을 위한 코드를 모아두는 브랜치 / 개발이 완료되면, Main 브랜치
eundms.tistory.com
[Slack] Slack과 Github, Jira 연동 (0) | 2025.01.09 |
---|---|
[Jira] Epic, Story, Bug, Task 관계 | Jira 와 Github 연동하기 (0) | 2025.01.07 |
[git] git branch 전략 : develop, release, hotfix (0) | 2024.03.18 |
[git] 생존을 위한 Git : 되돌리기 시리즈 --amend, reset, revert (0) | 2024.03.18 |
[git] 생존을 위한 Git : merge, rebase, cherry-pick, squash and merge (0) | 2024.03.15 |