GIT

Git과 Github에 대해서 알아보자

GIT 이란?

속도에 중점을 둔 분산형 버전 관리 프로그램

버전 관리란?

소스 하나 또는 묶음을 하나의 버전으로 간주하여 관리하는 의미이다.

GIT을 어느때에 사용하나?

개발 협업을 위해 사용하거나 개별적으로 프로젝트 이력을 관리하기 위해 사용한다.

버전 관리 유형 종류?

로컬 : 로컬 데이터베이스에 해당 파일의 변경 사항을 기록한다. (로컬에 저장하기 때문에 협업이 불가능)
중앙집중식 : 서버에 저장소를 집중시켜 중앙 서버에서 버전을 관리한다. (서버가 고장 나면 최신 소스 코드를 받아올 수 없다.)
분산 버전 관리 : 서버의 저장소를 통째로 복제하여 서버가 문제가 생겨도 복제된 저장소를 다시 서버로 복사하면 서버 복구가 가능하다.

GITHUB 이란?

GIT의 원격 저장소 서버를 제공하는 서비스

GITHUB을 사용하는 이유는?

변경 추적이 가능하다.
특정 시점으로 추적이 가능하다.
다양한 버전으로 관리가 가능하다.
협업을 위한 코드 공유가 편리하다.

SVN vs GIT

중앙집중식 버전 관리 시스템

분산 버전 관리 시스템

데이터가 중앙 서버에 집중되므로 관리하기가 매우 단순하지만 중앙 서버에 설정 해야 하는 부분이 다소 복잡하다.

데이터를 로컬 저장소 뿐만 아니라 원격 저장소에도 배포하여 저장할 수 있으며 작업 이력을 관리하고 분기하여 원하는 시점으로 파일을 복원하거나 통합할 수 있다.

작업한 내용은 수시로 서버에 반영해야 하므로 인터넷이 안 좋은 환경에서는 작업 속도가 매우 느리다.

네트워크가 연결이 되지 않아도 버전 관리가 가능하고 서버 저장소에 오류가 생기더라도 로컬 저장소로 복구할 수 있다. 그러나 브랜치가 많아질 경우 작업하는 시간 보다 병합하는 시간이 더 소요될 수 있다.

GIT DICTIONARY

Commit : 추가/수정/삭제 된 폴더/파일 등을 내 로컬 컴퓨터에 기록한다.
Push : 내 로컬 컴퓨터에 저장되어 있던 버전 정보를 Git 저장소 서버로 업로드 한다.
Branch : 버전들을 묶어서 Branch로 명칭한다. 크게 로컬 Branch/ 원격 Branch로 구분한다.
Tag : 특정 버전 위치에 대해 나중에 쉽게 찾아갈 수 있도록 이름을 지정해 놓은 것(책갈피 기능)
Cherry Pick : 다른 브랜치의 특정 커밋을 현재 브랜치에 병합
Merge : 서로 다른 Branch를 병합하는 과정
Rebase : Git 과거 이력을 편집 목적으로 정리 해줌
Pull : 원격 저장소의 최신 버전을 가져와 로컬 저장소에 자동으로 Merge 한다.
Fetch : 원격 저장소의 최신 커밋을 가져오지만 로컬 저장소에 Merge 하지는 않는다.
Clone : 원격 저장소를 특정 이름으로 복제하여 가져온다.

Branche Stratege

Master : 최종 릴리즈한 안정된 버전 브랜치
Develop : 다음 릴리즈를 위한 개발 중인 최신 빌드 브랜치
Feature : 특정한 기능을 위한 브랜치
Release : 릴리즈 점검을 위한 브랜치
Hotfix : 긴급 버그 픽스를 위한 브랜치

Git Flow

Feature 1. 최신 버전의 Develop 브랜치에서 Feature 브랜치를 생성한다. 2. Feature 브랜치에 작업한 것을 Commit한다. 3. 테스트를 완료한 후 이상이 없으면 최신버전의 Develop브랜치에 Feature브랜치를 Merge하고 충돌이 없다면 Push한다.
Release 1. 최신 버전의 Develop 브랜치에서 Release 브랜치를 생성한다. 2. QA팀에서 테스트를 한다. 3. 버그가 있다면 Release 브랜치에서 수정한다. (기능은 추가하지 않고 버그 수정이 목적) 4. 배포할 준비가 되었다면 Release 브랜치를 Develop 브랜치와 Master 브랜치 각각에 Merge 한다. 5. 배포한 Master 브랜치엔 버전 넘버를 태그한다.
Hotfix 1. 최신 버전의 Master 브랜치에서 새로운 Hotfix 브랜치를 생성한다. 2. Hotfix 브랜치에 코드를 Commit 한다. 3. 테스트된 Hotfix 브랜치는 Master와 Develop 둘다에 Merge 되어야 한다. 4. Master 브랜치는 다시 태그되어 배포된다.

Good Commit

목적 : 리뷰 속도 향상, 유지보수 성능 향상, 효율적인 협업

제목과 본문을 빈 행으로 분리한다.
명령문으로 작성한다.("Fix", "Add", "Change"등으로 시작)
제목은 50자 이내로 제한한다.
제목 행에 마침표를 넣지 않는다. (영문법에 문제)
어떻게 보다는 무엇과 이유를 설명한다.
Issue tracker를 사용한다면 내용 한단에 참조를 추가한다.

Github 충돌 해결하는 방법

로컬 버전을 사용하기
원격 버전을 사용하기
충돌을 해결된 것으로 표시

JIRA with github

JIRA를 사용한다면 Github의 commit history를 JIRA issue와 연결하여 작업한 내용을 issue에서 확인할 수 있다. (셋업하는 방법은 추후에)
Reference URL : https://confluence.atlassian.com/jirakb/how-to-add-github-organization-repositories-to-jira-815256707.html

ETC

Github issues : github 내부에서 이슈를 관리하고 다양한 카테고리를 설정할 수 있으며 작업자를 호출하거나 다른 이슈나 커밋 내용을 태그할 수 있다.
Mile stone : 프로젝트에 마일스톤을 지정하여 단계별로 업무를 진행할 수 있다. 각각의 마일스톤에 해당하는 이슈들을 등록하고 마감기한이나 참여자를 선택할 수 있다.
Fork & Pull request : 프로젝트 규모가 커지거나 이슈가 발생하여 외부에서 프로젝트에 참여하게 된다면 Fork하여 프로젝트를 import할 수 있고 작업한 내용을 original repository에 pull request하여 반영하도록 요청할 수 있다.

PreviousCLOUD COMPUTING NextDOCKER

Last updated 4 years ago

버전 관리 유형 종류?

로컬 : 로컬 데이터베이스에 해당 파일의 변경 사항을 기록한다. (로컬에 저장하기 때문에 협업이 불가능)

중앙집중식 : 서버에 저장소를 집중시켜 중앙 서버에서 버전을 관리한다. (서버가 고장 나면 최신 소스 코드를 받아올 수 없다.)

분산 버전 관리 : 서버의 저장소를 통째로 복제하여 서버가 문제가 생겨도 복제된 저장소를 다시 서버로 복사하면 서버 복구가 가능하다.

SVN vs GIT

중앙집중식 버전 관리 시스템

분산 버전 관리 시스템

데이터가 중앙 서버에 집중되므로 관리하기가 매우 단순하지만 중앙 서버에 설정 해야 하는 부분이 다소 복잡하다.

작업한 내용은 수시로 서버에 반영해야 하므로 인터넷이 안 좋은 환경에서는 작업 속도가 매우 느리다.

GIT DICTIONARY

Commit : 추가/수정/삭제 된 폴더/파일 등을 내 로컬 컴퓨터에 기록한다.

Push : 내 로컬 컴퓨터에 저장되어 있던 버전 정보를 Git 저장소 서버로 업로드 한다.

Branch : 버전들을 묶어서 Branch로 명칭한다. 크게 로컬 Branch/ 원격 Branch로 구분한다.

Tag : 특정 버전 위치에 대해 나중에 쉽게 찾아갈 수 있도록 이름을 지정해 놓은 것(책갈피 기능)

Cherry Pick : 다른 브랜치의 특정 커밋을 현재 브랜치에 병합

Merge : 서로 다른 Branch를 병합하는 과정

Rebase : Git 과거 이력을 편집 목적으로 정리 해줌

Pull : 원격 저장소의 최신 버전을 가져와 로컬 저장소에 자동으로 Merge 한다.

Fetch : 원격 저장소의 최신 커밋을 가져오지만 로컬 저장소에 Merge 하지는 않는다.

Clone : 원격 저장소를 특정 이름으로 복제하여 가져온다.

Git Flow

Feature 1. 최신 버전의 Develop 브랜치에서 Feature 브랜치를 생성한다. 2. Feature 브랜치에 작업한 것을 Commit한다. 3. 테스트를 완료한 후 이상이 없으면 최신버전의 Develop브랜치에 Feature브랜치를 Merge하고 충돌이 없다면 Push한다.

Release 1. 최신 버전의 Develop 브랜치에서 Release 브랜치를 생성한다. 2. QA팀에서 테스트를 한다. 3. 버그가 있다면 Release 브랜치에서 수정한다. (기능은 추가하지 않고 버그 수정이 목적) 4. 배포할 준비가 되었다면 Release 브랜치를 Develop 브랜치와 Master 브랜치 각각에 Merge 한다. 5. 배포한 Master 브랜치엔 버전 넘버를 태그한다.

Hotfix 1. 최신 버전의 Master 브랜치에서 새로운 Hotfix 브랜치를 생성한다. 2. Hotfix 브랜치에 코드를 Commit 한다. 3. 테스트된 Hotfix 브랜치는 Master와 Develop 둘다에 Merge 되어야 한다. 4. Master 브랜치는 다시 태그되어 배포된다.

Good Commit

목적 : 리뷰 속도 향상, 유지보수 성능 향상, 효율적인 협업

제목과 본문을 빈 행으로 분리한다.

명령문으로 작성한다.("Fix", "Add", "Change"등으로 시작)

제목은 50자 이내로 제한한다.

제목 행에 마침표를 넣지 않는다. (영문법에 문제)

어떻게 보다는 무엇과 이유를 설명한다.

Issue tracker를 사용한다면 내용 한단에 참조를 추가한다.

ETC

Github issues : github 내부에서 이슈를 관리하고 다양한 카테고리를 설정할 수 있으며 작업자를 호출하거나 다른 이슈나 커밋 내용을 태그할 수 있다.

Mile stone : 프로젝트에 마일스톤을 지정하여 단계별로 업무를 진행할 수 있다. 각각의 마일스톤에 해당하는 이슈들을 등록하고 마감기한이나 참여자를 선택할 수 있다.

Fork & Pull request : 프로젝트 규모가 커지거나 이슈가 발생하여 외부에서 프로젝트에 참여하게 된다면 Fork하여 프로젝트를 import할 수 있고 작업한 내용을 original repository에 pull request하여 반영하도록 요청할 수 있다.