| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
- 메가바이트스쿨
- 코딩테스트
- styled-components
- 모던 자바스크립트 딥 다이브
- 자바스크립트
- 국비지원교육
- 모던 딥 다이브 자바스크립트
- MegabyteSchool
- 프론트엔드
- next.js
- 개발 공부
- CSS
- 입문
- 자료구조
- Github
- useRef
- 비전공자
- 내일배움카드
- JavaScript
- GIT
- TypeScript
- 리액트
- 알고리즘
- useMemo
- 이벤트
- 개발자취업부트캠프
- 공식문서
- 프로그래머스
- 패스트캠퍼스
- react
- Today
- Total
개발 기록 남기기✍️
[패스트캠퍼스] 프론트엔드 부트캠프 git과 github으로 처음 협업해 본 후기✨(1주차) 본문

안녕하세요 여러분. 제가 또 왔습니다.
메가바이트스쿨 1주차가 끝났다!
한 주 동안 git의 기초, git bash 다루는 방법, git과 github를 통해 협업하는 방법을 배웠다.
그리고 금요일, 대망의 첫 협업 시간!!
아직 배운 것들이 없기 때문에 프로젝트를 진행하는 것이 아니었고, 팀원들의 자기소개를 하는 HTML 문서를 작성하기로 했다.
나는 협업에서 팀원으로서의 역할을 수행했다!
먼저 팀장이 GitHub에서 Organization을 만들고, 팀원들을 초대한다.
팀장이 기본적인 세팅을 한 뒤, 팀원들이 각자의 저장소로 fork해서 각자의 섹션 작업을 진행한다.
local repo에서 작업한 뒤 push해서 개인 remote repo에 올린 후, 이것을 team repo로 pull request하면 팀장이 검토하고 승인 여부를 결정한다.
Conflict message가 발생하면, 어떻게 할건지 팀 내에서 상의 후 file을 그에 맞게 수정한다.
모든 섹션이 채워지면 팀장이 git flow release를 하여 main 페이지로 페이지를 발행한다.

작업을 진행하기 전에, Team Repository에 Issue를 생성해서, 어떤 작업을 할건지를 작성한다.
팀장의 컨펌이 이뤄지면 그 때부터 내 Repository에서 작업을 시작한다.

팀 Repo에서 내 Repo로 끌어오는 방법은, 팀 Repo에서 Fork 버튼을 눌러 내 Remote Repository를 생성한다.
이 때, main branch만 가져오기라는 check 항목이 있는데, 꼭 check를 풀어주고 모든 branch를 가져오도록 한다!!
팀원들은 main이 아닌 develop branch에서만 작업하고 develop에서 main으로 발행하는 건 오직 책임자인 리더만 하도록 한다.

내 Repository에 돌아와서 확인하면, main, develop branch와 파일들이 잘 fork된 것을 확인할 수 있다.
참고로, main이 아닌 develop branch에 우리가 작업할 index.html 파일이 들어있다.
이제는 내 로컬 저장소로 끌어올 차례.

git clone address로 로컬 저장소에 끌어온다.
이 때 주의해야 할 점, 팀 레포 주소를 적는게 아니라 fork한 내 레포 주소를 적어야 한다!
Remote Repo를 잘 끌어왔는데.. branch를 확인해보니까 main만 있고 develop branch는 없는 것을 볼 수 있다.
이때, 당황하지 않고 바로 git flow init을 실행한다.

git flow init을 실행하니 branch가 자동으로 develop으로 이동되었고, 파일 리스트를 확인해보니 팀장이 develop branch에서 작업한 내용이 살아난 것을 확인할 수 있다.
이제, 저 index.html 파일을 가지고 작업하면 된다.
근데 그 전에 먼저, git remote -v로 확인을 해보면

remote에 origin 밖에 없는 것을 볼 수 있다.
팀에서 협업을 하는 방식은 팀장의 Remote repo 사본을 가지고 내 로컬 저장소에서 작업 -> 내 Remote Repo로 push -> 팀장의 Remote Repo에 Pull request를 날리는 방식으로 작업을 한다.
그리고 팀원들이 작업한 파일은 팀 Repo에서 직접 당겨받을 수 있다. 팀 repo에서 파일을 받기 위해서는 git remote add upstream address 작업을 수행해야 하는데, 이 때의 address는 팀 Repo의 주소를 입력한다.
Pull Request : 내가 수정한 코드가 있으니 내 branch를 가져가 검토 후 병합해주라고 요청 해주는 것이라고 보면 된다. PR을 통해 코드 충돌을 최소화할 수 있고 push 권한이 없는 오픈 소스 프로젝트에 기여할 때 많이 사용한다.

다시 git remote -v를 해보면 upstream이 생긴 것을 볼 수 있다. 이제 여기서 git fetch upstream을 통해 팀 파일을 직접 내려받을 수 있다.
이제 내 파일 작업!
작업은 git-flow를 사용해 작업한다.
⬇️어떻게 작업하는 지 보려면 아래 링크를 클릭해주세요.⬇️
https://charmming5.tistory.com/56
[Git] Git-flow란? / 다루는 방법
Git-flow Vincent Driessen의 브랜칭 모델. Git으로 개발할 때 거의 표준과 같이 사용되는 방법론. git-flow cheatsheet git-flow cheatsheet danielkummer.github.io Git-flow의 브랜치 Git-flow에는 5가지 종류의 브랜치가 존재
charmming5.tistory.com
git flow feature를 통해서 작업 단위 별로 작업을 하고, 각 작업 단위가 끝나면 Team Repo에 올렸던 Issue의 Task에 하나씩 체크를 한다. 이것을 통해 다른 팀원들은 내 작업 진척도를 확인할 수 있다.

Issue에 작성했던 나의 업무가 다 끝나면, 이제는 내 Remote Repo로 push해줄 차례!
처음으로 올리는 거면 git push -u origin develop을, 두 번째부터는 git push origin develop을 입력해서 push해 준다.
main 아니다. develop이다!!!!!
push를 해준 뒤, 내 Remote Repo로 이동해보면 아래와 같은 버튼이 생성된 걸 볼 수 있다.

Pull Request 버튼을 눌러서 메세지와 함께 Team Repo에 Pull Request 요청을 보내주면 된다.

message를 입력할 때, #을 입력하면 어떤 Issue에 관해서 작업한 것인지 Issues List를 불러올 수 있다.
List 중에서 나의 Issue를 클릭하고, 부연설명하는 message를 덧붙여서 Pull Request를 요청했다.
comment를 보면 내가 git add, git commit한 내용까지 다 전송된 것을 볼 수 있다.
이 때 주의해야 할 점!!
병합을 요청할 때, 내 develop 브랜치에서 팀의 develop 브랜치로 병합 요청했는지 체크한다!
팀의 main 브랜치로 병합해버리면 클난다.. (물론, 팀장이 체크하고 Request 거절을 할 수 있다. 하지만, 일을 두 번 하지 않도록 체크 또 체크!)
팀장은 Merge를 하기 전, 파일을 체크하고 수정 사항이 있으면 파일의 해당 라인에 comment를 작성하고 Request를 거절할 수 있다. 문제가 없으면 승인하여 나의 작업 내용이 Team Repo에 push된다.
만약, 여러 사람의 동시 작업으로 인해 같은 섹션을 건들게 되어 Conflict message가 발생할 시, 팀 내에서 상의해서 github에서 바로 파일을 수정한 후 충돌을 해결할 수 있다.
주말동안 각자 작업해서 Request 날리면 월요일에 다같이 모여 함께 화면 공유하면서 conflict 발생하는지 확인하고 release할 예정!! 진행되면 바로 내용을 추가하도록 하겠다.
오늘의 느낀 점 : 협업은 소통이 반이다.
(체감 상 90%)
처음에는 md 파일로 협업을 진행했다. 그런데 처음에 어떻게 파일을 작성할지 소통이 제대로 안되어서 introduce.md 파일의 초안에 있던 내용을 아예 지우고 작성한 분들도 계셨고 초안 내용 밑에 새롭게 내용을 덧붙이는 분들도 계셔서 각기 다른 Conflict message가 발생했다.
그리고 이미 Request를 날린 상태에 revert를 하려다가 안되어서 다같이 멘붕하고 한 시간 동안 작업한 내용을 다 날리고 새롭게 다시 Repository를 생성해서 작성하기도 했다.😅
아직 제대로 프로젝트를 시작해보진 않았지만! 간단한 git 협업 실습을 통해서 소통의 중요성을 다시금 깨닫게 되었다.✨
어떤 방식으로 작업할 건지, 어떤 규칙을 적용할건지 충분히 소통 후에 작업하는 것이 심신 안정에도 좋고.. 빠른 진행에도 좋고..ㅁ7ㅁ8
(요즘 애들은 ㅁ7ㅁ8 모른다면서요..? 충격 그 잡채다 진짜..)
그리고 다른 사람이 귀찮아할까봐 이해한 척 하는게 아니라, 이해 안된 부분 있으면 다시 한 번 물어보고!! 내가 해야 할 작업을 정확히 숙지하고 작업할 것!! 괜히 아는 척하고 했다가 잠깐 귀찮게 하고 끝날걸 겁나 귀찮게 해드릴 수도 있다..
다음 주부터는 HTML/CSS 강의가 시작된다!
아는 파트라고 대충 듣는 것이 아니라, 내가 완전히 이해하고, 자유자재로 다룰 수 있는지를 체크하면서 수업에 집중해야겠다!
그럼 오늘의 짤 남겨놓고 전 이만..
다들 평안하세요!!

'개발 일기장' 카테고리의 다른 글
| [패스트캠퍼스] 프론트엔드 부트캠프 한달차 후기✨(4주차) (0) | 2023.01.08 |
|---|---|
| [패스트캠퍼스] 프론트엔드 부트캠프 HTML/CSS 클론코딩 과제 후기✨(3주차) (2) | 2023.01.02 |
| [패스트캠퍼스] 프론트엔드 부트캠프 HTML/CSS 수업 1주차 후기✨(2주차) (1) | 2022.12.27 |
| git branch merge 연습하다가 키보드 부술 뻔한 후기🤦♀️(feat. 근황) (0) | 2022.12.15 |
| [메가바이트스쿨] 메가바이트 스쿨 프론트엔드 과정 합격 후기✨ (0) | 2022.12.02 |