깃허브에 커밋, 푸시를 하고 브랜치 병합까지

1. 깃허브(Github)

‘깃(Git)’이라는 시스템을 기반으로 만들어진 형상 관리 플랫폼 중 하나입니다
여기서 ‘형상 관리’는 변경 사항을 추적, 제어하는 과정을 의미합니다

대학교에서 과제를 작성하고 ‘최종.ppt’를 썼다가 ‘진짜최종.ppt’를 썼다가 ‘찐찐막최종.ppt’를 썼다가
그런데 이전 버전의 ppt에 있던 자료를 다시 찾아보기도 하고… 이게 코딩으로 넘어간다면 어떻게 될까요
그 무지막지한 코드의 양을 다시 찾아보기도 힘들고 백업을 남기는건 더 힘들지도 모릅니다

하지만 깃허브에서 ‘형상 관리’를 이용한다면 코드를 업데이트하며 간단하게 이전 버전을 다시 찾아볼 수도 있죠
게다가 다른 팀원과의 협력에 있어 누가 어떤 코드를 수정했는지도 알아보기 쉬워집니다

2. 깃허브에 파일을 올릴 때에는

우선 깃허브 저장소(Repository)와 로컬 저장소가 있는데
로컬은 저희가 컴퓨터에서 작업하던 파일들이 있을겁니다, 이것들을 깃허브 저장소에 올려봅시다

$ git status # 로컬에 있는 파일의 변동사항 확인
$ git diff # 수정된 파일의 내용 확인

$ git add . # 깃허브 저장소에 업데이트할 변경된 파일을 목록에 추가 ('.'을 적으면 모든 변경된 파일 적용)
$ git commit -m "새 업데이트" # 깃허브 저장소에 업데이트 할 때 메시지를 추가
$ git push # 깃허브 저장소의 파일 업데이트

보통 status로 변경된 내용이 있는지 확인한 뒤, git add ., git commit -m "", git push를 사용합니다
즉, git에서 ‘커밋(Commit)’하고 ‘푸시(Push)’를 했다고 볼 수 있겠습니다

3. 브랜치(Brunch) 병합

깃허브에서는 ‘Master’보다 ‘Main’이라는 이름의 브랜치를 쓸 것을 권장합니다
사실 차이는 없는데 ‘Master’라는 단어가 주는 주종관계의 뉘앙스 때문이라나 뭐라나…

만약 깃허브를 여럿이서 쓰는 경우면 브런치를 다양하게 쓸 일이 있을겁니다
프로젝트의 전체를 담당하는 ‘main’부터 시작해서 다른 인원들이 일부 파트를 담당하는 브랜치A, 브랜치B 등이 있겠죠

예를 들면 스프링 프로젝트에서 프론트엔드를 작업하는 브랜치와 백엔드를 작업하는 브랜치가 있을 수도 있구요
그리고 각 파트를 완성하면 ‘main’에 업데이트를 해줘야 할겁니다

• 브랜치 조회 및 생성

$ git branch # 모든 로컬 브랜치 목록 보기
$ branch feat/login # 'feat/login'이라는 이름의 새 브랜치 생성
$ branch -d feat/login # 'feat/login'이라는 이름의 브랜치 삭제

• 브랜치 전환

# checkout과 switch 둘 다 사용할 수 있지만 switch가 브랜치 전환에 집중된 명령어기 떄문에 switch로 전환하는걸 권장
# checkout은 브랜치 전환, 파일 체크아웃, 커밋으로 돌아가기 등 다양한 용도로 사용됨
$ git checkout feat/login
$ git switch feat/login

# 브랜치를 생성하면서 바로 전환하기
$ git checkout -d feat/new-design
$ git switch -c feat/new-design

• 브랜치 병합

# 1. 기준이 되는 'main' 브랜치로 이동
$ git switch main

# 2. main 브랜치 위에서 'feat/login' 브랜치를 병합
$ git merge feat/login