[패스트캠퍼스] 김민태의 프론트엔드 데브캠프 2기 첫 번째 섹션: Git&GitHub
여든 아홉 번째 포스팅
안녕하세요! 여든 아홉 번째 포스팅으로 찾아뵙게 되어 반갑습니다!♥
오늘의 포스팅 내용은 [패스트캠퍼스] 김민태의 프론트엔드 데브캠프 2기 첫 번째 섹션: Git&GitHub에 관한 내용입니다.
자세한 내용을 알아보러 갑시다❗️
[Boongranii] Here We Go 🔥
1️⃣ Git이란?
🍞 Git이 뭔가요
Git은 분산 버전 관리 시스템(DVCS:Distributed Version Control System)으로, 2005년 리누스 토르발스에 의해 개발되었다. Git은 소프트웨어 개발 프로젝트의 소스 코드 변경사항을 추적하고 관리하는 데 사용된다.
🍞 Git의 3가지 상태
Git은 파일을 세 가지의 주요 상태로 관리한다.
- Modified: 이는 파일이 변경되었지만 아직 로컬에 커밋되지 않은 상태를 말한다.
- Staged: 현재 수정된 파일을 다음 커밋에 포함하도록 표시한 상태를 말한다.
- Committed: 데이터가 로컬 DB에 저장된 상태를 말한다.
2️⃣ Git 시작하기
자, 이제 Git에 대해 가볍게 알아보았으니 사용하며 익혀보자.
Git을 시작하는 것은 아주 간단하다. Git 설치부터 커밋까지의 과정을 설명해보도록 하겠다.
🥚 Git 설치하기
운영 체제에 따라 Git 설치 방법이 다르다. 하지만 필자는 Windows를 사용하기 때문에 Windows설치방법만 설명하도록 하겠다.
- [Git 공식 홈페이지]에서 설치 프로그램을 다운로드한다.
- 다운로드한 설치 프로그램을 실행하고 안내에 따라 설치를 완료한다.
- 설치 과정에서 “Git Bash” 옵션을 택하면 CLI 도구를 사용할 수 있다.
필자는 CLI를 사용할 때는 “Git Bash”를 사용한다. 하지만, VS Code에서의 GUI로 대부분 커밋하곤 한다. 하지만, 김민태 강사님께서는 GUI보다는 CLI의 방법을 통해 연습하는 것이 좋다고 한다.
CLI도 모르는데 GUI를 선뜻 접했다가 프로그램이 변경되면 작업이 어려워질 수 있기 때문이다.
나도 이에 동의한다. CLI도 모르면서 무작정 GUI로만 커밋 과정을 진행하는 것은 무지하다고 생각한다.
🥚 Git 설정하기
Git을 설치한 지 정말 오래되어서 이 과정을 했는지 기억이 잘 나지 않는다. 하지만, 찾아서 작성해본다.
Git을 설치 후, 사용자 정보를 설정해야 한다. 이는 커밋에 서명할 때 사용된다.
🍩 사용자 이름 설정
1
git config --global user.name "Name"
🍩 이메일 주소 설정
1
git config --global user.name "email@email.com"
🍩 설정 확인
1
git config --list
위와 같은 명령어를 통해서 설정을 이뤄낼 수 있다.
3️⃣ Git 저장소 만들기
자 이제 저장소를 만들어보자. Git 저장소를 만드는 방법은 크게 두 가지가 존재한다.
🍩 새 저장소 초기화
기존 저장소를 클론하는 것이 아닌 로컬에 있는 저장소를 초기화하는 것이다.
1
cd your_project_path
저장소 초기화를 원하는 디렉토리로 이동 후
1
git init
위 명령어를 통해 .git이라는 숨김 폴더를 생성한다. 이 폴더에 Git이 프로젝트의 모든 변경사항과 히스토리를 저장하게 된다.
🍩 기존 저장소 클론
1
git clone https://github.com/username/repository.git
원하는 프로젝트를 복사하거나 기존의 Git 저장소의 로컬 버전을 만들고 싶을 때 위와 같은 명령어를 사용해 현재 디렉토리에 복제할 수 있다.
4️⃣ 커밋을 해보자
자, 이제 드디어 커밋을 한다. 드디어라고 해서 거창한 것은 아니고 정말 간단하다.
커밋은 Git에서 변경사항의 스냅샷을 저장하는 기본 단위를 말한다.
🍩 프로젝트에 파일 추가
먼저 Git이 초기화된 프로젝트에서 자신이 커밋하고 싶은 파일을 작성한다. 이를 hello.txt라고 하자.
🍩 변경사항 스테이징
1
git add hello.txt
hello.txt라는 파일만 스테이징하고 싶다면 위와 같이 하면 되지만, 여러 파일을 한꺼번에 스테이징 하고 싶다?
1
git add .
add 뒤에 .을 붙여 모든 변경사항을 스테이징을 할 수 있다.
🍩 커밋하기
1
git commit -m "feat: add hello.txt"
위와 같이 커밋 메시지를 작성하여 커밋을 할 수 있다.
5️⃣ 변경사항 되돌리기
개발과정에서 실수로 잘못된 변경을 하거나 이전 상태로 돌아가고 싶다면?
걱정 말아라. Git에서는 다양한 방법으로 변경사항을 되돌릴 수 있다.
🍩 워킹 디렉토리의 변경사항 되돌리기
1
git checkout -- filename
워킹 디렉토리의 변경사항을 되돌린다. 즉, 아직 스테이징되거나 커밋되지 않은 변경사항을 취소할 수 있다.
--는 현재 브랜치를 의미한다.
🍩 스테이징된 변경사항 되돌리기
1
git reset HEAD filename
위 명령어는 스테이징 영역에서 파일을 제거하는 역할일 뿐이며, 워킹 디렉토리의 변경사항은 유지하는 것이다.
HEAD는 현재 브랜치의 마지막 커밋을 가리킨다.
위 명령 후, 필요하다면 다시 git add로 스테이징 하면 된다.
🍩 마지막 커밋 수정하기
1
git commit --amend
위 명령어로 가장 최근의 커밋을 수정할 수 있다. 보통 커밋 메시지를 변경할 때 사용하며, 마지막 커밋에 새 변경사항을 추가하고 싶을 때 사용한다.
🍩 특정 커밋으로 되돌리기
1
git revert commit-hash
위 명령어로 지정한 커밋의 변경사항을 취소하는 새로운 커밋을 만들 수 있다.
commit-hash는 커밋의 해시값을 나타낸다.
1
git revert HEAD^
이는 제일 마지막 커밋을 되돌리는 것이다.
하지만 주의할 점이 있다.
revert는 되돌리는 과정에서 충돌이 발생할 수 있고, 이 경우에는 수동으로 해결해야 한다.
6️⃣ 브랜치 생성 및 관리
브랜치는 나뭇가지처럼 main의 중심이 되는 나뭇가지에서 또 다른 나뭇가지를 치는 듯한 데에서 비롯한 용어이다.
브랜치는 독립적인 작업을 만들 때 사용한다.
🍩 브랜치 생성
1
git branch branch_name
branch를 통해 새로운 브랜치를 생성할 수 있다.
🍩 브랜치 변경
1
git checkout branch_name
원하는 branch_name으로 이동한다.
브랜치 생성과 변경을 한 번에 가능기도 하다.
1
git checkout -b branch_name
필자도 보통 이렇게 사용한다. 간단하니까.
🍩 브랜치 목록 확인
1
git branch
🍩 브랜치 삭제
1
git branch -d branch_name
원하는 브랜치도 삭제가 가능하다.
7️⃣ 브랜치 병합
브랜치 병합은 팀 협업을 하며 중요한 작업이다. 서로 다른 브랜치의 작업 내용을 하나로 통합하는 과정이기 때문이다.
🍮 기본 병합
🍩 병합이 될 브랜치로 전환
1
git checkout main
병합의 대상이 될 브랜치로 이동한다. 여기서는 main이다.
🍩 브랜치 병합
1
git merge branch_name
branch_name의 변경사항을 현재 브랜치인 main에 통합한다.
🍮 병합 유형
병합 유형도 존재한다. 크게 두 가지가 존재한다.
- Fast-forward 병합
- 현재 브랜치가 병합할 브랜치의 직접적인 상위에 있을 때 발생한다.
- 단순히 현재 브랜치의 포인터를 병합할 브랜치의 마지막 커밋으로 이동한다.
- 별도의 병합 커밋을 생성하지 않는다.
- 3-way 병합
- 두 브랜치가 서로 다른 커밋을 가리키고 있을 때 발생한다.
- 공통 조상 커밋과 각 브랜치의 마지막 커밋을 비교하여 새로운 커밋을 생성한다.
- 병합 커밋은 두 브랜치의 변경사항을 모두 포함한다.
어떤 병합 유형이 더 자주 사용되나?
이는 프로젝트의 워크플로우나 브랜칭 전략에 따라 다르다.
Fast-forward 병합은 간단한 선형 히스토리를 만들지만, 브랜치의 존재 흔적을 남기지 않는다.
3-way 병합은 브랜치의 히스토리를 보존하고, 각 기능이나 작업이 언제 병합되었는지 명확히 보여준다.
두 방법들은 정말 기업마다 프로젝트마다 팀마다 다른 방법이 사용되는 것 같다.
🍮 충돌 해결하기
협업을 하다보면 각자 브랜치에서 작업을 진행하다가 병합 과정에서 충돌이 발생할 수 있다. 각 브랜치에서 같은 파일의 같은 부분을 다르게 수정했을 때 발생하는 것이다.
병합 실행 후 “CONFLICT” 메시지가 출력된다면 충돌이 발생한 것이다.
발생 후 충돌 발생한 파일을 오픈하면 다음과 같이 확인할 수 있다.
1
2
3
4
5
<<<<<<< HEAD
현재 브랜치의 내용
=======
병합하려는 브랜치의 내용
>>>>>>> feature-branch
충돌 부분을 수동으로 편집해 유지할 내용만 남기고 구분자를 제거하면 된다.
1
2
3
git add 충돌_해결된_파일
git commit -m "commit_message"
충돌을 해결하고 스테이징 후 커밋을 완료하면 병합이 완료된다.
🍮 병합 취소하기
병합 과정에서 문제가 발생해서 병합을 취소하고 싶을 수 있다.
🍩 병합 전 상태로 되돌리기
1
git merge --abort
위 명령어를 통해 병합 시작 전의 상태로 워킹 디렉토리를 되돌릴 수 있다.
🍩 이미 병합이 완료된 경우
1
git reset --hard ORIG_HEAD
위 명령어로 병합 직전의 커밋으로 브랜치를 되돌릴 수 있다.
병합 과정에서 실패하더라도 위와 같은 명령어로 병합을 취소할 수 있게 된다.
8️⃣ 고급 기능
🍔 Rebase
Rebase는 한 브랜치의 변경사항을 다른 브랜치에 적용해주는 명령어이다. Merge와 비슷한 결과를 얻지만 커밋 히스토리를 더 깔끔하게 만들 수 있다.
1
2
git checkout another_branch
git rebase main
another_branch의 변경사항을 main 브랜치의 최신 커밋 위에 재배치하도록 한다.
1
git rebase -i HEAD~n
HEAD를 통해서 n개의 커밋을 수정, 결합, 삭제, 순서 변경 등을 할 수 있다.
Rebase는 선형적이고 깔끔한 프로젝트 히스토리를 유지하며 불필요한 병합커밋을 제거할 수 있는 장점이 있다.
하지만, 이미 공개된 브랜치에 대해 사용 시 문제가 발생할 수 있으며 충돌 해결이 더 복잡할 수 있다는 단점이 존재한다.
🍔 Stash
Stash는 작업 중인 변경사항을 임시로 저장하고, 다음에 불러와 적용할 수 있도록 해주는 명령어이다.
🍩 현재 변경사항 스태시에 저장
1
git stash
🍩 스태시 목록 확인
1
git stash list
🍩 가장 최근 스태시 적용
1
git stash pop
위와 같이 Stash를 사용할 수 있다. Stash는 다른 브랜치로 전환 후 작업 내용을 불러와 작업을 하고 싶지만 현재 작업을 커밋하고 싶지 않을 때 사용하면 매우 유용하다.
필자는 Rebase는 사용해본 적이 없지만 Stash는 협업 시에 항시적으로 사용한다.
결론적으로, Rebase와 Stash는 효율적인 작업 관리와 깔끔한 프로젝트 히스토리 유지에 도움을 준다. 이 기능을 적절히 활용해서 더 효과적인 버전 관리가 가능하다.
9️⃣ Git 브랜치 운영 전략
효과적인 Git 사용을 위해서 적절한 브랜치 전략을 택하는 것도 중요하다.
ATLASSIAN를 보면 브랜치 전략들이 잘 설명되어 있다.
🍧 Git Flow 전략
Gitflow는 체계적이고 엄격한 워크플로우를 제공한다.
- main: 안정적인 애플리케이션을 반영한다.
- develop: 개발 작업의 기반이 되는 브랜치
- feature: 새로운 기능 개발을 위한 브랜치
- release: 출시 준비를 위한 브랜치
- hotfix: 긴급 버그 수정을 위한 브랜치
위 외에도 여러가지로 만들 수 있다.
Gitflow의 장점은 체계적인 버전 관리이며 대규모 프로젝트에 적합하다. 하지만 어떤 부서는 빈번한 릴리즈를 통해 계속 관리를 해주어야 하기 때문에 복잡하고 부적합할 수 있다.
🍧 GitHub Flow
GitHub Flow는 Gitflow보다 단순화된 모델로, 지속적인 배포에 적합하다.
Pull Request를 통한 코드리뷰를하며, main브랜치로 병합 후 즉시 배포를 한다.
빠른 배포 주기에 적합하며 CI/CD와의 높은 호환성이 장점인 반면, 버전 관리가 어려우며 대규모 프로젝트에서 복잡성이 높을 가능성의 단점이 있다.
🍧 Forking Workflow
이 전략은 주로 오픈 소스 프로젝트에서 사용되는 전략이다.
오픈 소스 프로젝트를 자신의 레포지토리로 포크해와 로컬에서 변경 사항을 작업한 후 원본 저장소에 PR을 제출하면 된다.
이는 오픈 소스 프로젝트에 매우 이상적이며 중앙 저장소의 안정성을 유지할 수 있다는 장점이 있다.
🍧 선택 기준
- 프로젝트의 규모와 복잡성
- 팀의 규모와 협업 방식
- 배포 주기
- 제품의 특성
위 사항 외에도 고려할 점이 존재할 수 있다.
중요한 것은 팀과 프로젝트에 가장 적합한 전략을 선택하고, 필요에 따라 유연하게 조정하는 것이다. 최근에는 Gitflow의 복잡성을 피하고 GitHub Flow의 단순성을 채택하는 추세가 있지만, 각 프로젝트의 요구사항에 따라 최적의 전략은 달라질 수 있다.
🔟 느낀점
첫 섹션이었던 “Git & GitHub”이 끝났다. 평소에 커밋, 협업을 하며 Git 명령어를 자주 사용해 익숙한 내용이었다.
하지만 위 내용 외에도 Git에 대해서 더욱 디테일하게 그림을 통해 학습하니 더 이해가 잘 되기도 했고 모르는 개념도 학습할 수 있던 섹션이었다.
되도록 CLI를 사용하라고 하시는데 급한 프로젝트가 아니라면 되도록 손에 익도록 써보려고 노력해야겠다💪
댓글남기기