2024.03.07 12일차 Git fetch, pull & Github 협업하기

Git Fetch

원격 저장소의 최신 변경 사항을 로컬로 가져오지만, 작업 중인 브랜치에 이 변경 사항을 병합하거나 커밋하지 않습니다.

$ git fetch [remote-name]

이렇게 하면 원격 저장소의 변경 사항을 보거나, 그 변경 사항을 사용하여 다른 브랜치를 만들 수 있습니다.

여기서 [remote-name]은 어떤 원격 저장소의 데이터를 가져올지를 지정합니다.

이를 생략하면 Git은 origin이라는 기본 원격 저장소에서 데이터를 가져옵니다.

 

git fetch는 원격 저장소의 새로운 브랜치 및 데이터를 가져옵니다. 하지만, 이 명령은 기존의 작업 내역을 변경하지 않기 때문에, 현재의 작업 내역을 그대로 유지하면서 원격 저장소의 변경 사항을 확인할 수 있습니다. 이후 원격 저장소의 변경 사항을 반영하려면, git merge 명령을 사용하여 가져온 변경 사항을 현재의 브랜치에 병합하거나, git checkout 명령을 사용하여 가져온 브랜치로 전환해야 합니다.

 

 

** 깃 크라켄은 자동 fetch 설정이 있음 → preference / Auto-Fetch Interval 1minute

 

 

Git Pull

git pull = git fetch + git merge

 

git pull은 원격 Git 저장소의 변경 사항을 다운로드하고 자동으로 현재 브랜치에 이를 병합하는 Git 명령입니다.

이는 실질적으로 git fetch와 git merge 명령의 조합으로 이해할 수 있습니다.

 

$ git pull [remote-name] [branch-name]

$ git pull origin main


// git pull  (ff merge)
user@DESKTOP MINGW64 ~/Desktop/2024/remote-practice/Remote-Practice (animals)
$ git pull origin animals
From https://github.com/dazzlingtea/Remote-Practice
 * branch            animals    -> FETCH_HEAD
Updating ba47349..7638608
Fast-forward
 fish.txt | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 fish.txt

user@DESKTOP MINGW64 ~/Desktop/2024/remote-practice/Remote-Practice (animals)
$ git status
On branch animals
Your branch is up to date with 'origin/animals'.

nothing to commit, working tree clean

 

 

Git Pull과 충돌(Conflict)

⇒ 3 way merge 와 같은 해결방법

동일한 파일의 동일한 부분을 동시에 변경한 경우, Git은 이 변경 사항을 어떻게 병합해야 할지 알 수 없는 상황을 충돌(conflict)이라고 합니다.

 

** 해결법

충돌이 발생한 경우, Git은 충돌 위치에 충돌 마커를 추가합니다.

충돌이 발생한 부분 수동으로 확인 및 수정 → 병합 → 병합된 브랜치를 push

   * push까지 해야 완벽하게 동기화

   * pull 전략 | git config pull.rebase false → 3way merge

 

*** 충돌 시 깃허브에서 수정이 가능한데 가끔 불가능한 경우

      링크와 같이 실행파일이나 설정파일에서의 충돌은 아닌지 확인해보세요.

[git] gitignore - 인텔리제이 out폴더, workspace.xml

 

 

Push 하기 전에 Fetch 또는 Pull 하기

git fetch 또는 git pull을 통해 로컬 저장소가 원격 저장소의 최신 상태를 반영하도록 하는 것은 좋은 습관입니다. 이는 다음과 같은 이유로 중요합니다:

• 충돌 방지: git fetch나 git pull을 통해 로컬 저장소가 원격 저장소의 최신 상태를 반영하면, 동일한 파일을 동시에 변경하는 등의 상황에서 충돌이 발생할 가능성을 크게 줄일 수 있습니다.
• up-to-date 상태 유지: git fetch나 git pull을 통해 로컬 저장소가 항상 최신 상태를 유지할 수 있습니다. 이는 다른 사람들의 작업을 지속적으로 확인하고, 필요한 경우 자신의 작업에 반영할 수 있게 합니다.

따라서, 원격 저장소에 변경 사항을 푸시하기 전에 git fetch나 git pull을 실행하는 것이 좋습니다. 이렇게 하면 원격 저장소의 변경 사항을 로컬 저장소에 반영하고, 필요한 경우 충돌을 해결한 후에 원격 저장소에 푸시할 수 있습니다. 이는 코드의 일관성을 유지하고, 작업의 효율성을 높이는 데 도움이 됩니다.

 

 ** fetch 후 변경사항을 확인해 충돌을 방지한 뒤 pull

 

---

Github 협업하기

• Collaborator
• Centralized Workflow
• Featured Workflow

 

GitHub의 Collaborator

1. 코드 푸시 : 소유자와 동일하게 repository에 직접적으로 코드를 푸시 가능 
2. 이슈 관리 : 프로젝트의 오류 보고, 기능 추가 요청, 개선 사항 등을 관리
3. 풀 리퀘스트 관리 :
     풀 리퀘스트를 수락하거나 거절 가능
     프로젝트에 기여하려는 다른 사람들이 제출한 코드 변경 사항을 검토하고 결정하는 역할을 수행
4. Wiki 및 페이지 관리 :
     프로젝트의 GitHub Pages 및 Wiki를 관리할 수 있습니다. 프로젝트 문서 작성 및 유지 보수에 관여하는 역할을 수행

   ** collaborator는 거의 모든 권한을 주기 때문에 주의!!

 

GitHub의 README.md 파일

1. 프로젝트 설명  프로젝트의 목적과 기능에 대한 개요
2. 설치 가이드 필요한 의존성, 설치 과정, 구성 방법 등의 정보가 포함
3. 사용 방법 예제나 튜토리얼을 제공
4. 기여 가이드라인 다른 사람들이 프로젝트에 어떻게 기여할 수 있는지에 대한 지침을 제공
5. 라이센스 및 저작권 정보 프로젝트의 라이센스 정보와 저작권 정보를 명시

** README.md 은 마크다운 언어로 작성된 파일

    Markdown은 간단한 구문으로 텍스트를 서식화하고 HTML로 변환
    자세한 사용방법은 공식 문서를 참조

https://daringfireball.net/projects/markdown/syntax

Daring Fireball: Markdown Syntax Documentation

vscode로 편집할 때 우측 상단 돋보기 아이콘 preview

 

Git 중앙집중형 워크플로우(Centralized Workflow)

• SVN(Subversion) 같은 중앙집중형 버전관리시스템(VCS)
• 하나의 중앙 원격 저장소가 존재하고, 개발자들은 이 저장소에 직접적으로 변경 사항을 푸시
• 일반적으로 master 브랜치 하나만을 유지하며, 모든 변경사항을 이 브랜치에 푸시

 

  * 충돌 처리가 복잡하고 코드 테스트가 어려운 문제점이 있음

 

Feature Branch Workflow

• Git의 "branch" 기능을 활용한 워크플로우 방식
• 이 방식에서는 각 기능 개발이나 이슈 해결을 위한 작업들이 별도의 브랜치에서 진행됨
• 해당 작업이 완료되면 master 브랜치에 병합(merge)

1. 기능(feature) 개발이나 버그 해결을 위해 새로운 브랜치를 생성
2. 생성된 브랜치에서 작업을 진행하고 커밋
3. 작업이 완료되면, `master` 브랜치로 병합

 

Pull Request

• 개발자가 자신이 작업한 브랜치를 원격 저장소의 타겟 브랜치(일반적으로 master 또는 main)과 병합하는 것을 제안할 때 사용

 

1. 개발자는 새로운 브랜치를 만들고, 이 브랜치에서 작업을 수행
2. 작업이 완료되면 개발자는 작업한 브랜치를 원격 저장소에 푸시(push)
3. 원격 저장소(GitHub 등)에서 개발자는 새로 푸시한 브랜치를 기반으로 Pull Request를 생성
   이때, 병합을 요청하는 대상 브랜치(target branch)와 PR의 제목 및 설명, 관련 이슈 등을 포함하여 생성
4. 다른 개발자들이 해당 PR을 리뷰하고, 필요한 피드백을 제공합니다. 필요하다면 추가적인 수정을 요청
5. 피드백을 반영한 후, 리뷰어의 승인이 있으면 PR을 타겟 브랜치에 병합(merge)

코드를 깃 푸시한 뒤에는 pull request 를 작성해 요청

GitHub의 main branch 보호하기

중요한 브랜치를 보호하기 위한 '보호 브랜치(Protected Branch)' 기능

main 또는 master와 같은 기본 브랜치는 프로젝트의 핵심적인 부분을 담고 있으므로,

잘못된 수정이나 삭제를 방지하기 위해 보호 설정 필요

• 포스 푸시(Force Push) 차단
• 삭제 방지
• Pull Request의 리뷰 강제  
  변경사항을 브랜치에 직접 푸시하기 전에 Pull Request를 통해 코드 리뷰를 받는 것을 강제
• 상태 체크(Status Check) 통과 강제 
  테스트나 빌드 등의 상태 체크를 통과하지 않은 코드는 병합이 불가능하도록 설정

   레포지토리 룰 설정하기

1. 레포지토리의 Settings 탭으로 이동
2. 좌측 사이드바에서 Branches를 클릭
3. Branch protection rules 섹션에서 Add rule을 클릭
4. 보호하고자 하는 브랜치 이름(main 또는 master 등)을 입력하거나, 패턴을 사용하여 여러 브랜치를 선택
5. 필요한 보호 옵션을 선택하고, Create 또는 Save changes를 클릭

 

팀 협업 Workflow

01. 팀장 | organization 생성 및 팀원 초대
02. 팀장 | organiztion settings →  member privilege (read → write)
03. 팀장 | repository settings → Branch protection rules 설정
04. 팀장 | repository 생성 & README.md 등 초기 설정
05. 팀원 | 생성된 repository를 로컬로 clone
06. 팀원 | 본인 branch 생성해서 작업
07. 팀원 | 본인 branch 그대로 원격으로 push
08. 팀원 | Github에서 pull request 요청
09. 팀장 | pull request 리뷰 후 승인 & merge 또는 거절 (충돌 관리)
10. 팀원 | master/main에서 fetch로 merge 된 프로젝트를 받아와 본인 branch에서 다시 작업

 

... 이 과정을 반복하며

팀장도 본인 작업은 자신의 branch를 생성 후 해야함 (master/main에서 X)

 

 

 

 

---

+ 개인 추가 학습

실습하면서 아직 만나지 못했지만 예상되는 오류가 있다하여 추가 학습

 

Pull Strategy 

hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only

 

  * git config pull.rebase false → 3way merge

 

rebase

rebase는 브랜치의 기준을 한 커밋에서 다른 커밋으로 변경하여 마치 다른 커밋에서 브랜치를 만든 것처럼 보이게 합니다. Git은 내부적으로 새 커밋을 만들고 지정된 기준에 적용하여 이것을 구현합니다.

브랜치가 동일하게 보이지만 완전히 새로운 커밋으로 구성되어 있음

rebase

출처 https://www.atlassian.com/ko/git/tutorials/rewriting-history/git-rebase

git rebase | Atlassian Git Tutorial