Git, GitHub 기초

Bard·2022년 6월 7일
gitgithub
25

GitHub를 통해서 배워보는 기업용 파일 버전관리, 데브옵스 (DevOps)

목록 보기
1/3

본 글은 Bryant Son 님의 "GitHub를 통해서 배워보는 기업용 파일 버전관리, 데브옵스 (DevOps)" 를 듣고 정리한 포스트입니다.

Syllabus

주날짜/시간강의 내용
첫째주2022.06.07GitHub 적용 - 기본: Branching, Pull Request,
Merge, 리뷰, 양방향 커밋, atomic 커밋
둘째주2022.06.14GitHub 적용 - Advanced: Git Bisect, Git Alias, Git LFS, Git Revert,
Git Tag/Releases, Git Reset, Git Cherry Picking
셋째주2022.06.21데브옵스 입문 & 적용: 데브옵스의 개념 그리고 정의, Docker, HTML, CSS,
Javascript NodeJs 를 사용한 웹 개발
넷째주2022.06.28데브옵스 적용 - 인프라 데브옵스: Terraform, Azure, GitHub Action 를
사용한 인프라 데브옵스
다섯째주2022.07.05데브옵스 적용 - 앱 개발 데브옵스: GitHub Action, GitHub Package,
Azure 를 사용한 앱 개발 데브옵스
데모데이2022.07.12

25,000 피트 상공 위에서 보는 Git + GitHub

Git 이란?

  • Git 은 오픈소스
  • Branch: Git에서 중요한 컨셉 중 하나
  • DVCS: 분산 버전 관리 시스템
  • Remote + Local

DVCS인 Git 과 CVCS 의 차이

Git은 사진을 찍는 듯한 Snapshot으로 저장

Github란?

  • GitHub는 Git을 베이스로 한 플랫폼
  • 다양한 협업 기능이 있다.
  • 7500만 개발자 사용 (2021)
  • GitHub Action (DevOps)
  • GitHub Package (Image Registry)
  • GitHub Discussion (Q&A)
  • GitHub Package (프로젝트 관리)
  • 등등 ...

GitHub Repository

Repository란?

깃허브에서 파일을 저장하고 다양한 협업 기능을 제공하는 공간

Activity: Repository

마크다운 파일이란?

HTML, XML 같은 메타 텍스트 파일. 깃허브는 이 파일 포멧으로 다양한 문서 작업이 가능.

README.md란?

마크다운 포맷으로 되어 있는 가장 기본적인 깃허브 파일.

Activity: Markdown

.gitignore 파일이란?

제일 앞 . 으로 알 수 있듯, 컴퓨터에선 숨겨진 파일이지만 깃허브 레포에선 보여지며 패턴에 매치되는 파일/디렉토리는 깃허브 레포에 올려지는 걸 방지할 수 있습니다.

.github 디렉토리는?

GitHub에서 인식하는 특별한 목적의 디렉토리이며 깃허브 액션. CODEOWNERS 등 다양한 설정 관련 파일들이 들어갈 수 있습니다.

  • CODE_OF_CONDUCT.md: 올바른 행동/관리에 대한 설명
  • CONTRIBUTING.md: 프로젝트에 기여할 수 있는 방식을 설명
  • FUNDING.yml: 스폰서/도네이션 받는 오픈소스 프로젝트에 유용
  • ISSUE_TEMPLATE: 깃허브 이슈를 일정한 포맷으로 만들어 줄 수 있는 Template을 저장하는 디렉토리
  • PULL_REQUEST_TEMPLATE.md: Pull Request를 일정한 포맷으로 만들어 줄 수 있는 Template을 저장하는 디렉토리
  • stale.yml: GitHub Probot 관련 설정 파일
  • SECURITY.md: 보안 관련 정보를 설명하는 파일
  • workflows: 깃허브 액션 파일을 저장하고 인식하는 디렉토리
  • CODEOWNERS: Pull Request를 할 때 자동으로 Reviewer를 더할 수 있는 특별 파일
  • dependabot.yml: Dependabot을 사용해서 의존성 관련 스캔 해주는 파일

Activity: 개인 깃허브 리포 파일 추가 + 업데이트

Git Branch란?

브랜치는 독립적인 워크스페이스/공간

다른 브랜치에게 영향을 안 주는 독립적인 워크스페이스/공간 개념

Github 시작에서 Merge까지 Step-by-step

Step 1: main/master 브랜치에서 시작

Step 2: 브랜치 만들기

브랜치는 저장이 될 때 카피가 아니라 포인터 식으로 레퍼런스를 주는 개념

Step 3. 커밋하기

파일을 변경한 후 commit을 합니다.

Step 4. Pull Request하기

Pull Request의 시작은 완벽하지 않아도 됩니다. 계속 이야기하면서 협업하기 위한 과정

Step 5. Pull Request에서 리뷰 및 토론

Step 6. Ship 🐿

Step 7. Merge

브랜치 작명의 예

  • main/master: 디폴트 브랜치. Branch Protection으로 안전하게 보호하고 직접적인 merge는 가능하지 않도록 설정
  • development 브랜치나 다른 stage 브랜치: DevOps 모델을 따라서 DEV. UAT. PROD 식으로 브랜치를 모델링. 예를 들어 main 브랜치는 dev나 uat 브랜치에서 다 테스팅하고 prod/release 브랜치에 안전하게 배포된 후 merge
  • feature-xxx: 새로운 기능을 추가할 때 사용. 하지만 main/master 브랜치에 직접 merge는 불가능하도록 설정. JIRA같은 프로젝트 매니지먼트 태스크에 연동 가능
  • hotfix-xxx: Production 환경에서 중요한 에러나 버그를 고치기 위한 브랜치. feature 브랜치에 마찬가지로 JIRA 같은 프로젝트 매니지먼트 태스크에 연동 가능.

다양한 Git Branch 모델

Git Branch 모델 #1: GitHub flow

main 브랜치와 feature 브랜치만 존재함

장점:

  • 가장 간단한 워크 플로우

단점:

  • 버그나 문제가 자주 일어날 수 있음
  • 큰 팀에 적합하지 않음

Git Branch 모델 #2: GitLab Flow

깃허브 플로우와 비슷하지만 배포를 위한 production 브랜치가 따로 있음

장점:

  • 깃허브 플로우의 단점을 보완하지만 간단한 플로우

단점:

  • 역시 실제 클라우드 모델에 쓰기엔 단점이 있음

Git Branch 모델 #3: Trunk-based

정해진 지속되는 브랜치가 있고 같은 main 브랜치에 merge

장점:

  • 브랜치 매니지먼트가 필요없고 간단하게 브랜치 사용 가능
  • Accurev. ClearCase에서 온 팀에겐 가장 근접

단점:

  • 깃의 기본적인 브랜치 개념을 따르지 않음

Git Branch 모델 #4: Git Flow

기업에서 가장 많이 쓰는 브랜치 모델.
main 브랜치에서 변화는 hotfix 브랜치만 가능하고 feature 브랜치는 development 브랜치로 merge

장점:

  • 가장 기업 변화에 유연한 모델

단점:

  • 복잡함

Clone, Fork 란?

Fork란?

  • 한 깃허브 리포지터리에서 본인 어카운트나 소속된 Organization에서 새로운 리포지터리로 카피하는 개념
  • 오픈소스에서 주로 사용되지만 기업에선 선호하지 않는 방법
  • 예 #1: 리눅스의 많은 종류가 Fork된 리포
  • 예 #2: Sun Microsoft System 이 Hudson이란 데브옵스 툴을 가지고 있었는데 Oracle이 Fork를 해서 따로 개발. 얼마 뒤 나중에 Oracle이 Sun을 인수하면서 자신들이 라이센스를 가지고 있다고 우김. 원조 Hudson은 Jenkins로 이름을 바꿈. 그리고 Oracle의 Hudson은 후에 관리 포기.

Clone이란?

  • 한 깃허브 리포지터리에 있는 파일들을 본인 컴퓨터로 카피하는 개념
  • 클론된 리포는 또 다른 하나의 git 파일 시스템
  • git remote -v를 통해 origin 링크 확인 가능

필수적으로 배워야 할 Git 명령어

Git이 Github와 이야기하는 방법

2 Stage Commit

  • Step 0: 아무런 변화가 없음

    workingstaginghistory

  • Step 1: 새로운 파일이 만들어 졌거나 변경

    workingstaginghistory
    new
    ✨ ✨
    modified
    ✨ ✨ ✨

  • Step 2: git add 명령어를 사용해 staging

    workingstaginghistory
    ✨ ✨
    ✨ ✨ ✨

  • Step 3: git commit을 사용해서 커밋 함

    working staging history
    ✨ ✨
    ✨ ✨ ✨
profile
Bard
The Wandering Caretaker
다음 포스트

웹앱, 클라우드, 컨테이너

4개의 댓글

comment-user-thumbnail
JISEUNG
2022년 6월 7일

기초에 대해 잘 공부하고 가네요.. 👍 다음 시리즈도 기대할게요!

답글 달기
comment-user-thumbnail
정현수
2022년 6월 7일

github 디렉토리 내용은 잘 몰랐었는데 새롭게 알아갑니다..!

답글 달기
comment-user-thumbnail
Jeongmin Yeo (Ethan)
2022년 6월 8일

요새 gitflow 는 별로인 것 같아요.. CD (Continuous Delivery) 측면에서 불편합니다. 새로운 전략 없을까요

1개의 답글