[FE_Bootcamp] Pre-Project_Git Flow

이번주부터 본격적으로 Pre-Project가 시작되었다.

첫날은 가장 중요한 버전 관리 툴인 git과 github을 다루는 방법에 대해 배웠다. 

지금까지 프로젝트를 포크하고 클론 하는 방법만 배웠었는데, 막상 직접 레포지토리를 만들고 pull, push 해보려니 난관이 많았다,,.,,

---

1. git 레포지토리 만들고 remote 하기

이미 만들어져 있는 레포지토리(이하 레포)라면 clone을 하면 되겠지만, 프로젝트는 아예 처음부터 만들어야 하기 때문에 레포를 먼저 만들고 터미널에서 remote 하여 로컬 환경과 연결하는 방법을 사용했다.

 

원격 환경과 로컬 환경

 

원격 환경을 만들기 위해 먼저 git에 새로운 레포를 만들어 보자.

 

 

외부에 공개하는 것이 아니라 일단 깃허브 사용 연습을 하는 것이기 때문에 private로 만들었다.

필요한 경우 readme.md 파일이나 gitignore, license 등의 설정을 해준다.

나는 아무것도 모르므로,.,.,.

 

 

다음과 같은 화면이 나오면 레포가 정상적으로 생성된 것이다.

여기서 다른 화면을 만지지 말고, 터미널로 넘어가보자

 

 

새로운 폴더를 생성해준 뒤, 해당 폴더로 넘어가 현재 git 화면에 나와있는 명령어들을 그대로 쳐준다.

사실 git remote ... 부터 해도 무방하지만, 이미 수차례 git에게 당한 나는 그냥 나오는 것들을 모두 써주곤 한다,.,.,.,

remote는 말했다시피 '원격 저장소와 로컬 저장소를 연결하는' 행위로, add 뒤의 origin은 원격 저장소의 이름을 지정해주는 것이다.

 

git remote -v

 

라는 커맨드를 입력해주면 현재 로컬 레포와 연결되어있는 원격 레포를 알 수 있다.

 

 

이렇게 리모트한 레포가 뜬다면 OK

 

---

2. Branch 생성과 이동

브랜칭(branching)은 기존 개발 중인 메인 개발 코드를 그대로 복사하여 새로운 기능 개발을 메인 개발 코드를 건드리지 않고 할 수 있는 버전 관리 기법이다. 처음에 GitHub Repository를 생성하면 나오는 main 브랜치에서만 작업을 하다가 새로운 기능 개발을 위해 feature 브랜치를 새로 생성하는 경우, 기존 main 브랜치에서의 작업은 유지하고 새로운 feature 브랜치에서 자유롭게 코드를 추가 및 삭제할 수 있다.

 

쉽게말해, 원본을 건들지 않고 사본을 이용해 작업을 한 뒤, 작업이 완료되면 원본에 추가하는 형식이다.

 

브랜칭

 

브랜칭을 위해서는, 먼저 브랜치를 만들어야 한다.

현재 만들어져있는 브랜치 확인은 

 

git branch -r

 

커맨드로 확인 가능하다.

 

브랜치는 터미널에서 만드는 방법과 원격 레포에서 만드는 방법 2개가 있는데,먼저 터미널에서 만드는 방법은

 

git switch -c 브랜치명

 

이렇게 입력해주면 된다.

 

 

원격 레포에서 만드는 방법은 메인 화면의 브랜치를 눌러 전체 브랜치 보기로 들어간 다음

 

 

우상단의 New Branch를 통해 만들어주면 된다.

그림과 같이 sub라는 브랜치를 만들어보자.

 

 

이렇게 브랜치가 만들어졌다면 성공. 

위에 적어둔 git branch -r 명령어로 브랜치를 확인해보자.

 

 

어라라?

분명 sub 브랜치를 만들었는데 없다고 나온다.

 

다행히도, 이는 정상적인 현상이다. 

우리는 브랜치를 만들기만 하고 만들어진 브랜치를 로컬 환경에 업데이트 해주지 않았기 때문에 만든 브랜치가 안뜨는 것은 당연한 일인 것이다.

 

git remote update

 

코드를 입력해 로컬 저장소를 업데이트 하고 다시 브랜치를 확인해보자.

 

 

업데이트를 하니 잘 나오고 있다.

이번에는 브랜치를 옮겨가 보자. 

원래는 chekout 명령어로 브랜치 이동이 가능했으나, checkout의 과로(?) 문제로 switch 명령어를 이용한다고 한다.

 

git switch sub
git branch

 

switch로 이동했다면, branch 명령어로 현재 브랜치를 확인할 수 있다.

 

 

무사히 sub 브랜치에 안착했다.

---

3. Pull과 Push

이번에는 sub 브랜치와 로컬 저장소에 main 브랜치의 내용물을 가져와보자.

 

 

이해를 돕기 위해 main 브랜치에 helloworld.html 파일을 넣어 두었다.

 

 

현재 우리는 sub 브랜치에 위치해 있는 상황.

 

git pull origin main

 

remote 단계에서 원격 저장소의 이름을 origin이라 해주었으므로, origin의 main 브랜치를 로컬 저장소로 pull 해오자

 

 

pull을 해오니 로컬 저장소에 helloworld.html 파일이 생긴 것을 볼 수 있다.

 

이제 이 helloworld.html 파일을 우리가 원하는대로 수정한 뒤, sub 브랜치에 push해보자.

 

 

자, 현재 우리의 작업물은 로컬 저장소를 떠나 원격 저장소의 sub 브랜치에 저장되어 있는 상태.

그렇다면 main 브랜치를 pull해왔으니 수정한 내용이 main 브랜치에도 자동으로 반영 되어있을까?

main 브랜치의 helloworld.html

 

sub 브랜치의 helloworld.html

 

그렇지는 않다. 애초에 우리가 sub 브랜치를 만든 이유가 main 브랜치에 잘못된 코드를 집어넣는 것을 방지하기 위해 만든 것인데, 이게 자동으로 병합된다면 sub 브랜치를 만들 필요가 없기 때문!

 

따라서, 우리는 Pull Request(PR)를 날려 sub 브랜치의 수정사항을 main 브랜치에 병합해도 되는지 허락을 구해야 한다.

 

 

원격 레포로 돌아가보면, 이렇게 main 브랜치와 sub 브랜치를 비교하여 PR을 날리라고 아주 친절히 나와있다.

 

 

자세히 보면, sub 레포에서 main 레포로 pull하며 병합이 가능하다고 나와있다.

아래에는 수정사항의 제목과 내용을 적어주고 PR을 날려준다.

 

 

만약 문제없이 PR이 날아갔다면, 이렇게 세부 정보 확인과 함께 main 브랜치에 병합 할것인지 묻는 창이 뜬다.

개인 프로젝트라면 상관없지만, 팀 프로젝트라면 일단 PR을 날린 뒤 팀원들과 코드 리뷰를 하거나, 변경사항을 꼼꼼히 검토한 후 문제가 없다면 병합하도록 하자.

 

만약 코드 충돌이 일어나 병합이 불가능한 경우에는 직접 코드를 수정해야 하는 번거로움이 생길 수 있다.

 

 

병합이 무사히 완료되었다면 PR이 닫히고

 

 

main 브랜치에도 sub 브랜치의 수정사항이 반영된다.

---

후,.,.,.이거 하다가 수명 5일은 깎인 것 같다,.,.,

반드시 기억할 것은 update와 pull!!

update를 안하면 원격 저장소의 변경사항이 반영되지 않고, pull을 안하면 변경된 파일이나 코드들을 받아올 수 없어 충돌이 일어날 수 있다.

온갖 시행착오를 겪으며 알아낸 것이니 이 글을 읽는 분들은 Booddy,.,.,.,.