주요 git 명령어
| 명령어 | 설명 |
|---|---|
| git init | 현재 디렉토리를 git이 추적하는 저장소로 초기화합니다. .git 폴더를 생성하고 빈 저장소의 상태를 확인합니다. |
| git add | 변경된 파일을 Staging Area에 올립니다. 파일별 또는 전체로 추가가 가능합니다. |
| git status | 현재 브랜치, 커밋 상태, 스테이징된 파일과 추적되지 않은 파일을 구분해서 확인할 수 있습니다. |
| git commit | stage에 올린 변경사항을 저장합니다. 메세지 작성 규칙이 존재하며 이를 지키는게 중요합니다. |
| git commit -m | 간단한 메세지로 바로 커밋이 가능합니다. 작은 변경이나 테스트에 활용됩니다. |
| git diff | 커밋 전후, 브랜치 간, 커밋 간 변경 사항을 비교합니다. |
| git log | 커밋 이력, 작성자, 시간, 메세지 등을 확인합니다. |
commit 메세지 작성 규칙
- 제목은 50자 이내
- 본문은 변경의 이유와 내용을 담아 72자 이내
- 꼬리말(이슈 트래커, BREAKING CHANGE 등)
으로 구성됩니다.
commit 되돌리기
reset, restore, revert
| 명령어 | 동작 방식 | 사용하는 상황 |
|---|---|---|
| reset | 커밋 이력 자체를 삭제합니다. 브랜치의 포인터를 과거 커밋으로 이동시키고 옵션에 따라서는 스테이징/작업 디렉토리에 영향을 주기도 합니다. | 혼자 작업을 하는 경우, 커밋의 정리가 필요한 경우 |
| restore | 파일 단위로 변경 사항을 복구합니다. 커밋의 이력은 그대로 두며 워킹/스테이징 파일만 복구합니다. | 파일만 되돌릴 때, 커밋 전 수정을 취소할 때 |
| revert | 특정 커밋의 변경 사항을 취소하는 새 커밋을 생성합니다. 커밋의 이력은 보존합니다. | 협업 시, 안전하게 커밋 취소 |
reset
- --soft: 커밋만 되돌립니다. 스테이징의 상태는 그대로 둡니다.
- --mixed: 커밋과 스테이징 모두를 되돌리고 작업 디렉토리는 유지합니다. 기본값입니다.
- --hard: 커밋, 스테이징, 작업 디렉토리까지 모두 과거 상태로 초기화 합니다.
restore
- git restore <file>: 해당 파일을 가장 최근 커밋 상태로 복구합니다.
- git restore --staged <file>: 스테이징을 해제합니다.
revert
- git rever <commit>: 해당 커밋의 변경 사항을 취소하는 새 커밋을 생성합니다.
- git revert HEAD: 가장 최근 커밋을 취소하는 새 커밋을 생성합니다.
- git revert -n <commit>:취소만 하고 커밋은 하지 않습니다. 여러 작업을 합쳐 커밋할 때 유용합니다.
Git 브랜치
브랜치는 git에서 나뭇가지처럼 독립적인 작업 공간을 만들 수 있는 기능입니다. 기본적으로는 main 브랜치에서 작업을 하는데, 새로운 기능 개발, 테스트, 배포 전 점검 등 목적에 따라서 여러 브랜치를 만들고 코드를 격리하여 관리합니다.
브랜치를 사용하면 각 환경에 맞추어 코드를 분리 및 관리할 수 있으며 규모가 커질 수록 필수적인 전략입니다.
브랜치를 사용하는 이유?
- 기능별, 환경별로 코드를 안전하게 격리시킬 수 있습니다.
- 여러 명이 동시에 개발할 때 충돌을 줄일 수 있으며, 각자 작업을 독립적으로 진행할 수 있습니다.
- 배포, 테스트, 긴급 수정 등 다양한 상황에 맞추어 유연하게 코드 관리를 할 수 있습니다.
브랜치의 생성과 관리
- 현재 브랜치 확인:
git branch - 새 브랜치 생성:
git branch 브랜치이름 - 브랜치 이동:
git checkout 브랜치이름
브랜치를 생성하면, 현재 위치한 최신 커밋을 기준으로 새 브랜치가 만들어지게 됩니다. 브랜치마다 커밋 이력이 독립적으로 쌓이며 나중에 병합할 수도 있습니다.
Cherry-pick
한 브랜치의 특정 커밋만 선택적으로 다른 브랜치에 복사해오는 Git 명령어입니다. 긴급 버그 수정이나 특정 기능만 빠르게 반영해야 할 때 유용합니다.
- 반영할 브랜치로 이동
- 가져올 커밋의 해시값 확인
git cherry-pick 커밋해시명령어 실행
cherry-pick을 하면 커밋 이력이 복사되어 새로운 커밋으로 남기 때문에 브랜치 간 직접적인 연결고리는 생기지 않습니다.
주의점
커밋 이력이 단절되므로 어디서 왔는지 추적이 어려울 수 있습니다. 또한 미래 커밋과 충돌이 발생할 수 있고 이러한 경우 직접 충돌을 해결해야 합니다.
Merget, Pull Request
일반적으로는 cherry-pick보다는 브랜치 전체를 merge하는 방식이 더 많이 사용됩니다.
Github 등에서는 Pull Request를 통해 코드 변경을 공유하고, 합의 후 merge로 코드를 통합니다. 여기서 PR은 협업시 검토와 조율을 하기 위해 필수적인 절차입니다.
