깃 협업 사용법

팀플이 닥쳐서 깃 협업을 하게 됐다. 마냥 어렵게 느껴졌던 깃인데 나름 잘 배워가고 있는 듯하다.

깃 플로우에서 영감을 받아(?) main과 별개로 develop 브랜치를 만들었으며, 이 하위 브랜치로 landing, post_list, signup 등 세부 브랜치들을 만들었다.

기능단위로 만들라고 했는데 사실상 html 단위로 만들고 있다. 기능단위... 흠 요구사항 분석을 한다고는 했는데 한 페이지 안에서 get도 하고 put도 하고 이건 기능이고 저건 기능이 아닌 거 같고 기준이 명확하지 않아서 헷갈린다

암튼 깃 협업에 대해 얘기해보자면 develop의 하위 브랜치 만드는 법은 다음과 같다.
git checkout -b recommend develop
git push origin recommend

---

그리고 develop 브랜치 만드는 법이 조금 달랐다.

git checkout -b develop #develop은 하위브랜치가 아니라서 뒤에 뭔가 붙지 않는다.
git add .
git commit -m "Initial commit on develop branch"
git push origin develop #develop에다가 push한다

---

아주 기본적으로 써왔던 커밋 프로세스는 다음과 같았다.

평소 gitcheckout "자기브랜치"한 상태로 늘 작업하다가

git add .
git commit -m " "
git pull origin main
git push
이렇게 하면 어지간해서는 충돌이 안 났다.

근데 난 gitflow든 뭐든 곧장 main으로 안가게 하는 협업은 단 한번도 한 적이 없나보다. 너무나 익숙한 명령어 git pull origin main.....
앞으론 main에 좀 덜 익숙해져야겠다.

---

하위브랜치에서 작업한다는 가정이라면
git add .
git commit -m " "
git pull origin develop
git push 이려나?

누군가 기능을 완성하면 자기 브랜치가 아닌 develop으로 push를 할테니 말이다.

---

그리고

이런 깃 커밋 컨벤션 / 풀리퀘 컨벤션 도 하게 됐다. 이건 또다른 팀플인 소공(소프트웨어공학)에서 알게 된 거지만, 이번 인프(인터넷프로그래밍)에서 써먹어보려고 한다. 내가 팀장이기 때문에 음.. 알려줘보려고 한다.
사실 데이터베이스에 기존 데이터를 스크래핑해서 넣어두고, 장고 프로젝트 및 앱 생성해서 urls.py와 view.py 구조 잡아놓는 작업은 feat이 아닌데 뭐지... 하다가 냅다 add로 써서 냈는데, 지금 보니 chore에 해당하는 건가 싶기도 하다.