이번주는 HA라는 이떄까지의 배운것을 시험보는 시간이 있기 떄문에

일단 기본적으로 내가 배운 이론적인 내용을 오늘안에 모두 다시 정리해볼 생각이다.

그리고 내일은 클론코딩을 통해서 css 및 React를 다시 해볼 것이고

그 다음날은 HA를 준비하기 위해 진행한 스프린트를 훑어 볼 것이다.

• 시간이 남으면 또 클론 코딩 또는 개인공부를 할 것 같다.

화이팅티이팅티

Git Branch

모두가 알다 시피 Git은 개발자들이 협업하는데에 필요한 툴이다.

개발자들은 개개발을 할떄에 동일한 소스코드를 함께 공유하고 다루게 된다.

• 동일한 코드 안에 버그를 수정 또는 새로운 기능을 만들어 낸다.

하지만 동일한 코드로 작업을 하기 떄문에 시간이 경과함에 따라서 서로 다른 버전의 코드가 만들어 질 수 밖에 없다.

• 이러한 점을 보완하기 위해서 있는 것이 브랜치(Branch)라고 한다.

브랜치(Branch)

독립적으로 어떤 작업을 진행하기 위한 개념이다.

개발을 하다보면 한 페이지 안의 여러 기능을 따로 구현하기 위해, 코드를 여러 개로 복사해야 하는 일이 자주 생기게 된다.

• 하지만 브랜치의 기능을 활용하면 코드를 통째로 복사한 후 원래 코드가 변경될 우려 없이 독립적으로 개발이 가능하다

즉 각각의 브랜치는 다른 브랜치의 영향을 받지 않는다.

브랜치의 장점
1. 한 소스코드에서 동시에 다양한 작업을 할 수 있게 해준다.
2. 소스코드의 한 시점과 동일한 상태를 만들고 브랜치를 넘나들며 작업 가능
3. 각각의 브랜치는 독립적으로 존재한다.

우리가 github 레파지토리를 보면 Main, Master 이라는 브랜치를 볼수가 있을 것이다.

이러한 통합 브랜치를 베이스로 두고 다른 브랜치들

• hotfix, release, develop 등등

에서 각각 필요한 작업을 하는 것이다.

• 이러한 분리된 브랜치 에서는 각자 독립적인 작업 영역을 가지고 입맛에 맞게 코드를 변경할수가 있다.

이후 작업이 완료되면 병합을 합으로써 다시 새로운 하나의 브랜치로 모을 수 있다.

여러명에서 작업을 하는 상황을 예로 들어 설명을 해보겠다.

main이라는 브랜치에 우리가 작업을 소스코드를 둔다.

A는 hotfix라는 브랜치에 소스코드를 복사한뒤 작업을 하고
B는 develop라는 브랜치에 소스코드를 복사한뒤 작업을 하게 된다.

이후의 사람들도 각자 브랜치를 하나 담당하여 작업을 진행한다.

만약 일정 시간이 지나고 우리가 특정 작업을 마무리 해서 병합을 해야 하는 시기가 온다면

브랜치에 있는 코드를 하나하나 병합을 한뒤 테스트후 main이라는 통합 브랜치에 저장을 한다.

브렌치의 종류에 대해서 설명을 하면

통합 브랜치
- 배포될 소스코드가 기록 되어 있는 브랜치
- 기본적으로 main브랜치가 해당이 된다(master인 경우도 잇다.)

피처 브랜치
- 각자 개인 또는 팀이 맡아서 작업할 브랜치를 말한다.
- 통합 브랜치에 있는 코드를 복사하여 만들어 지며 후에 병합에 사용 된다.

브랜치 명령어 모음

git branch 새로운 브렌치 이름
- 새로운 브랜치를 생성한다.

git branch
- 브랜치 목롱을 확인

git branch - v
- 브랜치 목록과 각 브랜치의 최근 커밋을 확인

git checkout 브랜치 이름
- 브랜치 전환

git checkout -c 브랜치 이름
- 새로운 브랜치를 생성후 해당 브랜치로 전환
- 즉 생성과 브랜치 이동을 동시에 한다.

브랜치 병합( master브랜치로 dev브랜치를 병합할떄)
1. git checkout master
2. git merge dev

git stash
- 아직 커밋을 하지 않은 작업을 스택에 임시 저장

프로젝트 workflow

기본적으로 개발을 진행하는 과정에서는 main이 아닌 dev라는 브랜치를 만들어 작업을 하는 경우가 많다.

• git checkout -b dev

그후 생선한 브랜치에 코드를 넣어주어야 하기 떄문에

• git push origin dev

이후 만약 로그인 기능을 구현하고자 한다면

• git checkout -b feature/login
  그리고 똑같이 push해주면 된다.

이후 로그인 기능이 구현이 되고 그후 소셜 로그인 까지 구현을 하고자 하며 소스코드를 건드리자니 위험 부담이 있기 떄문에 새로운 브랜치를 만들다고 가정을 하자

• git checkout -b feature/login-oauth
  그리고 똑같이 push해준다

그리고 우리는 모든 기능 구현이 완료 되었기 떄문에 병합을 해주어야 한다.
그러기 위해서는 일단 병합의 주체가 되는 브랜치로 이동을 해야 한다.

• git checkout feature/login

이렇게 이동후에 병합을 진행한다.

• git merge feature/login-oauth

이떄 한가지 알아 두어야 하는 점이 login브랜치에 추가 커밋이 있다 없다로 방식이 달라지는 점이다.

만약 login에서 oauth로 코드를 복사 한후에도 login의 소스코드에 변환가 있었다면 merge commit방식으로 병합이 되며

만약 login의 소스코드에 변화가 없엇다면
fast-forward방식으로 병합이 이루어 진다.

이것을 따른 말로는 rebase와 merge의 차이라고도 한다

면접 주요 질문중 하나!!

merge와 rebase의 차이점에 대한 내용이다.

rebase의 원리는 앞서 말한 fast-forward와 같다.

merge같은 경우에는 변경 내용의 이력이 모두 그대로 남아 있기 떄문에 이력이 복잡해 지지만

rebase는 말 그대로 branch base를 이동 시킨다는 뜻으로 브랜치 통합을 목적으로 하지만 특정 시점으로 브랜치가 가리키는 곳을 변경하는 기능을 뜻한다.

만약 git rebase main feature/login이라는 명령어를 사용 하게 되면
main의 가장 최신 커밋으로 브랜치가 변경이 된다.

이후 모든 작업이 끝나게 되면 push하게 되고 dev브랜치 에서 반영을 해주어야 한다.

• 이 부분은 github의 pull request를 허가해 줌으로써 할 수가 있다.

• 앞서 글로 설명한 부분에 대한 전체적인 흐름도 이다.

rebase에 대한 추가 설명

개인적으로 rebase명령어가 잘 이해가 되지 않아서 구글링을 통해 추가 학습을 하였다.

링크 : https://flyingsquirrel.medium.com/git-rebase-하는-방법-ce6816fa859d

일단 우리가 특정 브랜치로 a로 b라는 브랜치를 병합 한다고 생각을 해보자

두가지 선택사항이 있을 것이다.(merge, rebase)

merge같은 경우에는 b라는 브랜치에서 커밋한 내용이 모두 a라는 브랜치에 기록이 남게 된다.

• 즉 기록이 공유된다 라고 생각을 하자

하지만 rebase라는 명령어는 b에서 커밋한 내용중 불필요한 것들은 제외하고 a라는 브랜치의 커밋에 추가가 된다.

• 기록이 공유 되지만 불필요한 기록은 공유되지 않는다

불필요한 기록은 내가 Rebase할떄 삭제를 하면 된다.

대략 내가 3개의 커밋을 남겼다고 생각을 해보자

그후 모든 작업이 완료가 되고 그걸을 origin에 push해주기 전에 불필요한 커밋들을 rebase해줌으로써 깔끔하게 정리된 커밋들만 넘겨 주는 것이다.

git rebase -i @~3

• 최근 3개월의 커밋들을 rebase하겠다는 명령어 있다.

이렇게 3가지의 커밋 활동이 뜨게 된다.

pick f7f3f6d fix typo
pick 310154e wip
pick a5f4a0d bugfix

이 3가지의 커밋 활동중 우리는 bugfix부분의 커밋만 넘겨 주려고 한다면

s f7f3f6d fix typo
s 310154e wip
pick a5f4a0d bugfix

이렇게 pick을 s라는 명령어로 삭제 시켜 주면 된다.

그리고 나면 또다른 vi가 나오게 된다.

# This is a combination of 3 commits.
# The first commit's message is:
fix typo

# This is the 2nd commit message:

wip

# This is the 3rd commit message:

bugfix

이러한 vi에서는 dd를 눌러서 원하지 않는 내용을 삭제 시켜 주어야 한다.
- bugfix만 남기고 싶기 떄문에 bugfix를 제외한 모든 사항을 dd 시켜 삭제 해준다.

그러면 rebase가 완료가 된다.

이렇게 새롭게 알고 나니 rebase는 정말 말 그대로 새롭게 정의 내린다는 의미가 되는 것 같다..

rebase에서 주의할 점은 다른 사람들과 함께 쓰고 있는 브랜치 에서 git push할떄에는 rebase를 쓰지 않는 것이 좋다.

• 다른 사람이 pull하게 되면 엄청난 conflict를 만나게 된다고 한다.
• 그러기 떄문에 정말 깔끔하게 정리하는 용도로만 사용을 하도록 하자