기능 개발 : feature/login, feature/selecet-product
출시 준비 : release-1.3, release-1.4
긴급 수정 : hotfix-1.2.1
저번 글에서 작성하지 못했던 것이 있는데, 브랜치를 만드는 법에 대해서는 설명했지만, 브랜치를 삭제하는 방법에 대해서는 제대로 말하지 못하였다.
그래서!
브랜치를 만들었는데, 오타가 났거나 삭제하고 싶은 브랜치가 있다면
git branch -d [해당브랜치이름]
ex)git branch -d dev
이런식으로 해주면 된다.
만약 브랜치를 거실브랜치과 화장실브랜치를 만들었어.
이 두개를 따로 관리할 수 있다는 거니까, 코드도 서로 달라야겠지?
그래서 거실브랜치에 위치하고, 막 작업을 해. 수정하고 추가하고 해.
그런 다음 화장실 브랜치로 가면 내가 작업했던 거실브랜치의 코드들이 사라지고 화장실 브랜치의 코드들만 보일까?
바로는 안보여!
왜냐하면 브랜치는 커밋을 하기 전까지 수정한 코드들을 인정해주지 않기 때문에, 커밋을 하기전까지는 각 브랜치를 옮겨도 내가 수정한 것처럼 보이게 될거야. 그렇기에, 수정을 했고, 각 브랜치마다 관리를 해주고 싶다면, 수정한 후 꼭 커밋! 까지 해주기!
거실브랜치에서 수정한 코드들을 커밋을 하고 화장실브랜치로 가면 내가 거실브랜치에서 수정한 코드들은 사라져서 안보일거야.
그래서 가장 중요한 것이 거실브랜치에서 작업을 하다가 커밋하기 전에, 화장실 브랜치로 옮겼어 브랜치를.
그럼 아직 코드들이야 잘 있겠지? 그럼 화장실에서 브랜치에서 모르고 커밋을 해버렸어.
그럼 거실브랜치코드들이 화장실 브랜치에 들어가버린거야. 그럼 다시 삭제하거나 수정한 부분을 다시 너의 기억으로 되돌려놓고 다시 커밋해서 화장실브랜치를 되돌려놓고, 다시 그 코드들을 거실브랜치에서 다시 작성해서 다시 커밋을 하면 돼.
그럼 많이 귀찮고 빡세겠지? 그래서 커밋할땐 정말 주의해서 해야해.
그리고 아까 브랜치를 새로 만든다고 해서, 바로 깃허브에 올라가있지 않아.
브랜치를 만들어둬도, VSCODE에만 있는거지, 깃허브엔 없어. 그래서 이 브랜치를 깃허브에 등록하고 싶다면, 그 브랜치도 PULISH를 해줘야 해.
1. fast-forward 전략
A브랜치와 B브랜치가 있는데, A가 메인 브랜치야.
그러면 A인 메인 브랜치에서는 아무런 추가 구현을 하지 않고, B브랜치를 만들어서 거기에서만 추가 구현을 한 뒤,
B브랜치를 A인 메인 브랜치에 합쳐버려. 그럼 A에 B의 작업들이 전부 들어오겠지? 그게 FAST-FORWARD 전략이야.

2. 3ways
자 이건 말그대로 3개의 방향으로 하는 브랜치야.
자 메인 브랜치, 거실 브랜치, 화장실 브랜치가 있어.
그러면, 메인브랜치는 가만히 냅둬. 그리고 거실브랜치와 화장실브랜치에 각자 기능을 구현해. 커밋을 해.
그럼 이제 합쳐야할때, 메인브랜치에 합쳐야하는데, 메인이 하나 그냥 선택해서 "화장실브랜치야 너 작업 끝났어? 너부터 와!"
하고 메인에 화장실 브랜치를 합칩니다.
자 그럼 다음에 거실브랜치를 합쳐야 하는데, 거실 브랜치도 화장실 브랜치 앞에 붙여도 되고, 뒤에 붙여도 됩니다.
근데 이건 FAST-FORWARD랑 같지 않나요? 할 수 있는데, 맞아요 같아요.
3WAY전략은 FAST-FORWARD처럼도 쓸 수 있고, 현재 개발직에서도 같이 사용하는 것을 주로 이룬다고 합니다.


하지만 여기서 질문!
만약 거실브랜치에 있는데, 기능이 비슷한 브랜치가 있어. 예를들어 소파 브랜치 같은거, 그럼 기능이 사이사이에 껴둬야 한단 말이야.
그 사이에사이에 어떻게 껴넣지? 잘 기간 맞춰서 껴둔다고 해도, 중간중간에 우리가 작업한 것을 합친다음 한번 테스트해보고, 문제가 생기면 또 그 문제를 고쳐야하고, 다시 개발도 이어나가고 해야하는데, 그런건 어떻게 하지? 아 가지가 엄청 나오나?
합치고 다시 가지가 나오고, 다시 합치고 다시 가지들이 나오고 그런식으로 운영하나? 집중하면 잘 관리할 수 있을 것 같지만, 조금 복잡하지 않나?
이 질문에 대한 답은 다음 글에 적어보도록 하죠