git & github (2)

프로젝트 관리의 첫 걸음 - 로컬 저장소 생성 및 기본 명령어

 

챕터_1_명령어_정리.pdf

0.06MB

 

https://vim.rtorr.com/lang/ko

● reset: 과거를 지우는 방식
특정 커밋 이후의 모든 기록을 삭제.
커밋 로그에서 사라지므로, 협업 환경에서는 위험할 수 있음.
보통 과거 커밋으로 상태를 "초기화"하고 싶을 때 사용.

● restore: 파일 단위로 되돌리는 방식
커밋 전체가 아니라 파일 단위로 변경 사항을 되돌림.
"작업 중인 파일"이나 "스테이징된 파일"의 상태를 복구.
과거 커밋 기록은 전혀 영향을 받지 않음.

● revert: 되돌리지만 기록을 유지
특정 커밋의 변경 사항을 취소하는 새 커밋을 생성.
커밋 기록을 안전하게 유지하면서 작업을 되돌릴 수 있음.
협업 환경에서 가장 안전한 방법.

● respt

○ 지우개로 과거 페이지를 완전히 지움

○ " 아무 일도 없던 것처럼" 상태를 바꾸고 싶을때

 

● restore

○ 책의 특정 페이지를 복구

○ 전체가 아니라 특정 부분만 되돌리고 싶을 때.

 

● revert

○ 틀린 내용을 고치고 새 노트를 추가.

○ 변경 사항을 취소했음을 기록에 남기며 되돌림

 

요약하기

● reset은 브랜치 히스토리 재작성 도구

● restore는 파일 단위 상태 복구 도구

● revert는 안전한 변경 취소 도구
라고 볼 수 있습니다.

 

`https://kangdy25.tistory.com/134 // git reset, restore, revert에 대한 블로그 참고 글

---

인터스텔라를 생각하며 - Git 버전 되돌리기 

 

< Git Restore 명령어와 스테이지 옵션의 실제 활용 및 커밋 메세지 관리하기 >

● restore 명령어는 스테이징 영역에 올린 변경 작업을 해제하여 워킹 디렉토리로 돌리는 역할을 합니다.

● 이 명령어 사용 시 작업 내용을 커밋에 반영하기 전,
추가 수정을 위해 스테이징 영역에서 다시 내려 자유롭게 수정을 진행할 수 있습니다.

● 옵션 없이 restore를 실행하면 직전 커밋 상태로 돌아가며, --staged 옵션을 사용하면 
스테이징 영역의 변경만 해제되고 파일의 실제 변경 내용은 유지됩니다.

● restore --staged 옵션은 해당 파일을 '추적되지 않는 상태' 로 복원하며, 삭제 없이 
변경 내용만 스테이징 해제하는 데 사용합니다.

● 불필요한 커밋을 방지하고, 정말 중요한 내용만 커밋하도록 커밋 메시지 작성 전 
스테이징 영역을 조절하는 것은 효율적이고 신중한 버전 관리에 필수적입니다.

 

< Git revert 동작과 사용법, 협업 환경에서의 장점 알아보기 >

revert 명령어는 기존 커밋 내용을 취소하면서 기록을 보존하고, 새로운 커밋을 생성합니다.

● revert는 커밋 단위로 동작하며, 변경사항을 취소하지만 과거 기록은 남기기 때문에 
협업 환경에서 안전하게 사용할 수 있습니다.

● -n 옵션을 사용하면 변경사항만 취소하고, 새로운 커밋은 생성하지 
않아 추가 수정 후 커밋할 수 있습니다.

● 여러 작업을 한 커밋으로 합치고 싶을 때도 사용할 수 있습니다.

● 실제 예시에서 revert 실행 시 새로운 해시값을 가진 취소 커밋이 생성되고
git log에서 이전 커밋이 취소됨이 기록됩니다.

● HEAD 옵션을 사용하면 가장 최근의 커밋을 취소할 수 있고, reset HEAD와 유사하지만 
기록이 보존됩니다.

● 여러 번 revert를 반복하면 취소 커밋명이 중복될 수 있으나, 이는 커밋명을 바꾸는 것으로 
해결할 수 있습니다.

 

< Revert 명령어의 HEAD, -n 옵션 활용과 Reset/Restore/Revert 차이 요약하기 >

● git revert -n 옵션을 사용하면 취소된 변경사항을 다시 
워킹 디렉토리(directory)에 배치할 수 있으며, 이 과정을 통해 작업의 이어받기가 가능합니다.

● 해당 옵션을 적용하면 새로운 커밋이 생성되지 않고, 변경 사항이 스테이징 영역으로 이동해 
관리할 수 있습니다.

● 실제 예시에서는 "git log"로 확인한 최근 커밋의 해시 값을 복사한 뒤 revert -n을 적용해 
기존 작업 내용을 워킹 디렉토리로 되돌릴 수 있었습니다.

● Reset, Restore, Revert는 각각 커밋 삭제, 스테이징 영역 수정, 커밋 기록 보존 등 
동작상의 분명한 차이가 있습니다.

● 앞으로 고급 git 사용법과 특정 커밋으로 회귀하는 다양한 방법에 대해 추가 학습 기회가 
제공될 예정입니다.

---

원하는 것만 쏙쏙 - 특정 버전의 커밋 가져오기 

지난 시간에는 우리가 커밋한 기록을 어떻게 수정하고, 불필요한 커밋을 
삭제하거나 취소 작업을 수행 후, 새로운 커밋을 구성하는 작업 등을 진행했습니다.
 
이번 시간에는 이제 조금 더 본격적으로 git을 사용할 때 branch라는 것을 구성해서 
매 작업 환경을 만들어주는 방법에 대해 설명해보고자 합니다.
 
사실 우리가 git을 처음 사용할 때 작업하는 branch도 main이라는 것을 사용하고 있습니다.
 
다만, branch를 국문으로 나무 가지라고 해석할 수 있는 것처럼 우리가 git을 사용하면서 
무수히 많은 브랜치를 생성하고 사용할 수 있습니다.
 
브랜치를 사용하는 방법을 이해하는 것은 git을 더 빠르게 이해할 수 있다는 것과 일맥상통합니다.
 
사실상 git의 꽃이라고 봐도 무방합니다.

 

우리가 브렌치를 사용해야하는 이유

● 보통 개발하는 환경에서 새로운 기능을 개발 및 테스트하는 환경, 사용자들에게 서비스를 배포하기 전 점검하는 환경
그리고 실제 사용자들이 접속해서 사용하는 환경으로 나눠 구분해 코드를 관리하는 것이 관례처럼 받아들여지고 있습니다.

● 이처럼 개발하는 코드를 각 환경에 맞춰 격리해서 사용하고, 기능 개발이 마무리 되면 다음 단계의 환경으로 이전하는 작업들을 수행해줘야하는데 
새로 개발하는 기능에는 항상 버그나 오작동이 존재할 수 있으므로 브랜치로 충분히 코드를 격리 시켜 사용해야하는 과정이 꼭 필요합니다.

● 프로젝트 규모가 작을 때는 브랜치를 사용 안하는 것이 더 편할 수도 있지만, 일정 규모 이상 개발 규모가 커지면 
반드시 브랜치 기반으로 코드를 작업해주는 것이 필요합니다.

 

잠깐 분산형 버전 관리 시스템을 기억해 봅시다.

Q. 우리가 “백업”을 잘 남기는 게 분산형 버전 관리 시스템에서 중요하다면, 
일정 작업 단위가 끝날 때마다 틈틈이 커밋을 생성해 주면 되는 것 아닌가요?

A. 커밋을 잘 남겨주는 것은 좋은 습관이에요! 특히 여러명이 협업하는 단계에서 
본인의 업무를 어디까지 했는지 파악하는 것에도 많은 도움을 얻을 수 있고
반대로 다른 팀원들이 일을 어디까지 했는지 자동으로 업무 공유가 되기 때문이에요.

하지만 너무 빈번하게 커밋을 남기면 되려 지나치게 많은 커밋 때문에 어떤 작업으로 
업무 현황을 파악해야하는지 파악하기 힘들답니다!

특히, 지난번에 배운 Revert의 경우, 앞전의 커밋을 취소하고 새 커밋을 만들기 때문에 
안봐도 되는 커밋 (히스토리 파악용 취소 커밋)이 생기기 때문에 더 복잡해질 수 있습니다.

그런데 이게 전부 제품을 배포하는 하나의 브랜치에서 발생하는 문제라면? 😱

그래서 브랜치를 개발 업무에 반드시 도입이 필요하답니다!

 

위 그림이 의미하는 바가 무엇일까요?

● 2개의 브랜치 (experiment, master) 에서 각각 작업한 결과 커밋 C4, C3가 있습니다.

여기서 experiment 브랜치에서 작업한 코드를 master 브랜치에 합쳐서 C2라는 
브랜치로 구성하는 것을 볼 수 있습니다.

이 행위를 Merge라고 하며, 챕터 5에서 Conflict 해결하기 심화 부분에서 더 자세하게 배우게 됩니다.

중요한 것은 branch라는 단어가 나뭇가지인 것처럼 가지가 너무 길면, 사람들이 가지치기를 
해주듯 일정 시점이 되면 다른 branch로 계속 합쳐지는 특성을 갖고 있다는 것이에요.

 

Q. 일반적인 브랜치 사용 방법은 어떻게 되나요?

A. 보통은 프로젝트에서 개발하는 단계에 따라 dev / stage / prod (또는 main 브랜치 그대로 사용) 
라는 명칭으로 브랜치를 구성해 개발하거나, 개발 버전에 따라 브랜치 이름을 
v1.0.0, v1.0.0-beta 형태로 이름을 지어서 관리하기도 한답니다.

해당 부분에 대한 자세한 내용은 챕터5의 브랜치 전략에서 학습하게 됩니다.

 

https://wikidocs.net/66830 >> 브랜치(Branch) 기초 학습 

https://git-scm.com/docs/git-cherry-pick git cherry-pick 관련 

 

순서대로 브랜치 확인하기

 

[ 1 ] 현재 사용 중인 브랜치 확인하기
먼저 git 명령어를 사용해서 현재 사용 중인 브랜치가 어디인지 확인해 보도록 하겠습니다.

git branch

위의 명령어를 입력하면 현재 사용자의 프로젝트 환경에서 구성되어 있는 모든 브랜치 목록을 
조회할 수 있고, 현재 사용 중인 브랜치는 * main 이라고 표기되는 것을 볼 수 있습니다.

참고로 윈도우에서 git bash를 사용하면, 아래처럼 기본적으로 현재 사용하고 있는 
브랜치 이름이 터미널 옆에 표기되는 것을 볼 수 있어요.

 

[ 2 ] 새 브랜치 생성하기

실습을 위해 새 브랜치를 생성해보겠습니다.
브랜치 이름은 cherry-pick 이라고 만들어볼게요.

git branch cherry-pick

생성이 잘 되었다면 다시 git branch 커맨드를 입력해서 생성된 브랜치 목록을 조회합니다.
현재는 cherry-pick이라는 브랜치를 사용하고 있지 않기에 흰색으로 표기되어 있습니다.

 

[ 3 ] git 도구로 생성된 브랜치 확인해보기

왼쪽 사이드 메뉴 하단에서 git 도구에서 우리가 조금 전 생성한 
cherry-pick 이라는 브랜치가 생성된 것을 볼 수 있습니다.

주목할 점은 현재 main 브랜치를 선택해도, cherry-pick 브랜치를 선택해도 
현재 로그가 모두 동일합니다. 
 
그 이유는 아직 cherry-pick 브랜치에서 작업한 것이 아무것도 없기 때문에 그렇습니다.

.

 

[ 4 ] 브랜치 생성 시점에 대한 이해

우리가 브랜치를 생성하게 될 때, 그 브랜치가 지금 “어떤 브랜치”를 
기준으로 새로 생성하는지에 대해 이해하는 것이 중요합니다.
 
지금은 우리가 이전 강의에서 “Revert”라는 취소 커밋 작업이 이뤄진 직후 커밋을 생성했죠?
 
그래서 지금 새로운 브랜치가 시작하는 지점은 생성하는 브랜치의 가장 최신 커밋을 기준으로 생성됩니다.
 
즉, 만약 main 브랜치가 아닌 다른 브랜치에서 또 다른 브랜치를 만든다면
그 때마다 시작하는 커밋의 기점은 계속 달라지겠죠?

[ 5 ] 브랜치 이동하기

이제 branch 를 이동해보겠습니다.
checkout 이라는 명령어를 사용해서 이동할 브랜치 이름을 입력해 바꿔봅니다.

git checkout cherry-pick # 이동할 브랜치 이름을 입력

아래처럼 cherry-pick 브랜치가 이동되는 것을 볼 수 있습니다.

git 도구에서도 현재 사용 중인 브랜치의 순서가 바뀐 것을 볼 수 있습니다.

 

[ 6 ] cherry-pick 브랜치에서 새 커밋 기록하기

이제 새 브랜치로 이동했으므로, 여기서 git cherry-pick 명령어 
실습을 진행하기 위해 새 커밋을 기록해봅니다.

cherry-pick 브랜치 테스트 입력 입니다.

git add dummy.txt
git commit -m "Added: cherry-pick test text"

커밋이 이뤄지고난 결과는 아래 그림처럼 cherry-pick 커밋이 먼저 생성해서 작업했던 main 
브랜치보다 최신 커밋으로 구성된 것을 볼 수 있습니다.

[ 7 ]조금 이해가 되셨나요?

git 공식문서에 있는 도식 중 저희 상황과 거의 흡사한 도식을 가져와 보여드린다면, 
아래와 같은 상황이라는 것을 알 수 있을 것입니다.

시작했던 브랜치보다 새로 생성한 브랜치의 커밋이 더 앞에 있는 것은 전혀 잘못된 점이 아닙니다.

문제가 있으면 원본 코드는 그대로 두고, 새로운 브랜치에서 값을 수정 후 문제가 없으면 
원본 코드에 합치는 것이 정상이에요.

작업 중 원하는 커밋만 main에 반영하기 위해 cherry-pick 사용하기!

본래 영문 표현으로 cherry-picker라는 말이 있습니다.
 
고객이 기업 제품을 구매하지 않고 프로모션이나 혜택만 잔뜩 챙기는 행위를 언급하는 
부정적인 의미로 쓰이는데, 사실 우리가 필요한 특정 커밋만 다른 브랜치로 가져오는 것도
행위가 비슷하기 때문에 (브랜치 작업을 병합 - merge - 하지 않고 특정 작업만 다른 브랜치로 
가져오므로) 이러한 명령어로 구성했다고 볼 수 있습니다.

오히려 급하게 수정한 사항을 빨리 배포하는 코드에 반영해야하는 
상황에서 유리한 게 cherry-pick입니다.

 

[ 1 ] 다시 main 브랜치로 이동하기

git checkout main

다시 main 브랜치로 이동하는 것은 매우 간단합니다.
동일하게 checkout을 사용해서 main 브랜치를 입력해주면 됩니다.
notion image
다만, 한 가지 신기한 게 보입니다.
git 도구에서 main 브랜치로 넘어오니, cherry-pick 브랜치의 시각화 방식이 바뀌었기 때문입니다.
정말 말 그대로 “나뭇가지”가 생긴 것처럼 cherry-pick 브랜치가 하나 더 앞서 생긴 것이 보이죠?

 

[ 2 ] cherry-pick 브랜치 커밋 가져오기

main 브랜치에 cherry-pick 브랜치 작업을 가져와 반영하기 위해 아래 명령어를 수행해볼게요.

git cherry-pick <다른 브랜치의 커밋 해시 값>

참고로 다른 브랜치 커밋 해시 값은 git 도구에서 조회가 가능합니다.

 

[ 3 ] 커밋 자체의 반영

작업을 수행하면 보시는 것과 같이 main 브랜치에 새로운 커밋으로 값이 반영되는 것을 볼 수 있습니다.

지금 git 도구에서 새로운 커밋으로 main에 값이 생성된 것을 볼 수 있죠?

git reset 때와는 다르게 커밋 자체를 다른 브랜치로 가져와 작업하는 것이기 때문에 그렇습니다.

 

Q. 그런데 매번 다른 브랜치에서 작업한 코드를 cherry-pick으로 가져와 사용하면 되는건가요?

A. 그렇지 않습니다.

현재 브랜치라는 기능에 대한 설명, 그리고 하나의 브랜치에서 생성된 커밋을 다른 브랜치로 어떻게 
반영하는지에 대해 빠른 이해를 위한 설명을 목적으로 cherry-pick을 언급하긴 했지만, 
사실 cherry-pick을 사용하는 상황은 조금 더 특수한 상황에 이용되긴합니다.

cherry-pick을 사용하는 상황 예시

● 변경 사항만 선택적으로 복사
Cherry-pick은 특정 커밋만 선택해서 복사하기 때문에 원래의 브랜치(예: cherry-pick)와 
현재 브랜치(예: main)가 독립적입니다.

브랜치 간의 관계를 유지하지 않으며, 단순히 "변경 내용만 가져오는" 방식입니다.

● 작업 내역이 단절
Cherry-pick으로 가져오면, 복사된 커밋이 원래 브랜치와는 완전히 별개의 기록이 됩니다.
이로 인해 "이 커밋이 어디서 왔는지" 추적이 어려울 수 있습니다.


● 사용 사례
긴급 버그 수정이나 특정 기능 일부만 다른 브랜치에서 적용하고 싶을 때.

 

Github에서 Pull Request, Merge를 수생한다.

챕터 3에서 github 연동을 수행하는데, 이 때 더 보편적인 상황에서 이용하는 Pull Request, Merge라는 
작업을 수행해서, 코드를 합칠 수 있습니다.

우리가 git은 코드의 변경 이력을 추적하고 관리하는 도구라고 했습니다. 즉, 개별 브랜치 사이의 
커밋 기록은 잘 보존하면서 특정 브랜치의 작업이 마무리 되면, 이제 그 브랜치에서 마무리한 
작업을 기준이 되는 주요 브랜치에 통합하는 절차를 밟게 됩니다.

이 때 점검하는 절차를 Pull Request라고 하며, 코드를 합치는 것을 Merge라고 부릅니다.

여기서는 각각 기능에 대해서만 짧게 설명하고 챕터 3에서 github을 연동할 때 다시 한 번 설명해보도록 하겠습니다.

해당 작업들은 GUI에서 실행되기 때문에 git을 사용할 때보다 직관적으로 이해하기 쉽습니다.