[코드프레소] Java 웹개발 트랙 체험단 - 실무자가 알려주는 Git 활용한 프로젝트 관리

01강 Git 브랜치의 이해

• 브랜치
  • 기본 브랜치로부터 파생한 독립적 작업 공간
  • 최신 커밋을 가리키는 일종의 포인터
  • 매우 가볍다
  • 생성, 이동, 병합 (merge)가 매우 쉽다.
• Git 의 브랜치
  • https://github.com/tensorflow/tensorflow
• Git 의 브랜치 실습을 위한 디렉토리 생성

$ cd ~/g ittest $ mkdir branch_test $ cd branch_test $ git init

• master브랜치
  • Git 은 기본적으로 master 브랜치를 생성한다.
  • 현재 작업중인 브랜치 확인하는 명령어 $ git branch
  • master 브랜치는 첫 번째 커밋을 만들어야 생성된 커밋을 가리킬 수 있다.
• 첫번째 커밋 생성
  • $ vi MainService.java
  • 내용 작성 후 저장하고 종료하기 (:wq)
  • $ git add MainService.java
  • $ git status
  • $ git commit -m "Commit 1 on master branch”
  • $ git branch
  • $ git log
• HEAD
  • 현재 브랜치를 가리키는 일종의 포인터
  • 현재 브랜치의 마지막 커밋에 대한 스냅샷
• 새로운 기능 개발이 시작되면?
  • 브랜차는 목적에 따라 분기할 수 있다.
  • 브랜치 분기 전략은 조직에 따라 달라진다.

• 브랜치생성

$ git branch feature-login (생성할 브랜치명)

$ git branch

$ git log

 

• 브랜치이동

$ git branch feature-login (이동할 브랜치명)

$ git branch

$ git log

 

• master 브랜치로 이동

$ git checkout master $ git branch

$ git log

$ Is -la

 

• • HEAD 는 checkout 대상 브랜치로 이동한다.
  • 로컬저장소의 상태는 HEAD 가 가리키는 마지막 커밋이 최신이 되고,
  • 작업 디렉토리의 파일 상태도 변경된다.브랜치 이동(checkout)

 

• 개발 증 이슈가 발생하면?
• 브랜치 생성
  • master 브랜치에서 issue 라는 새로운 브랜치 생성
  • $ git branch
  • 브랜치 생성과 동시에 이동(checkout)
  • $ git checkout -b issue
  • $ git branch
• 이슈 해결이 완료되면 ?
• 브랜치 병합 (merge)

(1 ) 기준이 되는 브랜치로 이동해서 병합해야 한다.

• issue 브랜치 ➔ master 브랜치 $ git checkout master

(2) 합쳐질 브랜치를 병합한다. $ git merge issue $ git log

• Fast-forward Merge
  • 브랜치의 위치만 최신 커밋으로 이동시키는 방식
  • $ git merge issue
• 브랜치 삭제
  • 더 이상 사용되지 않는 브랜치는 삭제하기 $ git branch -d issue
• 기능개발이 완료되면?
• 브랜치 병합 (merge)

(1 ) 기준이 되는 브랜치로 이동해서 병합해야 한다. feature-login 브랜치 ➔ master 브랜치 $ git branch

(2) 합쳐질 브랜치를 병합한다. $ git merge feature-login

• 3-way Merge
  • 아래 3 개 커밋을 모두 고려하여 병합하는 방식으로 3-way Merge 의 결과는 새로운 커밋으로 생성됨
  • 1 ) master 와 feature-login 브랜치의 공통 부모 커밋 2) mater 브랜치의 죄신 커밋 3) feature-login 브랜치의 죄신 커밋
• 변경사항의 충돌(conflict)

개발하는 기능의 목적에 맞게 어떤 변경사항을 어떻게 반영할지를 결정하고 수정하여 반영 하는 것을 conflict을 해결하는 과정이라 한다.

$ git status

• 충돌의해결

1. 직접 merge 하기 $ vi MainService.java 수정하지 않고 :q 로 종료
2. mergetool 사용하기 $ git mergetool

 

--

1. 개발자의 의도대로 수정 후,
2. Conflict 기호 제거( <<<<<< , ===== >>>>>> )
3. 수정 완료되면 저장 후 종료 ([ESC]+:wq)
4. 나머지 3-way 장은 수정 없이 종료 ([ESC] + : q)
5. 병합이 제대로 되었는지 확인 후, commit 생성

$ vi MainService.java

$ git add MainService.java

$ git commit -m "Merge Comrmit 2"

$ git log --oneline

 

 

---

Git의 Tag

• 태그란?
  • 태그는 특정 시점의 소스코드 정보를 기록함
  • 프로젝트 진행중 의미있는 시점의 커밋을 태깅한 것
    • 의미있는시점이란? -1차 목표기능 개발 완료 되었을 때,
      • 매우 중요한 이슈가 해결되었을 때
      • 기능 개발 완료 및 테스트까지 모두 완료하여 통과하였을 때,
      • 고객에게 소프트웨어를 배포할 때,
      • ...
• Git 태그의 종류
  • Lightweight 태그 : 버전명과 같은 태그명만 남기는 태그
  • Annotated 태그 : Git 데이터베이스에 태그를 만든 사람의 이름, 이메일, 태그 생성 날짜, 태그 메시지 등을 저장한 태그
• Git 태그 생성하기
  • Lightweight 태그 생성 : $ git tag [태그명]
  • Annotated 태그 생성 : $ git tag -a [태그명] -m [태그 메시지]
• Annotated 태그 생성하기
  • $ git tag - a v1.0 - m “implemented login feature"
  • $ git log
  • $ git show v1.0 (태그 정보 확인)
• 특정 시점의 커밋 태그하기
  1. 태깅하고자 하는 커밋의 |D 값확인
  $ git log --oneline
  1. 커밋 |D 값을 인자로 태깅하기 $ git tag -a v0.1 [커밋 ID] -m "fix issue number-1" $ git log --oneline
  2. 태그정보확인하기 $ git show v0.1
• 태그활용전략
  • Git 을 이용한 태그 생성 시점은 조직마다 다를 수 있다.
  • 중요한 것은 소스코드의 효율적인 관리를 위해 태그 생성 시점과 방법에 대해서 일관성 있는 규칙 (프로세스)을 정해 프로젝트 팀원 모두가 준수할 수 있도록 정책화 해야 한다.

 

 

---

 

 

02강 Git 브랜치 활용

Git 브랜치 활용 전략

• 브랜치가 왜 필요할까요?
  • 소프트웨어는 지속적으로 변경된다.
  • 소프트웨어에 대한 변경은 개발 진행 중에 또는 개발이 완료되어 사용 중인 제품에서 발생하는 문제점을 해결하거나 개선하기 위해 발생할 수 있다.
• 브랜치 활용 전략
  • Git 을 이용한 브랜치 활용 방식은 개인/조직마다 다를 수 있다.
  • 브랜치 활용 전략은 소스코드의 효율적인 관리를 위해 프로젝트의 모든 리스크를 죄소화하는 방향으로 일관되고 생산적인 방식으로 조직에 맞게 프로세스화 시켜야 한다.
• 브랜치 활용 전략모델
  • feature 별 branch
  • 개발자별 branch
  • 스프린트 주기별 branch
  • 사내 검증 단계별 branch
  • 브랜치 활용 전략 모델(방법론) : GitFlow

 

---

Git 브랜치 활용 전략 - GitFlow

• GitFlow 모델
  • 아래 브랜치를 활용하여 변경점 관리하는 모델
    • master branch
    • develop branch
    • feature branch
    • release branch
    • hotfix branch
• GitFlow 모델 - master
  • 실제 고객에게 릴리즈되는 브랜치 (production)
  • 모든 변경사항은 결국 master 로 최종 반영되어야 함
• GitFlow 모델 - develop
  • 실제 개발의 중심이 되는 브랜치
  • 즉, 모든 기능이 추가되고 버그가 수정되고, 고객에게 배포 가능한 수준이 되면 develop 의 내용은 master 에 최종 반영되어야 함
  • 다음 배포할 기능 개발하는 브랜치
• GitFlow 모델 - feature
  • 기능을 개발하는 브랜치
  • develop 브랜치로부터 분기되어 사용됨 (feature 브랜치의 단위? 기능, 스프린트 주기 등)
  • 기능개 발이 완료되거나 스프린트 주기가 종료되면 develop 브랜치로 내용 merge 후 브랜치 삭제됨
• GitFlow 모델 - release
  • 배포를 준비(검증, 이슈 수정 등) 하는 브랜치
  • 배포 가능한 상태가 되면 master 브랜치로 병합
  • release 브랜치에서 기능 점검시 발견한 이슈에 대한 수정 사항은 반드시 develop 에 병합해야 함
  • 배포 준비가 완료되면, 최종 master 로 병합하고 tag 를 명시해야 함
• GitFlow 모델 - hotfixs
  • 배포한 버전에서 긴급하게 수정이 필요한 장애 및 버그 발생시 대응하는 브랜치
  • hotfixs 는 master 로 부터 분기되며, 이슈가 수정되면 수정 사항은 master, develop 브랜치에 최종 반영되어야 함

 

---

https://www.codepresso.kr/