github 협업

git branch를 만들어서 협업하는 것은 다들 잘 알고 있을 것이다.

 

협업 규칙

1. branch 형식 : feature/{기능}
   • 예시 : feature/login, feature/boardlist
2. Commit message :
   • feat : 새로운 기능 추가
   • fix : 버그 수정, 기능 수정
   • docs : 문서 수정
   • refactor : 코드 리팩토링 (변수명 수정 등)
   • test : 테스트 코드, 리팩토링 테스트 코드 추가
   • style : 코드 스타일 변경, 코드 자체 변경이 없는 경우
   • remove : 파일 또는 코드, 리소스 제거
   • resource : 이미지 리소스, prefab 등의 코드와 상관없는 리소스 추가

다음과 같이 수행하며

 

branch의 종류는

 

main(master)

branch/develop

branch/feature

branch/release

branch/hotfix

등이 있다. 

 

여기서 새로운 기능을 개발하고 있는 브랜치는 feature이고 여기서 개발을 하다가 어느 정도 완료가 되면 dev브랜치로 병합한다. 그리고 안정성을 위해 중간에 release 브랜치로 병합한 후 최종적으로 main 브랜치로 병합해주면 되는 것이다.

이때 develop단계에서 긴급 수정해야할 때 hotfix라는 브랜치를 만들어 수정하면 되는 것으로 이루어진다.

 

git branch

브랜치 조회

 

git branch [브랜치명]

브랜치 생성

 

git checkout [브랜치명]

브랜치 이동

 

git checkout -b [브랜치명]

해당 브랜치가 없으면 생성하고 해당 브랜치로 이동

 

git branch -D [브랜치명]

브랜치 삭제

 

git branch -m [현재브랜치명] [new브랜치명]

브랜치 이름 변경

 

git push origin [브랜치명]

원격 저장소에 현재 브랜치 push

 

git merge [브랜치명]

예를 들어 login/feature 에서 작업 중이 던 것을 login/develop로 병합하려면

git checkout login/develop

git merge login/feature 하면 됨

 

물론 팀장이 아닌 경우는 git branch로 올려서 pull request 날리는 게 좋다.

 

그러면 팀장이 코드 확인 후 merge해 줄 것이고

 

그 merge한 코드를 git pull origin main 으로 당겨오는 것이다.

 

 

충돌 문제는 해당 충돌 파일에 가면 충돌된 텍스트가 함께 있으니 선택한 것을 제외한 충돌 구문을 지우면 된다.

 

그리고 협업을 하다보면 사용자마다 설정 정보가 다르기 마련이다.

같은 spring에 mariaDB에 react를 사용한다고 해도

누군가는 mac을 쓰고 누군가는 linux를 누군가는 windows를 쓸 수도 있다. 또 버전이 다를 수도 있다.

사용자는 윈도우에서 작업한 것을 linux 서버에 올릴 수도 있다. 이때 오류가 날 확률이 높으므로

이럴때는 docker로 이미지를 올려서 관리를 하는 게 좋고

 

그게 아니라면 인텔리제이의 환경(gradle, maven 환경은 사용자마자 달라지니까)의 차이 정도가 걱정된다면 .gitignore을 사용하여 git에 올리는 정보를 제외해도 좋다.

 

또 application.properties나 yml 파일 같은 경우는 각자 버전이나 포트를 다르게 쓰고 있을텐데 아예 무시하기에도 좀 애매하다. 이럴 땐 사전에 협의를 하는 것도 좋다고 한다.