💻Git 3주차 총정리(1)💻

✔ fork

 - 내가 주인이 아닌 다른 repo에 PR하려면 Fork(일종의 프로젝트 복사)가 필요하다!
 - repository의 사용권한이 다른 사람에게 있을 때, 예로 많은 사람들이 참여하는 오픈 소스처럼, 내가 
  소유하고 있는 repo가 아니더라도 프로젝트 제안할 때는 일단 프로젝트의 내용을 내 공간으로 가져와야
  한다.
 - fork는 원본 소스코드를 복사해서 새로운 독립적인 software로 개발하는 것을 이야기한다. 마치 어떤 
  문서를 복사해서 그 위에 내가 원하는대로 수정해서 사용하는 것과 비슷하다.

   [Fork]

                                   🟥 (나/Repo)

                      <fork> ↙      ↘<fork>

                          🟥              🟥
                     (김씨/Repo)     (이씨/Repo)

 - 오픈소스에 기여할때는 fork해 온 후, PR을 한다. 프로젝트에 이 오픈소스에 기여하는 방법 가이드도 
  있다.단, Github에 있는 모든 프로젝트가 PR을 받는 것은 아니니 관리하는 사람 마음대로라서 주의!
 - 다른 repo에서 PR하기도 fork를 하고 나서 이후 과정은 같은 repo에서 PR하기 와 유사하다.
 - 단, 내가 merge할 권한이 없으므로 repo관리자의 merge pull request를 기다려야한다.

✔ PR

 - PR(Pull Request) : 내작업내역을 바로 merge하지 않고, 참여하고 있는 프로젝트에 내 branch를 merge
         해달라고 request를 먼저 보는 것을 말한다.

[PR 과정]

  🔴(특정 commit) →   →   → 🔴(main branch)

    ↘     ↗ [PR(Merge해도 되나요?)]
       ● → ● → ● → ● 
   (cmt01)(cmt02)(cmt03)(cmt04)


 - 작업한 내용에 대해 코드 리뷰를 하거나 같이 토론하면서 개선시킬 수 있는 기회가 생기는 것이다.
  프로젝트 기준에 맞지 않는다면 PR은 reject(거부) 될 수도 있다.

  🔴(특정 commit) →   →  (main branch)
       ↘
           ● →  ●  →  → ● (project branch)
                    ↓
  
     [PR 하기전 토론해서 개선사항을 주고 받기]
      1. 프로젝트에 이런 것을 추가하고 싶어요!
      2. 추가전에 테스트를해보고 말씀해주세요!


 - 리뷰한 후 작업내역을 최종적으로 반영하면 된다. 또 기본적으로 프로젝트 품질을 관리해야하는 회사에
  서 작업하거나, 여러 사람들이 참여하는 오픈소스에서는 PR후 merge하는 과정을 거치게 된다.


  🔴(특정 commit) →       →       →  🔴(main branch)
       ↘           ↗
         ● →  ●  →  → ● →  →  
                    ↓     ↪ [merge를 하고 PR에 반영]
  
     [PR 하기전 토론해서 개선사항을 주고 받기]

 - 내가 참여하고 싶은 오픈소스 프로젝트가 있다면 코드를 작성해서 내 코드를 반영할 수 있는지 의사를
  물어본다. 그리고 PR을 해보는 것도 있고 내가 다른 사람 소스를 사용하는 것을 넘어서 프로젝트에 참여를
  할 수 있다는 것이 큰의미가 부여된다.
 - 좋아하는 책에 저자로 참여할 수 있는 일이 개발 세계에서 일어나고 있고 Github repo의 contribution
  페이지에 기여한 사람들 정보를 적어두기도 한다.
 - 같은 repo안에서 branch를 바로 merge하지 않고 PR한 후에 검토를 받고 merge하는 것을 말한다.

 - PR은 branch를 바로 merge해서 프로젝트에 반영하는 것이 아니라 반영을 request후 merge할지 말지가
  결정된다.

       🟥 🔴  →  🔴  →  →   🔴
 (remote repo)            ↘    ↗ [PR(merge)]
                                 🔴(project branch)

    🔽 [Pull]

       💻 🔴  →  🔴  →  →  🔴 (Merge branch 'branch name' into main)
  (local repo)            ↘
                                🔴(project branch)

 - branch 삭제하는 이유?
  1. PR이 완료된 후에 local repo의 branch를 삭제하는 것은 이전에도 branch는 작업을 다하고 main 빼고
  는 해줘야지만 충돌을 방지 할 수 있다. 또한 필요없는 branch를 남겨두는 것을 좋지 않다.
  2. PR은 리뷰하는 과정을 통상적으로 포함한다. PR후에도 추가적으로 commit을 하는 경우도 있다.
  3. 리뷰에서 추가 수정을 요청받거나
  4. PR을 그대로 merge한다고 했을 때 merge conflict가 나는 것을 미리 고치는 것
  5. 수정제안을 받았을때, local repo의 'branch'에서 commit후, remote repo의 'branch'에 push하는 것
  이 통상적이다.

     [PR전 branch삭제를 왜 마지막 검토후 하는지?]
      🟥
(remote repo) →                 →               →  🔴(Merge branch 'branch name' into main)

     💻                     ↗ [PR요청!](1)      ↗
(local repo) →         🔴           →        🔴[최종적으로 PR을 함](2)      
   ↓
                    [추가사항 발생]
 [최종적으로 작업발생!]

 

✔ amend

 - commit 실수 하면 기본적으로 나만 작업하는 특정 branch 하나에만 적용해야한다! 그렇지 않으면 작업
  하던 사람들의 commit까지 날라간다! 주의!!
 - 작업중 commit 메시지에 오타 났거나 파일을 add(staging)할때 최신의 commit을 수정하는 것을 amend
  (어맨드, 고치기)라고 한다. amend로는 가장 최신의 commit만 고칠 수 있다는 것을 알아두기!

[amend]
 → 🔴       →      🔴
  (cmt01)   (cmt02)
    ↑         ↑
[amend로 못고침!]    [여기에서 amend로 수정가능!]
   
 - push후에도 push한 commit을 되돌릴 수 있다. 강제로 commit을 덮어씌우는 것과 같습니다! force push
  (강제 푸시)라고 한다.

✔ revert

 - amend로 되돌리기는 가장 최신의 commit만 되돌릴 수 있다. 그리고 어떤 걸 되돌렸는지도 알 수 없다.
 - 다른사람들과 같이 협업하고 있다면 어떤 내용이 되돌려졌는지 기록으로 남기는 것도 중요합니다.
  어떤 내용을 되돌렸는지 새로운 commit을 남기는 것을 revert라고 한다. 최신 commit뿐만 아니라 이전에
  했던 commit도 revert로 되돌릴 수 있다.

[revert]

🔴  →   🔴    →     🔴
     (cmt01)         (cmt02)       (cmt01 add! [revert])
        ↑

     [revert]하고 싶을때!


✔ reset

 - commit했던 작업내역을 말 그대로 reset시키는 것이다. 과거로 돌아가서 새로운 삶을 사는 것처럼 reset
  이후에 작업내역은 없어진 commit기록과 관계없다!

[reset]

🔴  →   🔴    →     🔴
     (cmt01)         (cmt02)          (cmt03)
            ↑

  [여기로 기록 되돌리고 싶다면?]

            ↓ [reset]

🔴 X→   🔴    X→     🔴
     (cmt01) (cmt02)          (cmt03)

 ※ 즉 cmt02, cmt03은 사라진다!! 다시 cmt01에서 새로 시작한다는 소리임!!

 - reset에는 세가지 모드가 있다.
  1. soft : head, branch에 이동만 한다. 즉, 안전하게 한다는 소리! 상태는 변함! 단 삭제되고 변화는
   없음!
  2. mixed : 이전으로 되돌아가는 것
  3. hard : 작업한 것을 모두 날리는 것

✔ stash

 - 숨겨두거나 넣어둔다라는 뜻이 있다. 프로젝트의 변경사항을 임시적으로 보고나해둘 때 사용합니다.
  다른 branch로 checkout하는 경우 현재 branch의 변경상항이 사라지게 됩니다. 아직 작업중이라 commit
  하지 않고 변경사항만 보관해두고 싶다면 이때 commit대신 stash를 사용합니다.
 - commit하지 않은 파일이면 굳이 stash할 필요없다!
 - stash는 말그대로 여러 변경사항을 임시 저장이라고 생각해라!
 - 여러번 stash했을 경우, 내가 수정한 내역이 이곳저곳에 흩어져 있어서 자칫하다가 작업내용이 날라갈
  수 있다는 점! 어떤 변경사항 stash를 저장했는지 파악하고 되도록이면 이전 stash에서 편집하던 파일을
  불러와서 작업하는 습관을 들이면 좋다!

✔ 작업으로 의사소통

 - commit으로 소통(메시지, 단위)
 1. commit메시지도 작성하는 규칙이 있다. 각 조직마다 commit 메시지 컨벤션이 있다. 프로그래밍 세계에
  서 서로 조직에서 합의한 규칙을 convention이러고 부른다.
 2. commit 메시지를 어떻게 작성해야하는지 정한 것이다.(규칙!)
 3. commit하면 다른 사람이 알기 쉽게 실제 개발 환경에서 기능을 구현하기 위해서 하나의 commit에 여러
  파일이 들어간다. 만약 파일명만 적어둔다면 코드를 하나하나 읽어야 하는 사태가 벌어진다. 그러지 않
  기 위해서 commit 메시지를 적는 것이다. 하나의 약속!

[convention 중요성]

→→→→→→→→→→→→→→→→→→ [main branch]
                       ↗ PR
→→ 🔴 →→ 🔴 →→→→→→→→ 🟥 [PR Reject!]
  1. A파일 추가
  2. B파일 업데이트  ↓
                           ↓
PR담당자 : 어떤 작업 하신거에요?
개발자 : .......;;

 - commit단위도 중요하단점! commit의 단위는 내가 기록하는 작업의 단위이다. 스타일마다 틀릴 수 있지만
  commit단위에는 일관된 규칙이 있는게 좋다. 또 나중에 버그를 찾기 위해서 작업 기록을 볼 때 단위가
  잘 나누어져 있으면 금방 찾기 쉽기 때문이다.
 - 즉, 가장 작게 쪼갠다면 기능 단위로 commit해서 웹사이트를 개발할때, 메뉴바를 개발하고 commit, 카카
  오 로그인 기능을 개발하고 commit하는 식이다.
 - 아니면 issue 단위로 commit을 할 수 도 있다!
 - 좋은 commit메시지, 단위로 작성하게 되면 어떤 작업을 했는지 commit history만 봐도 알 수 있고, 
  버그를 찾을 때도 코드를 고치기 쉽고, 다른 사람이 코드를 리뷰할 때 편하단 점!