Git Work-flow, Branch

📅 TIL #32

📅 TIL 📝 immersive-course


오늘 페어분은 주말마다 스터디하는 분들 중 주현님이여서 재밌게 진행이 되었다!

오늘은 실제 실무에서 프로젝트할 때 처럼 맛보기(?) 식으로 주현님과 함께 Git 으로 협업하는 과정을 연습해봤다!!

실무에서 일을 해 본적은 없지만 만약 실무에서 실제로 깃을 통해 코드를 계속 업데이트하면서 협업하는 과정이라면, 이런 느낌일 것 같다는 간접적인 체험을 한 기분이 들어서 재밌었다👍👍👍



👉 Git Work-flow


  • 진행과정
    1. 내가 Code States Repo에서 파일을 받고 수정한 뒤에 push를 한다.
    2. 서로 remote add [페어][페어 Repo URL] 을 한다.
    3. 주현님이 내가 수정한 파일을 pull로 받아온다.
    4. 다시 주현님이 수정을하고 Code States Repo에 push를 한다.
    5. 내가 다시 pull로 받아온다.


// 나의 입장에서
$ git clone -> 수정 후 -> add -> commit -> push

$ git remote add pair https://github.com/주현님Repo

$ git remote -v

파일 수정 후 push를 한 뒤 remote -v를 해서 remote가 추가 되었는지 확인한다.


gitWorlflow

이런식으로 된 걸 확인할 수 있다! 🙌



// 주현님 입장에서
$ git remote add pair https://github.com/useonglee/useonglee.github.io

$ git pull pair master


gitWorkflow2


이렇게 하면 서로 수정하고 공유도 할 수 있다!! 앞으로 중요하게 쓰일 것 같은 git 명령어를 배워봤다!



그래서 Git Pull 이란?


다른 사람이 원격 저장소에 업데이트한 파일이 있을 때 원격 저장소와 내 로컬 저장소의 상태를 동일하게 만들기 위해 사용된다.

즉, 리모트 서버의 최신 소스를 가져와서 로컬 소스에 병합 (Merge) 해주는 명령어이다.

만약 우리가 처음 소스를 클론한 후에 다른 사람이 리모트 서버를 상태를 갱신했더라도 리모트 서버가 우리에게 그 변경된 사항을 알려주지는 않기 때문에 우리가 직접 서버에 문의를 날려야 하는 것이다.

또한 pull은 단순히 리모트 서버에서 로컬로 소스를 가져온다의 개념보다는 가져와서 합친다의 개념이기 때문에 브랜치끼리도 pull을 통해 소스를 합칠 수 있다.





👉 Git 충돌(Conflict) 시 해결


컨플릭트는 말 그대로 소스의 충돌이다. 그렇다면 어떻게 했을 때 충돌이 일어나고 충돌이 일어났을 경우, 어떻게 해결할까?

먼저 연습하기 위해 우리는 고의로 충돌상황을 만들어 냈다.

  • 진행과정
    1. 내가 파일의 1번라인 코드를 수정하고 push를 한다.
    2. 주현님이 다시 1번라인 코드를 수정하고 push를 한다.
    3. 내가 다시 git pull pair master를 한다.
    4. 충돌 발생

다음과 같은 사진이 나타날 것이다.


gitWorkflow3


해결 법은?

<<<<<<< HEAD
내가 수정한 부분
=======
주현님이 수정한 부분
>>>>>>> 35058b46325bb61112efd52f4019f907c561328d


vscode를 들어가보면 이렇게 나와있다. ====== 위 아래로 나뉘어진다. 그러면 여기서 둘 다 수정할 것인지 하나만 수정할 것인지, 또는 다 지울 것인지를 결정하여 수정해주면 된다.

그 후 add 부터 다시 해주고 push를 해주면 해결!


그러면 이러한 현상이 나타나는 이유는?


gitConflict 출처


git은 최신 소스를 알려주지 않기 때문에 주기적으로 pull로 가져와서 내 로컬 브랜치에 병합을 해야하는데, 그 경우에 충돌이 일어난 것이다.

충돌 현상은 push가 아니라 pull을 했을 때 발생한다.

나도 push를 했고 주현님도 push를 한 상태에서 내가 다시 pull로 가져오니까 충돌이 발생했다.





Branch


branch


$ git checkout 브랜치1


을 입력하면 브랜치를 이동할 수 있다.



그렇다면 브랜치가 없는 상태일 때는 어떻게 해야할까?

branch2

// 브랜치를 만든다
$ git branch 기능1

// 생성한 브랜치로 이동한다
$ git checkout 기능1

이렇게 할 수 도 있지만, 한 번에 해결도 가능하다.


$ git checkout -b 기능1

checkout -b를 사용하면 브랜치를 생성하면서 그 브랜치로 작업공간을 이동한다. 때에 따라서 적절히 잘 사용하면 될 것 같다!



rebase


리베이스는 합치는 것이 아니라 말그대로 브랜치의 베이스를 변경하는 것이다.


$ git checkout Feature
$ git rebase master

rebase


리베이스의 장점은 바로 깔끔한 커밋 히스토리를 만들어 준다는 것이다. 머지 커밋이 남지 않고 애초에 master에서 수정한 것 마냥 히스토리가 남기 때문에 깔끔하게 일자로 쭉 떨어지는 정렬된 히스토리를 볼 수 있다.




이렇게 오늘 배운 git에 대해서 정리해보았다. git은 알면 알수록 어려운 세계이면서도 정말 중요하고 신기하게 여겨진다. 그래서 실무에서 잘 활용하기 위해 틈틈히 Git공부를 해야겠다

어제 오늘은 이머시브에서 프로젝트를 하고 과제를 하기 위한 기본 셋팅을 한 것 같다.

내일부터는 본격적으로 코드를 작성하는 시간이 있는 것 같다.



👊 내일의 TIW(today I Will)

node.js , CommonJS

← Previous Post Next Post →