여러명의 개발자가 1개의 저장소를 사용하는 환경에서 효과적으로 사용을 하기 위해 나온 개념이다
대표 전략으로는 다음과 같다
브랜치 생성
기능 개발, 버그 수정
Pull Request 생성
리뷰와 논의
공개 및 테스트
합치기 (Merge)
현재 많은 기업의 표준으로 사용하는 브랜치 전략
크게 5개의 브랜치를 운영하여 관리한다.
배포주기가 길고, 팀의 여력이 있는 경우에 권장하는 전략이다.
feature 브랜치는 하나의 새 기능을 만들때 생성하며, develop에 머지 후 삭제한다.
merge 시에 --no-ff
를 사용하여 기록을 그룹화 한다. (만약, 충돌시에 Develop 브랜치로 부터 변경사항을 불러와 수정후 merge)
--no-ff ?
브랜치 전략에서 merge 할 때 사용하는 것을 권장한다. Fast-Forward 관계에 있어도, merge commit을 생성하며 해당 브랜치가 존재하였다는 정보를 남길 수 있다. commit 기록을 되돌리기 편하다. 이 기능을 사용하지 않는다면, 브랜치 존재 여부를 알 수 없어, 어떤 commit에서 해당 기능을 구현했는지 알기가 어렵다.
다음 버전을 출시하기 위해 QA를 진행하는 브랜치. 버그 수정 및 버전 번호, 빌드 날짜와 같은 메타데이터를 준비하며, 기능 개발은 금지된다. merge 시에 --no-ff 사용. Master로 머지 후에 tag
명령을 통해 버전을 명시한다.
Production에 버그가 발생시, 빠른 수정을 위해 생성하는 브랜치이다. Production 코드를 수정하는 중에도, develop 에서는 계속 개발이 가능 Master로 머지 후, tag 명령을 통해, 이전버전 보다 높은 버전을 명시함(e.g. 1.2 -> 1.2.1)
깃을 사용하다보면 커밋한 내용을 되돌려야 하는 경우가 있습니다. 이때 사용할 수 있는 명령어로 reset, revert
가 존재하는데 이번에는 revert
키워드를 살펴보겠습니다.
revert
는 이전 커밋 내역을 그대로 남겨둔 채 새로운 커밋을 생성합니다. 내역을 남겨주므로, 어떤 커밋을 삭제했는지 알 수 있는 장점이 있습니다.
위 사진과 같이 작동한다. 이렇게 하는 이유는 다음과 같다.
만약 A-B-C 까지 작업을하고(B 뒤에 더 많이 작업을 하는 경우도 충분히 많겠지만 간단히 하면) B만 딱 지우려고 할때 reset
을 사용한다면, B 이후 커밋들은 삭제가 됩니다. 이렇게 딱 하나의 커밋만 삭제하고 싶을 때 유용하게 사용할 수 있습니다.
추가적으로, 브랜치를 합칠 때에는, 합칠 대상으로 Switch 후에 해야한다.
참조
https://www.youtube.com/watch?v=wtsr5keXUyE
https://www.becomebetterprogrammer.com/git-revert-last-commit/