Git & Github을 이용한 작업 방식

우리가 git과 github을 이용해서 작업을 할 때는 크게 두가지 공간이 있다는 개념을 이해해야한다

• Remote : 원격 저장소(인터넷 상에 올라가 있는 저장소)
  github상의 공간 : Repository 는 한 리모트에만 연결될 수도 있지만 여러 리모트 공간에 연결될 수 있기 때문에 별칭을 통해서 리모트를 지칭해서 명령어를 사용한다 origin

• Local : 내 컴퓨터 안에 존재하는 작업공간

case1. 이미 Github상에 Repository가 존재하는 상황

1. 리모트에 있는 코드를 로컬로 가져오기 : 원하는 폴더로 이동후 git clone 레파지토리주소
2. 클론완료후 현재위치의 하위에 프로젝트 폴더 생성됨 > 작업을 위해 하위 프로젝트 폴더로 이동
   cd 생성된폴더명
3. 클론을 하게 되면 로컬에서는 최초로 default branch에 위치해 있게 됨 (master/main)
4. git을 이용해 작업을 할때는 master branch에서 작업을 하면 안된다

   모든 작업은 항상 해당 작업을 위한 별도의 브랜치를 생성한 뒤 생성한 브랜치에서 작업해야 한다
   git branch 브랜치명

5. 브랜치 생성후 꼭 생성한 브랜치로 이동해서 작업해야한다
   git checkout 생성한브랜치명
6. 해당 브랜치로 이동 후 원하는 코드를 작성하고
   git add . git commit 실행
   커밋을 통해 작업 이력을 남겼지만 아직 리모트에서는 로컬에서 진행된 작업 이력을 모르고 있음
7. 로컬에서 작업된 진행내역을 리모트로 올린다
   git push origin 생성한브랜치명 : origin이라는 리모트의 내가생성한브랜치 에다가 내가 커밋한 작업을 올리겠다는 의미
   리모트에도 내가생성한 브랜치에 대한 작업 내용이 올라가게됨
   그러나 아직 default branch인 master 에는 내가생성한브랜치의 작업 내역이 없다
8. master 브랜치에 내가생성한브랜치 의 작업 내용을 합쳐 달라고 요청하기 위해
   PR : Pull Request 작성한다
   PR을 통해서 브랜치의 작업 내역을 확인하고 관리자 또는 다른 팀원들의 크로스 체크후 문제가 없다고 판단하면
9. 내가생성한브랜치가 master에 머지 되게 된다
   머지가 되고 나면 내가 생성한브랜치에서 작성한 코드가 origin=리모트 상의 master에 최신화되게 될것이다
   하지만 orgin master 는 최신화 되어 있지만 아직 내 로컬에 있는 master는 이 내용을 모르고 있다
10. origin master의 작업 내용을 내 로컬 master로 가져와 줘야한다
    현재 생성된 브랜치에 위치하고 있는데 git checkout master 이동하고나서
    git pull origin master 를 통해서 origin master의 내역을 내 로컬 master로 가져온다
    로컬 master의 코드 또환 최신화됨

case2. Github상의 레파지토리가 존재는 하지만 비어있어서 로컬에서 초기 세팅을 한 뒤 리모트에 올려줘야하는 상황

1. 한명의 팀원이 원하는 폴더로 이동한 뒤 CRA를 통해서 프로젝트를 생성npx create-react-app 프로젝트명하고 초기 세팅을 완료한다
2. 초기 세팅의 진행 내역을 git add . git commit 으로 기록해 준다
   아직 로컬에 있는 레파지토리는 리모트와 연결이 되어있지 않은 상황
3. 리모트를 추가해준다 git remote add orgin 레파지토리주소 : 레파지토리주소를 리모트로 추가하겠다 그리고 앞으로 이 주소를 origin이라는 이름으로 부르겠다는 의미
4. 리모트 추가 후 push를 통해 작업한 내역들을 리모트상에 올려준다
   git push origin master
   레파지토리가 github에 올라갔으므로 다른 팀원들도 github에서 clone 받아 레파지토리를 로컬에 만들 수 있게 됨
5. 팀원들은 작업할 원하는 폴더로 이동 후 git clone 레파지토리주소 진행

• node_modules directory는 용량이 크고 package.json을 통해서 패키지를 설치할 수 있기 때문에 .gitignore 파일에 추가되어 git으로 관리하지 않음
• 그래서 클론을 받았을때 패키지들은 설치되어 있지 않은 상태이다

6. 패키지를 설치한다
   npm install : package.json파일의 dependencies 기준으로 패키지가 설치되게 된다
7. 새로운 브랜치를 생성해서 생성한 브랜치로 이동 후 작업을 진행

브랜치 관리 원칙

1. 기능 단위의 브랜치 생성 후 작업

• 개발하고자 하는 기능에 따란 "feature/기능"과 같이 브랜치를 생성한다
• 기능 단위로 브랜치를 생성하고 작업을 진행하면 독립적인 공간(브랜치)에서 여러 개발자가 동시에 다양한 기능을 작업할 수 있다
• Git을 활용하면 기능별로 브랜치를 나눠서 작업한 뒤 작업이 완료되면 master브랜치에 병합하는 방식으로 작업을 진행할 수 있게 된다

2. 브랜치는 작은 단위로 나눠서 관리

• 브랜치는 작은 단위로 나눠서 관리하고 자주 병합하는게 좋다
• 만약 하나의 브랜치에서 너무 많은 작업을 진행하면, 이 브랜치에서 어떤 목적을 갖고 있는지 어떤 작업을 했는지 파악이 어렵고, 브랜치의 작업내용을 함께 확인하고 검토할 팀원들의 부담이 커짐
• 또, 너무 많은 작업을 진행하면 최종적으로 master에 병합하는 과정에서 다른 브랜치와 작업 이력이 겹쳐 발생하는 충돌이 대규모로 발생하게됨
• 이는 브랜치의 병합에 어려움을 야기하고, 독립적인 브랜치에서 작업 후 병합하는 Git을 활용한 작업방식을 제대로 활용할 수 없게 만듬

3. feature 브랜치에서 또 다른 브랜치 생성하지 않기

• git의 모든 명령어는 현재 내가 위치하고 있는 브랜치 기준으로 동작한다. 브랜치 생성 또한 마찬가지로 새로운 브랜치를 생성하게 되면 생성하는 시점에 내가 위치한 브랜치의 작업 내역(커밋)을 모두 가진 상태로 새로운 브랜치가 생성된다
• 브랜치들은 최종적으로 master에 병합되는것이 목표기 때문에 master를 기준으로 새로운 브랜치를 생성하는 것이 좋다 (의도하지 않은 작업내역이 새로운 브랜치에 포함되는 것을 막기위해)
• 추후 master병합하는 과정에서 충돌할 가능성이 커진다
• 명백히 의도하고 사용하는 경우가 아니라면 새로운 브랜치는 항상 master브랜치를 기준으로 생성해야한다