Git
깃(git)이란, 컴퓨터 파일의 변경사항을 추적하고 여러명의 사용자들 간에 파일 작업을 조율하기 위한 분산 버전 관리 시스템이다. 소스 코드 관리에 주로 사용된다.
커밋시 주의사항
- 커밋은 '의미 있는 변동사항'을 묶어서 한다.
- 클릭 관련 버그를 고치는데 5가지 파일을 수정했다면, 그 5가지를 묶어서 하나의 커밋으로 만들 것 -> 동료 개발자나 미래의 내가 어떤 파일을 수정했는지 손쉽게 파악이 가능하다.
- 커밋 메세지는 웬만하면 상세하게 적을 것!
자주 사용하는 깃 명령어
프로젝트 폴더에서의 커밋 과정
git init
(git으로 버전관리할 폴더에서 처음 1번 입력 :.git이라는 숨겨진 폴더가 생성된다.)
git add .
(변경파일 모두 add)
git commit -m "커밋메세지"
git remote add origin [저장소 주소]
git push origin master
(master는 브랜치 이름이다. main브랜치일경우 main을 입력해야 한다.)그 외 명령어
git branch "브랜치명"
(새 브랜치를 생성하는 명령어로, 보통 새로운 기능을 추가할때 생성한다.)
git checkout "브랜치명"
(해당 브랜치로 이동)
git merge "브랜치명"
(브랜치 합칠 때 사용, base 브랜치로 이동 후, 합칠 브랜치명을 merge하면 된다.)
중급 명령어
1. amend(마지막 커밋 수정)
깜빡하고 수정 못한 파일이 있을 경우, push하지 않은 기존 커밋상태에 추가 및 변경이 가능하다.
이력을 변경하는 amend와 같은 명령어의 경우, 꼭 혼자쓰는 branch에서 사용해야 한다. 협업중인 branch에서 이 명령어를 사용할 경우 동료의 히스토리까지 꼬이는 대참사가 일어날 수도 있다!
2. stash(변경사항을 보관)
변경사항을 잠시 킵해두고 커밋까지는 만들고 싶지 않을 때 사용한다.
예를들어 a 브랜치에서 작업중에, b 브랜치의 파일 수정요청이 들어왔다고 치자. 이때 b브랜치로 이동해야 하는데 a 브랜치의 작업물들을 커밋하기엔 애매하고 그렇다고 날려버릴수도 없을 때 사용하는 것이다.
다시 a브랜치로 돌아와서 pop해오면 보관했던 파일들을 꺼낼 수 있다.
3. reset(옛날 커밋으로 브랜치를 되돌리고 싶을 때)
보통 커밋은 기능 단위로 묶어서 하게 된다. 예를 들어, 좋아요 기능과 싫어요 기능을 만들었는데 싫어요 기능을 빼고 좋아요 기능까지만 구현해달라는 요청이 들어온 경우! 리셋을 통해 이전 코드로 되돌아갈 수 있다.
reset도 마찬가지로 이력을 변경하는 명령어는 반드시 혼자 쓰는 branch에서만 사용해야 한다.
4. revert(이 커밋의 변경사항을 되돌리고 싶을 때)
리셋과 차이점은, 리셋은 히스토리를 아예 초기화시키는 작업이고 revert는 히스토리를 새로 쌓으면서 변경하는 명령어이다.
reset 하고 force push를 하면 다른 사람들의 히스토리에 영향을 줄 수 있어서, revert로 새로 커밋을 생성하는 경우에 사용한다.
5. cherry-pick(저 커밋 하나만 떼어서 지금 브랜치에 붙이기)
ex) - 어제 릴리즈한 브랜치에 버그가 있어서, 다른 브랜치에서 버그를 고쳐서 master에 일단 머지를 했다.
- master 브랜치에 다른 수정사항도 많아서 latest랑 당장 머지가 불가능한 상태, 그래도 릴리즈된 브랜치에 버그수정 커밋은 들어가야 한다.
- 그래서 고친 코드가 있는 커밋을 릴리즈한 브랜치에 똑! 떼서 붙인다. 이게 바로 체리픽!
포크(Fork)와 브랜치(Branch)의 차이
포크란 저장소를 통째로 복제하는 것으로, 포크와 브랜치는 두가지 모두 협업을 위해 분기점을 나누는 방식이지만 특성이 다르다.
포크(주로 오픈소스 등 다수의 불특정 사람들끼리 협업 시 사용)
- 여러 원격저장소를 만들어 분기를 나눈다
- 원본저장소에 영향을 미치지 않아, 자유롭게 코드 수정이 가능하다
- 원본저장소의 이력을 보려면 따로 주소를 추가해 주어야 한다.
브랜치(주로 작은 팀이나 소규모 프로젝트에서 사용)
- 하나의 원본저장소에서 분기를 나눈다
- 하나의 원본저장소에서 코드 커밋 이력을 편하게 볼 수 있다
- 다수의 사용자가 다수의 브랜치를 만들 시, 관리가 힘들다.
풀 리퀘스트(pull request)
머지(merge, 병합)를 허락해달라는 의미로, 머지하고 싶은 두 브랜치를 선택하고 어떤 변경을 했는지 제목과 내용에 입력한다.
단일 저장소에서 보낼수도 있고, Fork한 저장소에서도 보낼 수 있다.
- 혼자 개발하는 경우가 아니라 협업하는 경우라면 직접 머지를 피하고, 모든 머지를 pull request를 통해서 하는것을 권장한다.
- 동료가 내 풀 리퀘스트(PR)을 보고 코드리뷰를 할 수 있다.
- 동료의 PR에 수정이 필요할 시, 댓글로 change request를 보낼 수 있다.
- 오픈소스에 PR을 보낼 경우, 기여 안내문서(contribution guideling)를 반드시 참고해야 한다.
브랜치 관리 TIP
- 보통
feat/기능이름으로 한 사람이 개발하는 기능 브랜치를 만든다.
(혹은fix/버그이름hotfix/급한버그) - 작업이 끝나면
dev(혹은master) 브랜치로 PR을 보낸다. dev브랜치에서 큼지막한 작업이 모두 머지되면release(혹은latest) 브랜치로 머지시키고 이를 실서버에 배포 한다.- 직접 커밋은
feat(혹은 fix, hofix) 브랜치에만 한다. - dev나 master, release 브랜치에는 직접 커밋이 아닌 머지만 한다.
git flow
Git-flow에는 5가지 종류의 브랜치가 존재합니다. 항상 유지되는 메인 브랜치들(master, develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)이 있습니다.
master : 제품으로 출시될 수 있는 브랜치
develop : 다음 출시 버전을 개발하는 브랜치
feature : 기능을 개발하는 브랜치
release : 이번 출시 버전을 준비하는 브랜치
hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
build: Build related changes (eg: npm related/ adding external dependencies)
chore: A code change that external user won't see (eg: change to .gitignore file or .prettierrc file)
feat: A new feature
fix: A bug fix
docs: Documentation related changes
refactor: A code that neither fix bug nor adds a feature. (eg: You can use this when there is semantic changes like renaming a variable/ function name)
perf: A code that improves performance
style: A code that is related to styling
test: Adding new test or making changes to existing test
feat/기능이름 이런식으로 브랜치를 만들고 머지가 완성되면 feature 브랜치를 삭제하는 식으로 관리하고 있는 것 같은데, 회사마다 다르기에 회사에 맞는 방식으로 깃을 활용하면 될 것 같다.
처음 배울땐 깃이 너무 어렵고, 수없이 많은 에러를 겪으면서 멘탈이 나갔었는데 포기하지 않고 여러 강의도 들어보고 에러메세지도 분석해보고 하니, 이제 git으로 버전관리를 할 때 주의사항들에 대해서 이해가 좀 되고 충돌을 피하는 방법도 얼추 감이 잡히는 것 같다.
앞으로 깃이랑 더 친해져 볼 것이다 ^_^.. 두고보자 포기란 없따
