Git 과 Github

Git 이란

• 분산 제어 버전 시스템이다.
• 분사 제어 버전 시스템이란 전체 저장소의 로컬 복사본을 모든 팀 구성원의 컴퓨터에 저장한 다음, 로컬에서 커밋 분기 병합할 수 있도록 한 시스템이다.
• 그래서 서버와 클라이언트간 동기화 한다는 느낌이고, 물리적 파일들 모두 동기화할 때 해당 파일들을 object 폴더 아래 저장 관리한다.

 

Branch(분기)

https://digitalvarys.com/git-branch-and-its-operations/

• 코드를 통쨰로 복사하고 원래 코드와는 상관없이 독립적으로 개발을 진행하는 것을 말한다.
  • 예를 들어, 개발자 2가 파일 2와 파일 4에 기능 추가 기능 및 수정한다고 하면 마스터 브랜치에서 새로운 브랜치를 생성한 다음 파일 2와 4를 추가 및 수정한다.(파란색 부분 Feature-2) 이때, 개발자 2이 건드는 작업은 서버에 저장된 원래 코드에 아직 반영되지 않았다.
  • 보라색 부분은 개발자 1은 파일 1과 파일 2를 기능 추가 및 수정한다면 하면 이 사람 또한 저렇게 마스터 브랜치에서 브랜칭하여 파일 1과 2를 변경한다. 물론 원본 서버 파일에는 반영되어 있지 않다.
  • 최종적으로 마스터 브랜치와 병합될 때 변경된 부분만 마스턴 브랜치에 추가된다.

 

Merge(병합)

 

https://www.geeksforgeeks.org/git/git-merge/

• 서로 다른 브랜치의 변경 사항을 하나의 브랜치로 결합하여 작업 내용을 통합하고 이력을 보존하는 기능

3-way Merge

https://docs.gearset.com/en/articles/9325332-two-way-and-three-way-merges-explained

• 두 브랜치를 합칠 때, 두 브랜치의 공통 조상이 존재하는 경우
• 비교 대상 3가지:
  • 1. Merge Base: 공통 조상 커밋의 파일 상태 (기준점)
  • 2. Source: 내가 가져오려는 브랜치의 파일 상태 (예: Feature 2)
  • 3. Target: 현재 내가 있는 브랜치의 파일 상태 (예: Feature 1이 이미 반영된 UAT)
• 특징: 기준점(Base)이 있기 때문에, Git은 양쪽 브랜치에서 "누가, 어느 라인을 어떻게 수정했는지" 명확하게 추적 가능
  • 만약 서로 다른 라인을 고쳤다면 Git이 알아서 자동으로 합쳐주고, 같은 라인을 고쳤을 때만 충돌을 일으킨다

 

Two-way Merge

https://docs.gearset.com/en/articles/9325332-two-way-and-three-way-merges-explained

• 두 브랜치를 합쳐야하는데 히스토리를 거슬러 올라가도 해당 파일의 공통 조상 커밋이 없는 경우
  • 비교 대상 2가지:
    1. Source: 가져오려는 브랜치의 파일 상태 (예: Feature 2)
    2. Target: 현재 브랜치의 파일 상태 (예: Feature 1)
• 특징: 주로 서로 다른 브랜치에서 우연히 같은 이름의 새로운 파일을 만들었을 때 발생
  • 기준점이 없기 때문에 Git 은 이 파일이 원래 어떤 형태였는지 모른다.
  • 자동으로 합쳐주지 못하고 무조건 두 파일의 차이점을 사람이 직접 보고 고르도록 충돌을 띄운다.

 

Fork & Clone

• fork
  • 기존 저장소를 복사하여 새 소유자가 이전 커미터들의 코드베이스와 분리하여 다른 깃헙에 옮겨 복사 붙여넣기한다는 개념. 실제로 이러한 명령어는 존재하지는 않음. 
  • 특징
    
    • 소유자가 포크된 저장소에 접근 권한을 이전 기여자들에게 부여하지 않는한  새 저장소에 코드를 커밋할 수 없다.
• clone 
  • 특정 저장소 또는 저장소 내 특정 분기의 복사본을 로컬에 만드는데 사용하는 명령어
• 뭔가를 복제하는 명령어는 clone밖에 없다.

 

Github 이란

• Git을 기반으로 구축된 클라우드 기반 스토리지 솔루션
• Git에 협업, 프로젝트 관리 및 워크플로 자동화를 위한 추가 도구가 더해진 버전
  • 클라우드 기반 저장소: 로컬에 저장되는 Git과 달리 GitHub는 저장소를 온라인에 저장하므로 어디서든 접근할 수 있다.
  • CI/CD 통합: GitHub Actions 및 타사 도구를 사용하여 테스트, 배포 및 워크플로를 자동화가능하다.
  • 보안 및 백업: GitHub는 저장소 백업, 접근 제어, 그리고 비밀 키 스캔 및 Dependabot 알림과 같은 보안 기능을 제공한
  • 커뮤니티 및 발견: 개발자는 GitHub에서 오픈 소스 프로젝트를 쉽게 공유하고, 기여하고, 발견할 수 있다.
  • 다른 도구와의 통합: GitHub는 Slack, Jira, VS Code와 같은 플랫폼과 원활하게 연결되어 더욱 효율적인 개발 워크플로를 지원한다.

 

Pull Request

https://oboacademy.github.io/obook/howto/github-create-pull-request/

• 자신이 했던 작업을 main 저장소 코드 변경 사항을 병합할 준비가 되었음을 알리는 행위
  • 변경된 제안사항을 논의 검토 후 변경 사항을 기본 브랜치에 병합 가능

실습

 

• 래포 하나 생성한 다음,

• 현재 main이 가리키는 커밋을 그대로 복사해서 새 brach를 생성한 다음, 작업 공간을 새 brach로 이동(git checkout -b feature/add-test-file)
  • checkout(구버전) -> switch(신버전) 
• 현재 저장소에 존재하는 브랜치 목록 리스팅 (git branch)

• test.txt 파일 다음 커밋에 포함(git add week-2/test.txt) - 변경 사항 후보에 올림
• On branch feature/add-test-file - 작업 중인 브랜치( feature/add-test-file )
• Changes to be committed - 커밋될 예정인 변경사항 -> week-2/test.txt
• new file: week-2/test.txt - 변경 파일이 아닌, 새로 만든 파일인 week-2/test.txt

• git commit -m "Add test file" : Staging Area에 있는 변경사항을 하나의 스냅샷(버전)으로 저장하는 것( 이번 버전의 이름은 'Add test file'이다)
• git push -u origin feature/add-test-file : 로컬 -> github으로 업로드

• 생성된 branch 확인 및 pull request 확인

• 요청하고 나면, Merge pull request 버튼이 나오고, 해당 버튼을 누르면
• feature/add-test-file 브랜치의 변경사항을 main 브랜치에 병합하는 절차가 시작
• feature/add-test-file → main

• Confirm merge를 누르면

기존 main

• 기존 main 에는 없는 test.txt 파일

 

feature/add-test-file/week-2

• feature 브래치 안에 test.txt 파일

• main branch에도 test.txt 파일 생성에 대한 변경 사항이 반영됨을 확인.

 

 

출처

https://nulab.com/learn/software-development/git-vs-github/

Git vs GitHub: What’s the difference? | Nulab

https://docs.gearset.com/en/articles/9325332-two-way-and-three-way-merges-explained

Two-way and three-way merges explained | Gearset Help Center

https://www.geeksforgeeks.org/git/git-merge/

Git Merge - GeeksforGeeks

 

https://oboacademy.github.io/obook/howto/github-create-pull-request/

Create a GitHub Pull Request - OBO Semantic Engineering Training