git cycle 재정리

드디어!!!! 팀 프로젝트를 시작했다.

함께 일하고 소통을 원활히 하기 위해 깃과 깃허브를 이용하기로 해서,
깃의 사이클에 대해 다시 한 번 정리하고자 한다.

Position of Git

Git은 크게 Local과 Remote로 나뉜다.

Local은 내 컴퓨터(랩탑 혹은 데스크탑) 위치이고,
Remote는 network를 통해 접속할 수 있는 컴퓨터, 즉 GitHub 위치이다.

Basic Cycle

Summary

git clone 리파지토리주소
-> git branch feature/login
-> git checkout feature/login
-> git add .
-> git commit -m "Add: Login page complete"
-> git push origin feature/login
-> write PR
-> (remote의 master에서) merge
-> (local에서)git pull origin master

1. Github에 있는 한 repository의 master에 있는 코드를 local 컴퓨터로 클론받는다.

git clone 리파지토리주소

2. 클론 받은 직후에는 local 컴퓨터의 master에 코드가 있다.
   이 때 브랜치를 생성하고 git branch feature/login, 그 브랜치로 이동한다 git checkout feature/login.

3. local 컴퓨터의 feature/login 브랜치에서 열심히 코드를 작성한다.

4. 작성(혹은 수정)한 코드를 queue에 저장하고 git add ., log와 함께 새로운 수정본을 생성한다 git commit -m "Add: Login page complete".(현재의 코드 상태를 사진으로 찍어놓는 것과 같다.)

5. local 컴퓨터의 코드를 remote(github)로 push한다.
   git push origin feature/login
   이는 "feature/login을 origin 위치에 push한다"와 같은 말이다.

6. 그 후 Pull Request(PR)를 작성한다.
   이는 "remote의 master에서 내가 올린 코드를 당겨주길 요청한다"는 의미로, 해당 코드에 대한 설명이 PR에 담긴다.

7. master에서 해당 코드가 괜찮다고 판단하여 merge하면, master의 코드가 업데이트된다.

8. remote의 코드와 local의 코드를 동일하게 유지하고 conflict를 방지하기 위해, remote master의 코드가 update되면, 꼭 git을 pull 받아놓는다.
   git pull origin master
   이는 "origin 위치의 master를 당겨온다"는 뜻이다.

9. 3~8번을 반복하고, 새로운 브랜치 생성이 필요할 때 2번을 진행한다.

Cycle of Team project

팀 프로젝트를 할 때는 팀원 중 1 명의 local 컴퓨터에서만 초기 세팅을 진행한다.
해당 세팅대로 다른 팀원들이 clone을 받아야 모두 동일한 세팅 환경을 마련할 수 있기 때문이다.

1. 한 팀원이 (예_팀원 A) 본인의 local 컴퓨터에 westagram이라는 디렉토리를 생성하면서 CRA를 설치한다.
   npx create-react-app westagram

2. 추가적으로 필요한 package와 program을 다운로드 받는다. 추가적으로 다운 받은 파일명과 버전은 모두 package.json에 저장되고, 실제 소스 코드는 node.modules에 저장된다.
   images 소스 등도 public 디렉토리 안에 새 디렉토리를 생성해서 모두 모아 둔다.

3. git add ., git commit -m "Add: initial settings complete", git remote add origin 레파지토리주소 를 한다.

4. node.modules는 파일의 무게가 너무 크기 때문에 .gitignore에 기록하고 remote 컴퓨터에 올리지 않는다. .gitignore 파일에 기록되지 않은 모든 파일은 git push origin master 를 통해 remote 컴퓨터의 마스터에게 push한다.

5. 다른 팀원들은 github의 해당 repository를 clone 받는다. 그 후 각자의 local 컴퓨터에서 npm install을 하면, node.modules 파일과 package.json에 기록된 추가 파일들이 다운로드된다.

6. 각자의 local 컴퓨터에서 새 브랜치를 생성하고, 그 브랜치에서 작업을 진행한다.

Cycle of treating Conflict

협업의 과정에서 Conflict는 일어날 수밖에 없기 때문에, 이를 사전에 방지하고 잘 다루는 것이 중요하다.

각자의 local 컴퓨터에서 작업한 코드를 github repository에 push한 후, master가 코드를 merge하면 master의 코드는 업데이트된 상태이다.
이 때, 이미 push를 했으나 아직 merge되지 않은 코드나 local 컴퓨터의 코드는 github master의 코드와 다르기 때문에 conflict될 가능성이 아주 높다.

이 때 Conflict를 방지하는 제일 좋은 방법은, master의 코드가 업데이트될 때마다 local 컴퓨터에서 git pull origin master을 진행해서 동일한 코드를 유지하는 것이다.
(꼭 checkout을 통해 local의 master에 위치한 상태에서 git pull을 진행하자!)

그럼에도 불구하고 Conflict가 난 상황이라면, 코드를 찬찬히 읽고 충돌된 코드를 작성한 분과 소통해서 conflict된 코드를 수정하고 다시 push를 하면 된다.

내일 오전에 westagram 팀원 분들과 함께 초기 세팅을 진행하기로 했다.

팀으로 함께할 때 더 에너지와 시너지가 나는 나로선, 팀원 분들과 소통하면서 작업하고 결과물을 만들어낼 과정이 정말!!! 기대된다.

팀에 누가 되지 않고 도움이 될 수 있도록 공부도 더 하고, 분위기도 즐겁게 유지될 수 있도록 노력해야겠다!!