👨💻 첫 팀회의
협업 팀빌딩이 끝나고 10/22에 첫 팀 회의가 진행되었다. 새로운 팀원분이 들어오신만큼 새로 자기소개하고 나서 본격적인 회의.
일단은 필수구현기능을 체크하고, 대략적인 프로젝트 방향성을 정했다. 그리고 나선 개발 방식(?)에 대해서도 논의하고.
디자인은 개인일정으로 디자인이 나오는데 시간이 조금 걸린다고 하셔서 프론트엔드 쪽에선 기본 구조 퍼블리싱만 미리 해두기로 했다.
그리고 백엔드와의 소통을 위해서 git과 관련한 어떤 협업툴을 쓸 것인가에 대해서도 얘기가 나왔는데 팀장분이 처음 추천해주신건 gitKraken이었다.
프론트엔드
프론트엔드 팀원은 나 포함 두명인데 나는 경험이 없는 것에 비해 다른 분은 팀프로젝트 경험이 몇번 있으셨다.
그래서 사실 팀회의때 나는 건의라 할게 딱히 없었다ㅠ 첨이다보니 접근방식을 어떻게 해야할지도 잘 모르겠고 뭘 해야할지 난감했다...
그래서 일단 큰 흐름에 대한 의견만 내고 모르는 부분은 물어보면서 진행했었다.
그리고 팀회의가 끝난 뒤 아무래도 내가 모르는게 많은 만큼 미리 공부를 좀 해야할 것 같다는 생각에 다른 프론트엔드 팀원분께 따르 대화 요청을 드렸다.
분명 공부를 하긴해야겠는데 '뭘 해야할지'를 모르겠어서 조심스레 여쭤보았다.
" 협업에서 제가 필히 익혀야할 부분이나 툴이 있다면 조언해주실 수 있을까요?ㅠ "
팀원분께서 친절하게 몇가지 알려주셨다. 일단은 협업과정을 진행하려면 pull request랑 merge, branch에 대해 알아두시면 좋을 것 같다구.
그래서 서치하면서 위에 대해 찾아봤다. 보니 하나의 흐름으로 이해하면 되는 것들이었다.
📬 협업을 위한 세팅
1. fork
일단 협업을 하면서 해당 프로젝트에 기여하고자 한다면 아마 가장 먼저 fork를 통해 레포지토리를 가져와야할 것이다.
fork는 이름처럼 마치 포크로 찍어서 가져온다는 느낌으로 다른 사람의 저장소에 있는 파일들을 내 저장소로 가져오는 것이다.
방법은 먼저 내가 가져오고자 하는 저장소에 가면 오른쪽 상단에 저런 fork표시가 있는데 저걸 누르면 된다.
그러면 내 저장소에 가져와 저장을 할 수 있고, 내 저장소에는 포크로 가져왔다는 표시와 어디서 가져왔는지에 대한 출처가 남게 된다.
2. clone 만들기
그런데 이제 github저장소에는 가져왔으나 내 로컬, 즉 컴퓨터에는 저 파일들이 없다.
작업은 결국 로컬에서 이뤄지니 저 파일들을 가져와야한다.
가져오는 방법은 clone을 만드는 것이다.
git clone <레포지토리 URL>명령어는 위와 같은데, 레포지토리 URL은 내가 아까 포크해서 가져왔던 저장소의 코드버튼을 누르면 확인할 수 있고 이를 복사해서 붙여넣으면 된다.
그러면 명령어를 실행한 로컬 위치에 clone이 생성되게 된다.
3. remote 설정
그리고 작업 전에 remote도 설정해줘야 하는데 clone으로 가져오면 일단 기본적으로 origin이라는 이름에 내 원격저장소 URL이 연결된다고 한다.
그런데 여기에서 끝내는 것이 아니라 원본 저장소, 즉 포크해왔던 곳도 remote를 등록해줘야 한다.
그 이유는 나중에 동기화를 시키기 위해서다.
// 원격저장소 remote등록
git remote add <이름> <저장소 URL>
// 원격저장소 확인
git remote -v보통은 내 원격 저장소의 이름을 origin으로, 원본 저장소의 이름을 upstream으로 하는 것 같다.
4. branch 나누기
이제 해야할 일은 branch를 나누는 것이다. 협업에서 정말 중요한 필수적인 부분인데, 이렇게 분기를 나눠야 해당 branch에서의 작업이 문제가 생기더라도 master에서의 코드는 유지되어 있기 때문에 role back을 시키기 쉽기 때문이다.
만약 나누지 않으면... 모든 코드가 덮어져 버린 상태로 에러가 나버릴 수 있는 대참사의 가능성이...
// 브랜치 생성
git branch <브랜치명>
// 브랜치 이동
git checkout <브랜치명>
// 생성과 동시에 이동하는 단축어
git checkout -b <브랜치명>
// 브랜치 리스트 확인
git branch이제 우리는 이렇게 만든 브랜치에서 작업 내용을 업데이트 해줄 것이다.
추가적으로, 내가 브랜치를 만들다가 이름을 잘못 설정했었다. 지우고 다시 만들려고 하다가 이름을 수정할 수 있는 방법이 있었다.
git branch -m <old name> <new name>
5. add, commit, push
일단 위에서 브랜치를 만들었고, 해당 브랜치로 이동을 한 뒤 작업을 했을 것이다.
그러면 이제부터는 개인 프로젝트를 하던 것과 동일하게 진행하면된다.
git add .
git commit -m "commit내용"
git push origin <브랜치명>이때 중요한 것은 push를 upstream(원본 저장소)에 하는 것이 아니라 origin 즉, 나의 원격저장소에 해야한다는 것이다.
6. pull request(PR) 보내기
이렇게 push까지 마치고 나면 내 github저장소의 위에 compare & pull request버튼이 생성되어 있다.
그러면 해당 버튼을 눌러서 전달사항 및 변경사항을 기록하고 pull request 요청, 즉 PR을 날려주면 되는 것이다.
PR후 추가 push
작업을 하다보면 PR을 이미 날렸는데 '아! 이거도 같이 수정(추가)해서 날릴걸!'할 때가 있다.
이럴 땐 굳이 PR을 취소하고 다시 commit/push후 PR할 필요 없이 그냥 PR이 이미 올려진 상태에서 commit/push를 진행하면 된다.
🚨 물론 같은 branch로 push를 해야한다.
그러면 해당 branch에 대한 PR에 추가로 push한 commit기록이 쌓이게 된다.
다만 협업의 경우 내가 추가 push하기 전에 다른 사람이 PR확인 후 merge시킬 수 있으니 미리 고지 후에 추가로 push하는 것이 좋을 것이다.
7. merge
이렇게 내가 작업한 내용을 PR보내게 되면 다른 팀원은 원본 저장소에서 PR내용을 확인할 수 있다.
그리고 해당 내용이 다른 코드에 영향을 미치지 않고, 원본 저장소에 반영해도 되겠다는 판단이 들면 그때 하는 것이 merge이다.
이름 그대로 PR의 변경사항을 원본에 병합하는 것이라고 보면된다.
만약 merge를 진행하게되면 PR내용은 닫혀서 사라지게 되고 원본 저장소에는 바뀐 내용이 반영되어 합쳐진다.
물론 문제가 있다고 판단될 시에는 이를 거절할 수도 있다.
pull(동기화)
merge가 완료되면 내 로컬 파일에도 다른 사람이 추가한 내용이 반영될 것이다.
git pull <원본 remote명칭> <브랜치명>branch 삭제
그리고 해당 작업이 끝난 branch는 삭제해준다.
git branch -d <브랜치명>협업을 하면서 위의 일련의 과정을 배포 전까지 계속해서 겪게 된다.
이 과정이 중요한 이유는 작업자간 다루는 파일이 겹칠 수 있기 때문에 코드의 충돌을 막기 위해서도 있고,
이러면서 서로 피드백을 주고, 코드리뷰를 하며 서로에게 좋은 영향을 줄 수 있기 때문이다.
나도 이제서야 제대로된 협업을 처음 겪어보게 됐는데 앞으로 계속 공부하면서 배우고 기록 해나가야겠다.
⭐ 첫번째 PR ⭐
