Git workflow

1. 4명이 개개인의 feature-issue-#[number]라는 branch를 만든다.
   
   

2. 코드를 작성하고 자신의 feature-issue-#[number] 의 branch에 push 한다.
   
   

3. develop branch에서 feature-issue-#[number]를 합친다.

4. 개발이 어느 정도 완성이 되면 relesase branch 에 올린다. 여기에서는 버그만 잡는다.

5. 버그를 다 잡으면 master branch 에 올린다 => 배포

   • 기능 추가했다고 배포하는게 아니라 버전을 계속 만드는 것

• hotfixes : master 에 올렸는데 갑자기 버그가 발생할 경우,

  hotfixes branch를 임시로 만들어서 버그만 잡고 master에서 다시 배포
  

Git forking repository

1. 원본 깃허브를 복사해서 내 계정의 repository( 복사본 폴더 fork )를 만든다

   = 원본을 fork 한다. (원본에 대한 안정성 유지)

- 원본 계정만 본체에 직접적으로 `push` 할 수 있다. 팀원은 본체에 직접적으로 `push` 할 수 없다.

2. fork 뜨고 feature branch를 만든고 기능구현 각자의 vscode에 $git clone _자신 레포지토리의 fork한 어드민 레퍼지토리 주소_ 한다.

3. feature branch를 만들고 기능 구현하고 코드를 만든다.

   1. feature branch를 복사본(fork)에 push를 한다.

4. 원본에 pull request(pr) 한다. (= 원본계정에 올리는 과정)
   

5. 팀장이 팀원이 pr한 feature를 합쳐줘야한다(merge). => 다음 날 아침에 합치기. 회의하면서 문제될 부분 빼고(close) 합친다.

   • 문제 될 만한 코드 거르기
   • 자신이 고민한 코드 공유하기 (이게 더 좋은 방법)

6. merge를 하면 원본 GitHub 업데이트된 상태. 각각의 팀원의 feature-issue-#[number] 는 업데이트가 된 코드가 아님.

    => 원본의 업데이트된 코드를 `pull` 한다.

   
   
7. 반복. 오늘 만들 기능 feature-issue-#[number] branch 만들고 여기에 기능 구현 => fork에 push => pr 날린다.

• 하루에 여러가지 feature 만듬. pr 만 보냈지 원본에서 merge 한 상태가 아니다. boardWrite가 만들어지지 않은 상태로 boardUpdate를 만든 것임.
  

• 중복되는거, 순서가 있는거 같이 만들면 안된다. => 등록/수정 같이 만들어서 pr 로 올려야한다. 등록만들고 등록 기반으로 수정만드는 pr 두번 올리면 안된다. 한명이 게시물 만들면 한명은 상품만들고 한명은 리뷰 말들고 다 다른거를 만드는게 좋음
• 반드시 1일 1 커밋
• 로그인같이 모두 영향 받는 것은

Git 원본 계정 repository 생성 방법

1. vscode에서 생성
   
2. 원본 repository 만들기
   
   
3. 생성한 repository 로 들어가서
   
   
4. $ git remote -v 하면 아무것도 없음
   
   

• error: ~ some refs ~

Git 팀원 계정

1. 내 계정 fork
2. 내 repository에서 원본계정 폴더에 들어가서 코드를 복사

3. vscode에서 $ git clone 복사한 주소

4. 아무것도 안한 상태: main branch 만 존재
   

5. $ git checkout -b feature-issue-#이슈번호 : branch를 만들어서 checkout( feature-issue-#이슈번호 로 이동한다) = 만들어서 이동한다.
   
   

6. 원본계정 페이지로 간다. => Issues 페이지: 내가 할 일 여기다가 적기 => New issue
   

7. Issue 에 내가 할일 적기
   

8. Issue number 가 자동으로 생성된다.
   

9. 내 issue 번호 복사 => vscode 이동 => branch 생성
   

   • -b : 현재 branch가 없는데 ‘feature-issue-#5’ branch를 만들고 checkout 이동한다.

   명령어 확인
   

   • ‘feature-issue-#5’ 에서 코드 만드는 것과 ‘master’ 에서 코드 만드는 것은 다른 공간에서 만드는 것

10. 새로운 파일을 생성. 이 파일의 위치는 ‘feature-issue-#5’ 이다.
    

    • 이미 존재하는 branch 는 checkout 으로 이동한다.

    • $ git log: 잘 저장 됐는지 확인하는 명령어

    만약 master 로 돌아간다면 five 파일이 존재하지 않는다.
    

    commit을 하면 checkout한 branch 에 저장된다. 그 branch를 push 한다. => 내가 fork한 git 에 push

11. git remote -v : 잘모르겟는데 그 git branch들 목록이 나온다. $ git push origin feature-issue-#5 해준다. => pr에서 new pull
    

    • 팀원은 develop 에서 하는게 아니고 개개인이 만든 feature~ 에 하는것. git에서 pr 날릴 때는 꼭 develop으로 해야한다!! ? 선생님이 develop 만는거???
      

회의 할 때 pull request 보면서

팀장이 합칠 때 Merge pull request

• develop만 키우다가 -> 배포하기 전에 release branch 만들어서 버그 잡고 -> develop version2를 만들어서 두개로 가는거

1. merge 된 원본(업데이트된 상태)을 pull 받아야한다. 그 전에 develop branch를 pull 받아야한다. develop으로 이동한다. 명령어 확인
   
   • 바로 pull develop 하면 안된다. 자기꺼에서 받아와진다. 원본 = upstream
     
2. 현재 origin 밖에 없으니까 upstream 을 만들어야한다!!!!! 명령어 확인
   아침에 받을 때는 꼭 upstream에서 땅겨와야한다.
   
3. git pull upstream develop
   합치게 되면 commit message 입력하는건데 안해도 되고 끄는거는 :wq 입력하면된다.
   :wq 하면 아래로
   pull 결과 확인