🚀 BE Day 40 0506

⬇️ Main Note
https://docs.google.com/document/d/1fmrR4Qq6lThvvq-GApQ_vFTc6VlvXnV3QhVvZoQjvlg/edit

---

🌕 Docs

Sequence Diagram : 순서도
➤ This is an essential thing since other co-workers are able to know which functions to use when API is requested.

ex) https://docs.google.com/spreadsheets/d/1BCdqOX4YkpPdMstuxlfGMZO4ykqKSSlMUwJ8e0K7K3w/edit#gid=0

---

🌕 Gitflow WorkFlow

Developing is done in develop branch.
➤ Naming doesn't really matter, but this is conventional.

Branch is like a specified folder.

git branch
➤ View my current working branch.
git checkout -b develop
➤ Create a branch called “develop” and move to that branch.
➤ Here, develop branch is created from master branch.
➤ git checkout -b aaa => aaa branch created and moved to aaa branch.
git checkout -b qqq
git checkout master
➤ We do not add -b when moving to existing branch.

Each branches have different folders.
➤ Even if I changed something in master branch, there's nothing with develop branch.
➤ Commit should be done to save
➤ When branches change, files and folders change.

🫧 Developing in develop branch

master branch에서 feature branch를 땄다고 할때:
철수는 게시글 등록을 만들고 영희는 상품등록을 만들고 훈이는 결제하기 기능을 만들었다고 하자
3명이 회사에서 같이 일하고 있기 때문에 회사에는 하나의 큰 repository가 있음 === develop branch
철수, 영희, 훈이는 각각의 develop branch에서 시작을 해서 새 branch를 딴 후 각자의 branch에서 일하는거임
철수가 feature-boardwrite라는 branch를, 영희는 feature-productwrite, 훈이는 feature-payment를 만듦
영희 vscdoe에서는 feature-productwrite 밖에 없음 자기꺼밖에 없는거임

그래서 각자 친 코드를 develop에 합치는 방식으로 진행하는거임
그러면 develop source code가 점점 커져가는거임

[ Deploy ]
그래서 나중에 얘를 그만 만들고 배포하자! 하는거임
그리고 이 배포는 master branch에서 실행
근데 그 전에 release branch에 이동시켜서 합침
→ 얘도 그냥 이름이 release branch일 뿐이지 이름은 아무거나 해도 상관이 없음
→ release branch는 개발자들 사이에서 암묵적인 룰이 존재함
*** 여기서는 기능을 추가하지 않고 버그만 수정해서 업데이트해야함
그래서 더이상 최종 버그가 나오지 않게 된다면 master branch에 이동시켜서 그 master branch를 배포시키는거임

[ hotfixes ]
만약에 master branch에 이미 배포가 다 된 후에 치명적인 버그가 생겼다면
( 출시 버전에 발생한 버그를 수정하는 브랜치 )
Master branch에서 hotfixes branch를 까는거임
그러면 그걸 가지고 치명적인 버그들을 수정 후 다시 master branch에서 업데이트를 하는거임

어느 브랜치에서 어떤 브랜치를 땄느냐가 상당히 중요함 (어디서 뭘 땄느냐)
파일과 폴더를 가지고서 새 브랜치를 따는거기 때문임
새 브랜치를 땄다고 해서 모든 파일이 다 저장되어있는게 아니기 때문에 어디서 땄느냐가 matters


우리가 평소에 git push 할때 => git push origin master 였음
git push origin feature-boardwrite
git pull 받을땐 => git pull upstream develop

🌕 Notice

서로 독립적인 기능 만들기
나눠서 개발을 하고 있음 (각자 게시물, 상품, 결제를 하는중)
– 이때 훈이가 철수의 소스코드를 변경하면 안됨
훈이도 게시글 등록을 수정하게 되면 두군데에서 동시에 바뀌게 되기 때문에 PR이 회사 repository에 날라갔을때 merging을 하려는데 뭘 합치고 뭘 버릴지 모르는거임
파일 두개를 동시에 merge 할 수 없음(X)
공통으로 사용되는 기능들은 리더나 시니어가 담당해야함 (서로 독립적인 기능이 안될때 )
모든 군데군데에 영향을 미치다 보니, 공통 기능들은 리더, 시니어 등등 연차가 있는 사람들이 맡아서 진행함
다른 개발자들에게 피해가 되지 않게끔 피해여부도 체크해가면서 개발해야함
Merge가 안된 기능과 독립적인 기능 만들기
철수가 시간이 좀 남아서 다음거를 먼저 개발해볼까? 하는데 그러면 게시물 등록 했으니까 게시물 수정을 해보자 이랬음
근데 이거 위험함!! 아직 합쳐지지 않은 상태에서 뭘 더 하려고 하면 안됨
→ Merge 가 안될수도 있는데 그거에 의존적인 API를 만들게 되면 꼬이게 됨
Merge가 안되고 거절당했을때를 생각해봐야함
Merge가 안된 기능에 의존적인 기능 만들지 말기
[ 실습 ]
회사 repository : mento’s repository
Push 하게 되면 pr날리고 확인 누르면 자동으로 원본에 pull request가 날라가게 됨
Pull request 에서 회사 Repository를 가지고 있는 사람은 merge를 할 수 있음

팀장 git clone 후 그 branch에 들어가서 새 branch 생성
=> git checkout -b feature-#10
Api 만들고 이거저거 한 후…
git add .
git commit -m “Update - board api” [ Commit Convention ]
git push origin feature-#10
git log 하면 commit logs 조회 가능해서 되돌리기가 가능함

Git pull upstream develop
을 하기 위해서는 1. git checkout develop
2. git add remote add upstream “원본주소”
3. git pull upstream develop

그래서 계속 개발을 진행해나가는거임
git checkout -b feature-#11
→ 이런식으로 또 브랜치 따서 만들고 작업하고 pr날리고…
이때 feature-#NUMBER에서 NUMBER는 issue 번호