협업 방법 👫
깃, 깃허브 수업에서 배운 내용을 활용하여 팀 과제를 수행했습니다.
실제 업무와 비슷하게 팀장과 팀원의 역할을 나누어 팀 협업을 어떻게 이루어지는지 직접 테스트를 해보았습니다.
팀장 🌱
1. GitHub Organization 계정 생성
GitHub에서 단체(Organization) 계정을 생성합니다.
오른쪽 상단의 + 아이콘을 클릭 후, Your organization을 클릭합니다.
New organization을 클릭하면 플랜을 선택하는 화면이 나오는데 이때 무료 플랜을 선택해줍니다.
플랜을 선택하면 Organization에 대한 정보를 입력하는 페이지로 넘어갑니다. Organization account name(단체 이름)과 Contact email(대표 이메일), 그리고 단체 소유주를 입력합니다. 이때 단체 소유주는 My personal account(현재 사용중인 개인 계정)
해당 검색창에 GitHub ID를 입력하면 초대할 사용자를 검색하고 추가할 수 있습니다. 초대할 멤버를 모두 골랐다면 Complete Setup을 클릭합니다. 초대할 멤버가 없다면 버튼 아래의 Skip this step을 클릭합니다.
이렇게 하면 Organization 계정이 생성되며, 계정을 생성한 계정은 자동적으로 단체 계정의 관리자가 됩니다.
개인 계정으로 이동해보면, 프로필에 단체 계정이 등록된 것을 확인할 수 있습니다.
2. Organization에 속한 Repository 생성
Team Work를 하기 위해서 Repository가 필요합니다.
만들어진 Organization에서 Repositories를 클릭합니다.
오른쪽 New repository 버튼을 클릭하고 해당 페이지에서 repository name등을 설정해주면 Repository가 생성됩니다.
People을 클릭 후, Invite member버튼을 누르면 팀원들을 초대할 수 있습니다.
💡 GitHub의 계정 종류는 크게 개인 계정과 단체(Organization) 계정으로 나뉩니다. 개인 계정에서도 저장소를 만들고 다른 개발자를 저장소에 초대해서 협업하는 게 가능합니다. 기능 상 아주 큰 차이가 있지는 않지만, 저장소를 소유주 한 명에게 의존적인 형태로 협업을 해야한다는 게 큰 단점입니다. 또한 다수의 저장소 권한을 한꺼번에 관리하거나 다수의 관리자를 지정하는 것도 불가능하며, 협업 관련 기능도 부족합니다.
GitHub에서는 바로 이럴 때 단체(Organization) 계정을 사용합니다. 단체 계정을 생성 하면 단체에 속한 저장소를 만들 수 있으며, 단체에 속한 멤버들을 관리할 수도 있습니다. 또한 협업을 위한 다양한 기능들을 추가로 제공하고 있습니다. 기업이나 비영리 단체에서도 GitHub 단체를 만들어서 사용하는 게 일반적입니다.
3. Git Clone
Team Work 수행하기 위해 github에 올라온 소스코드를 클론해야합니다.
깃허브에서 해당 주소를 복사해줍니다.
$ git clone [Repository주소]
그리고 터미널에서 내가 프로젝트를 저장할 폴더 위치에서 해당 명령어를 실행해야 합니다.
4. .gitignore 파일 생성
깃 플로우를 적용해서 팀원들이 만든 feature branch를 따서 작업했던 deveop에 쌓인 이 프로젝트 레포의 develop에 쌓여야합니다.
$ git flow inint클론된 디렉토리에 들어간 후,
$ touch .gitignore
$ vi .gitignoregitignore.io 에 접속하여 원하는 입력창에 현재 사용중인 개발환경을 검색하고 생성된 gitignore 내용을 모두 복사 후 프로젝트 파일에 .gitignore 파일을 생성하고 위의 생성된 내용을 붙여 넣어 저장합니다.
그리고 위의 이미지 처럼 커밋을 해줍니다.
💡 꼭
mainbranch에 gitignore 파일을 만들어야 합니다.
.gitignore이란?
Project에 원하지 않는 Backup File이나 Log File , 혹은 컴파일 된 파일들을 Git에서 제외시킬수 있는 설정 File입니다.
5. git flow 사용하기
$ git flow init
깃 플로우를 시작하면, develop branch가 생성되고 develop 브랜치로 이동한것을 확인할 수 있습니다.
6. 프로젝트 기반 Set Up
팀장은 프로젝트의 기반이 되는 작업을 셋업해주는 것이 좋습니다.
develop 브랜치 위에서 팀원들이 작업할 index.html과 main.css 파일을 생성해주고 커밋해줍니다.
7. develop 브랜치 push
$ git push -u origin develop💡첫 push이므로
-u(upstream)을 붙여줘야 합니다.
push 후, github 페이지에서 새로고침을 하면 develop 브랜치가 생성되고 생성한 파일이 push된 것을 확인할 수 있습니다.
팀원 🌱
1. Issues 작성
Repository의 Tab 가운데 Issues는 다양한 방법으로 활용 가능합니다.
Issues에서는 개발 중인 기능 관련 이슈, 문제 상황 등을, Issues 생성을 통해 다른 사람들과 공유할 수 있습니다.
Issues 생성은 Repository의 Issues Tab으로 이동해, New issue 버튼을 통해 생성할 수 있습니다.
예시로 Issues 양식은 위의 이미지처럼 작성해주면 됩니다.
이때 자세히 적는것이 좋습니다.
2. Fork 생성
초대를 받은 팀원들은 팀 Organization에 속한 Repository에 들어온 상태입니다. 여기서 github에서 제공하는 Fork라는 기능을 활용해 간접적으로 일을 하게됩니다.
팀원은 직접적으로 push가 불가능하기 때문에 사본을 만들어 내 휘하에 두고 push를 해야합니다.
Fork는 다른 사람의 Github repository에서 내가 어떤 부분을 수정하거나 추가 기능을 넣고 싶을 때 해당 respository를 내 Github repository로 그대로 복제하는 기능입니다.
fork 한 저장소는 원본(다른 사람의 github repository)과 연결되어 있습니다. 여기서 연결 되어 있다는 의미는 original repository에 어떤 변화가 생기면(새로운 commit) 이는 그대로 forked된 repository로 반영할 수 있습니다.
따라서 Fork를 이용하여 Organization의 프로젝트를 사본을 만든 후, 원본으로부터 remote의 사본을 만들고, 이 remote에 clone을 하여 작업 후 push를 해줘야합니다.
💡 fork를 생성할 때,
Copy the main branch only는 꼭 체크해지 하셔야 합니다. 체크를 하게되면 팀장이 만든 develop branch가 무용지물이 되기 때문입니다.
3. Git clone
Team work를 수행하기 위해 github에 올라온 소스코드를 내가 프로젝트를 저장할 폴더 위치에서 해당 명령어를 실행합니다.
이때, 주의할 점이 있습니다❗️
꼭 팀 Organization의 repository의 주소가 아닌, 이곳에서 사본을 뜬 내 권한이 된 프로젝트 repository가 생기는데 해당 주소를 클론해야합니다!
$ git clone [나의 Repository주소]
팀원들은 로컬에서 작업한 후, 내 Github Repository에 push하고
팀 Github Repository에 간접적으로 Pull Request를 통해 기여를 하게됩니다.
4. Remote 설정
레파지토리를 clone하면 origin 이라는 이름으로 remote url이 내 원격 저장소로 기본으로 설정되어 있습니다.
하지만 내 원격 저장소 뿐만 아니라, 포크 했던 원본 저장소도 remote로 등록 해주는 게 좋습니다. 나중에 원본 저장소 내용과 동기화 하기 위해 사용할 것이기 때문입니다.
$ git remote add upstream [팀 Repository url]해당 명령어는 원본 Repository remote 등록합니다.
$ git remote -v해당 명령어는 원격 Repository를 확인할 수 있습니다.
Upstream이란 ?
다른 사람의 GitHub의 Repository를 Fork한 경우 내 GitHub가origin이 됩니다.
내가 처음fork를 시도한 Repository를 upstream이라고 부릅니다.
origin와 upstream 모두 remote 저장소입니다.
보통 origin과 구분하기 위해서 upstream 이라는 명칭을 주로 사용합니다.
5. git flow 사용하기 - init
$ git flow init
클론된 폴더로 이동하면 main 브랜치가 있고, 팀장이 만들어 놓은 파일들을 확인할 수 없습니다.
git flow init 을 통해 develop branch가 생성되고 develop 브랜치로 자동으로 이동한것을 확인할 수 있습니다.
그리고 팀장이 만들었던 파일들도 자동으로 들어온 것을 확인할 수 있습니다.
💡
mainbranch 에서 작업하면 ❌
6. git flow 사용하기 - feature branch
$ git flow feature start [featureName]
기능 추가 및 수정을 하기 위해 feature 브랜치를 사용할 수 있습니다.
해당 명령을 실행하면, develop 브랜치 기반의 feature 브랜치가 생성되고 자동으로 feature 브랜치로 이동됩니다.
$ git add [파일명]
$ git commit
클론된 소스코드에서 팀원이 맡은 부분을 개발하고 커밋해줍니다.
💡
$ git add .는 가급적 사용하지 않는것이 좋습니다.
실수하기 좋은 커맨드이기 때문에 하나하나씩 해주는것이 좋습니다.
기능개발이 완료되었다면 해당 명령어를 통해 이 사실을 git flow에 알립니다.
$ git flow feature finish [featureName]
git flow feature finish 명령어가 실행되면
git flow는 develop 브랜치로 이동하고,
feature 브랜치의 변경사항들을 자동으로 develop 브랜치에 merge 합니다.
작업이 끝난 feature 브랜치를 삭제합니다.
7. git push
나의 remote(내 Github Repository)에 push 해줍니다.
$ git push -u origin develop
💡 로컬에서 처음만든 develop을 push해주기 때문에 -u(upstream)를 사용해줍니다.
내 Github Repository에 들어가면 내가 작업한 것들이 push 된것을 확인할 수 있습니다.
8. Pull request
Pull request란 내가 수정 혹은 개발한 코드가 있으니 나의 branch를 가져가 검토 후 merge해달라고 요청 해주는 것이라고 보면 됩니다.
즉, 팀의 Repository에 pull 하도록 request 해주는 것입니다.
내 Github Repository에서 Pull request 에 들어가 new pull request 버튼을 눌러줍니다.
로컬의 develop 브랜치에서 작업해서 remote의 develop 브랜치로 push를 하고, create pull request버튼을 눌러줍니다.
내가 어떤 작업을 했는지 메세지도 작성해줍니다. 내가 이슈에 작성한 내용과 연동이 됩니다.
초록색이면 merge가 가능한 상태를 말합니다.
팀장 🌱
1. Merge Pull Request
Pull Request를 받은 원본 Repository 관리자(팀장)는 코드 리뷰를 하고 Merge 여부를 결정하게 됩니다.
코드에 문제가 없으면 viewed를 전부 클릭해주고 Review changes 버튼을 눌러 approve를 해줍니다. 팀장은 승인을 하면 Merge Confirm으로 원본 저장소에 변경된 사항이 반영이 되고, pull request의 상태는 closed로 변경이 됩니다. 만일 맘에 들지 않는다 하면 Reject 됩니다.
팀원 🌱
$ git pull upstream develop
해당 명령어는 여러명의 팀원들이 작업한 내용물이 나의 develop 브랜치에 쌓이게 됩니다.
💡 pull 이 안될경우 해당 명령어를 입력하면 됩니다
$ git fetch upstream develop $ git merge FETCH_HEAD
🌕 레퍼런스
