[Git, Github] 깃과 깃허브 비교

Git

• 분산형 버전관리 시스템이다.

Github

• 깃으로 버전 관리한 코드들을 공유할 수 있고, 협업 할 수 있는 원격 저장소

Git의 역할

• 파일의 버전 관리(파일의 변경이력을 관리)
• 브랜치를 이용하면 완전히 구분되는 별도의 소스 작업영역을 만든다.
• 파일 변경이력정보가 사용자의 컴퓨터에 저장된다.(로컬저장소에 저장된다.)
• github와 같은 원격저장소를 활용하면 다른 개발자와 소스공유가 가능하다.

Git 설정하기

명령어실행내용

git config --global user.name "사용자명"	git의 전역 사용자명 등록
git config --global user.email "이메일"	git의 전역 사용자의 이메일 등록
git config --global --list	git 전역 설정 정보 조회

Git의 작업흐름

https://www.youtube.com/watch?v=Z9dvM7qgN9s

• Git의 로컬 저장소는작업디렉토리(Working directory),인덱스(Index),스냅샷(Commit)으로 구성된다.
  • Working directory : 실제 파일들이 존재하는 디렉토리다.
  • Index : 스냅샷에 대한 준비영역(Staging area)이다.
  • Commit : Index에 추가된 파일을 로컬 저장소에 반영한다.
• Git는 작업 디렉토리의 모든 파일을Tracked(관리대상 파일이다)와Untracked(관리대상 파일이 아니다)로 나눈다.
• Tracked 파일은 이미 스냅샷에 포함돼 있던 파일이다.
• Tracked 파일은 Unmodified(수정하지 않음)와 Modified(수정함) 그리고Staged(커밋하면 저장소에 기록되는 파일) 상태 중 하나다.
• Untracked 파일은 스샙냣에 포함돼 있는 것도 아니고,Staging Area에 있는 것도 아닌 상태다.
• 작업 디렉토리에서 새로운 파일을 생성하면UnTracked상태다.
• git add를 실행하면 해당 파일은Tracked상태이면서Staged상태가 된다.
• git add를 실행한 후 파일을 다시 수정하면Unstaged상태가 된다.
• Commit을 실행하면git add를 실행한 싯점의 파일이 커밋되어 저장소 히스토리에 남는다.

명령어실행내용

git init	새로운 git 저장소를 생성한다
git status	파일의 상태를 확인할 수 있다.
git clone <저장소URL>	원격 서버의 저장소를 복제한다.
git add <파일명>	변경된 파일을 인덱스에 추가한다
git add *	변경된 모든 파일을 인덱스에 추가한다
git commit -m "<이번 확정본에 대한 설명>"	변경된 내용을 확정하고 로컬 저장소에 반영한다

변경 내용 발행하기

• 로컬 저장소의 변경 내용을 원격 서버로 발행할 수 있다.

명령어실행내용

git remote add origin <원격 서버 주소>	새로운 원격 저장소를 추가한다
git push origin master	변경된 내용을 원격 저장소로 보낸다

브랜치 관리하기

• 브랜치는 안전하게 격리된 상태에서 개발을 진행할 때 사용한다.
• 로컬 저장소를 새로 만들면 기본으로master브랜치가 만들어진다.
• 새로운 브랜치를 생성하면, master 브랜치와 안전하게 격리된 상태에서 개발을 진행할 수 있다.
• 새로운 브랜치에서 개발이 완료되면 master 브랜치로 돌아와 병합한다.

명령어실행내용

git checkout <브랜치>	다른 브랜치 체크아웃한다
git checkout -b <브랜치>	현재 브랜치에서 새로운 브랜치 생성하고 체크아웃한다
git merge <브랜치>	브랜치의 변경내용을 현재 브랜치에 병합한다
git branch -d <브랜치>	브랜치 삭제한다

갱신과 병합하기

• 로컬 저장소를 원격 저장소에 맞춰 갱신할 수 있다.

명령어실행내용

git fetch	원격 저장소의 최신 내용을 받아온다.
git pull	원격 저장소의 최신 내용을 받아온 후 즉시 현재 브랜치에 병합한다

• pull과 fetch의 차이는 merge를 수행하는가, 수행하지 않는가의 차이다.
• pull은 최신 내용을 받아온 후 즉시 병합하기 때문에 충돌이 발생할 수 있다.

tag 달기

• 태그를 사용하면 소프트웨어를 버전별로 관리할 수 있다.

---

Git Flow 와 Github Flow

1. Git Flow

가장 최초로 제안된 Workflow 방식이며, 대규모 프로젝트 관리에 적합한 방식으로 평가받는다.

기본 브랜치는 5가지다.

• feature → develop → release → hotfix → master

 

 

Master

릴리즈 시 사용하는 최종 단계 메인 브랜치

Tag를 통해 버전 관리를 한다.

 

Develop

다음 릴리즈 버전 개발을 진행하는 브랜치

추가 기능 구현이 필요해지면, 해당 브랜치에서 다시 브랜치(Feature)를 내어 개발을 진행하고, 완료된 기능은 다시 Develop 브랜치로 Merge한다.

 

Feature

Develop 브랜치에서 기능 구현을 할 때 만드는 브랜치

한 기능 단위마다 Feature 브랜치를 생성하는게 원칙이다.

 

Release

Develop에서 파생된 브랜치

Master 브랜치로 현재 코드가 Merge 될 수 있는지 테스트하고, 이 과정에서 발생한 버그를 고치는 공간이다. 확인 결과 이상이 없다면, 해당 브랜치는 Master와 Merge한다.

 

Hotfix

Mater브랜치의 버그를 수정하는 브랜치

검수를 해도 릴리즈된 Master 브랜치에서 버그가 발견되는 경우가 존재한다. 이때 Hotfix 브랜치를 내어 버그 수정을 진행한다. 디버그가 완료되면 Master, Develop 브랜치에 Merge해주고 브랜치를 닫는다.

 

git-flow에서 가장 중심이 되는 브랜치는 master와 develop이다. (무조건 필요)

이름을 변경할 수는 있지만, 통상적으로 사용하는 이름이므로 그대로 사용하도록 하자

진행 과정 중에 Merge된 feature, release, hotfix 브랜치는 닫아서 삭제하도록 한다.

이처럼 계획적인 릴리즈를 가지고 스케줄이 짜여진 대규모 프로젝트에는 git-flow가 적합하다. 하지만 대부분 일반적인 프로젝트에서는 불필요한 절차들이 많아 생산성을 떨어뜨린다는 의견도 많은 방식이다.

 

GitHub Flow

git-flow를 개선하기 위해 나온 하나의 방식

흐름이 단순한 만큼, 역할도 단순하다. git flow의 hotfix나 feature 브랜치를 구분하지 않고, pull request를 권장한다.

 

 

Master 브랜치가 릴리즈에 있어 절대적 역할을 한다.

Master 브랜치는 항상 최신으로 유지하며, Stable한 상태로 product에 배포되는 브랜치다.

따라서 Merge 전에 충분한 테스트 과정을 거쳐야 한다. (브랜치를 push하고 Jenkins로 테스트)

 

새로운 브랜치는 항상 Master 브랜치에서 만들며, 새로운 기능 추가나 버그 해결을 위한 브랜치는 해당 역할에 대한 이름을 명확하게 지어주고, 커밋 메시지 또한 알기 쉽도록 작성해야 한다.

그리고 Merge 전에는 pull request를 통해 공유하여 코드 리뷰를 진행한다. 이를 통해 피드백을 받고, Merge 준비가 완료되면 Master 브랜치로 요청하게 된다.

이 Merge는 바로 product에 반영되므로 충분한 논의가 필요하며 CI도 필수적이다.

Merge가 완료되면, push를 진행하고 자동으로 배포가 완료된다. (GitHub-flow의 핵심적인 부분)

CI (Continuous Integration)

• 형상관리 항목에 대한 선정과 형상관리 구성 방식 결정
• 빌드/배포 자동화 방식
• 단위테스트/통합테스트 방식

이 세가지를 모두 고려한 자동화된 프로세스를 구성하는 것

 

참고

• https://www.youtube.com/watch?v=Z9dvM7qgN9s
• https://github.com/eungsu/documents/blob/master/git%EC%82%AC%EC%9A%A9%EB%B2%95.md
• https://gyoogle.dev/blog/github/Git%20vs%20GitHub%20vs%20GitLab%20Flow.html