[Git] (정리)혼자서 GitFlow를 따라 프로젝트 진행하기

목차

git 초기 설정

• git config 값 설정

  • git config --global user.email "이메일 주소"
    git config --global user.name "이름"
    git config --global init.defaultBranch main

  • 설정정보 확인
    

    • git config --list

원격 레포지토리 생성(main 브랜치 생성)

• 깃허브 원격 레포지토리 생성
  • 생성할때 Add a README file을 체크해서 최초의 파일을 생성해둬야 develop 브랜치가 생성이 가능합니다. (필요하다면 Add .gitignore 템플릿을 추가하여 생성하는 것도 가능합니다.)
    • 최초의 커밋이 있어야지만 develop 브랜치 생성 가능 
  • 깃허브 원격 레포지토리 생성 시 git init이 자동으로 실행됩니다.
  • 따라서 main 브랜치가 생성되어져 있는 상태입니다.
• 깃허브 원격 레포지토리 clone

  • git clone 레포지토리url.git

  • clone을 한 뒤 해당 폴더로 들어가서 git status를 진행하면 현재 브랜치가 main 브랜치로 지정되어 있습니다.
  • 또한 git remove -v를 통해 origin을 확인해 보면 해당 레포지토리 url가 origin으로 등록되어 있는 것을 확인할 수 있습니다.
  • (따라서 git init이나 origin을 지정해 줄 필요는 없습니다.)
• 클론 후 가상환경을 생성하고 activate를 진행해줍니다.

  • python3 -m venv venv(가상환경이름)
    source venv/bin/activate

    • 윈도우인 경우

      • python -m venv venv
        venv\Scripts\activate

  • .gitignore 파일에 venv/ 가 적혀있는지 확인해줘야합니다.

develop 브랜치 생성 및 푸시

• main 브랜치에서 develop 브랜치를 생성

  • git branch develop

• develop 브랜치로 이동

  • git switch develop

• develop 브랜치 원격 저장소에 push 해주기
  

  • git push -u origin develop

    • -u는 git push 할 때 지정한 원격저장소 주소와 올릴로컬브랜치명을 git에게 기억하고 있으라고 설정해 주는 것입니다. 따라서 한 번만 위 명령어를 쳐주게 되면 다음부턴 git push만 해도 알아서 원격저장소주소의 브랜치에 업로드 되게 됩니다. 
• 여기까지가 이제 main 브랜치와 develop 브랜치가 생성되어 있는 상태입니다. 현업에서는 이 상태가 대부분이며 develop 브랜치를 pull 한 뒤 feature 브랜치를 생성한 뒤에 코드를 작성하고 develop 브랜치에 pull requests를 하는 방식으로 진행됩니다.

feature 브랜치 생성 및 작업

• feature 브랜치 생성

  • git branch feature/기능

     
• feature 브랜치 이동

  • git switch feature/기능

• 이제 자신만의 feature 브랜치에서 코드 개발을 진행합니다. 
  • 코드 개발을 진행할 때 핵심 내역들이 진행되면 add와 commit을 진행해 줍니다.

    • git add .

      • 만약 add를 잘못했을 경우 아래 명령어로 add 취소 가능

        • git restore --staged 파일명

    • git commit -m "커밋 메시지"

      • 만약 commit을 잘못했다면 아래 명령어로 아예 커밋하기 전 시간으로 돌아가기 가능

        • git reset --hard 커밋아이디 # 모든 기억이 다 지워짐. 작업내역까지
          git reset --soft 커밋아이디 # 모든 커밋 내역이 다 지워짐. 단, 지워진 커밋에 대한 작업내역이 staging area에 올라간 상태
          git reset --mixed 커밋아이디 # 모든 커밋 내역이 다 지워짐. 단, 지워진 커밋에 대한 작업내역이 코드상에 존재(staging area에는 올라가지 않은 상태)

           
      • 만약 중간에 작업한 어떤 파일에 대한 commit 내역만 취소하고 싶을 경우, commit 내역은 삭제하지 못하지만 그때 했던 작업을 취소한다는 커밋을 생성해서 작업한 내용 삭제 가능

        • git revert 커밋아이디

  • 만약 코드 작성 중 지금까지 작성한 코드를 유지하면서 다른 여러 테스트를 진행하고 싶을 경우 어떻게 할까요?
    • 먼저 현재까지 작업하던  feature 브랜치에 추가적으로 여러 브랜치를 생성해서 테스트를 진행하고 테스트가 완료하면 feature브랜치에 합쳐주는 작업을 진행할 수 있습니다.
      • 새로운 브랜치를 생성할 때, 현재 브랜치의 최신 커밋에서 분기됩니다. 따라서 새 브랜치에서 시작하기 전에 중요한 변경사항이 있다면 커밋하는 것이 좋습니다.
      • 아래 예시에서 기준브랜치는 develop, 합칠 브랜치는 feature로 생각하면 이해하기 좋습니다.
      • 3-way merge(Fast-forward merge)
        • 기준브랜치에도 commit이 있고 합칠 브랜치에도 commit이 있는 경우 3-way merge로 진행됩니다.

          • git switch 기준브랜치
            git merge 합칠브랜치 -m "커밋메시지"

             
        • 기준브랜치에는 commit이 없고 합칠브랜치에만 commit이 있는 경우 Fast-forward merge로 진행됩니다. 
          • 이게 싫고, 기존 3-way merge처럼 새로운 merge 커밋을 하나 추가하고 싶다면 --no-ff 옵션을 추가해주면 됩니다.

            • git switch 기준브랜치
              git merge --no-ff 합칠브랜치 -m "커밋메시지"

      •  rebase merge
        • rebase는 합칠브랜치의 시작지점을 기준브랜치의 최신 커밋뒤로 이동하는 것입니다. 그후 fast-forward merge처럼 merge가 진행됩니다. (기준브랜치의 최신 커밋뒤로 이동했기때문에, 기준브랜치에는 commit이 없고, 합칠브랜치에만 commit이 있는경우가 됨) 

        • git switch 합칠브랜치
          git rebase 기준브랜치
          
          git switch 기준브랜치
          git merge 합칠브랜치

           
      • squash merge
        • squash는 합칠브랜치의 모든 커밋내용을 하나의 커밋으로 변경해서 기준브랜치의 최신 커밋뒤에 적용합니다.

        • git switch 기준브랜치
          git merge --squash 합칠브랜치
          git commit -m "커밋메시지"

  • 만약 현재 브랜치에서 코드를 작성하다가 뭔가 코드가 애매해서 최근 커밋 이후 내용부터 지금까지 작성한 내용을 새로운 브랜치에서 작업을 진행하고 싶으면 어떻게 해야할까요?
    • 새로운 브랜치를 생성한 뒤, 이어서 작업하고 새로운 브랜치에 commit하며 테스트를 진행하면 됩니다.

feature 브랜치를 develop 브랜치로 merge (Pull Request)

• 기능 구현이 끝나서 이제 merge를 하고 싶은 경우, 우선 원격저장소에 푸시를 진행합니다.

  • git push -u origin feature/기능

• 원격저장소에 올라갔다면, 이제 develop 브랜치에 Pull Request를 요청합니다.
  • 제목과 설명을 작성해준 뒤, Pull Request를 보냅니다.
• 원격저장소 관리자는 확인 후 merge가 가능하다면 merge 요청을 수락합니다.
  • Create a merge commit, Rebase and merge, Squash and merge 중 merge 방식을 선택하여 merge를 진행합니다.
    • Create a merge commit
      • 일반적인 merge 방식입니다. 병합 커밋을 생성하여 original 브랜치(feature)의 커밋 히스토리를 보존합니다.
      • 결과적으로 original 브랜치(feature)와 target 브랜치(develop)가  히스토리에 그대로 남아있게 됩니다.
    • Rebase and merge
      • 이 방식은 original 브랜치(feature)의 커밋을 target 브랜치(develop)의 최신 커밋 뒤에 이어 붙여줍니다. 이 과정에서 originarl 브랜치(feature)의 커밋들은 새로운 커밋으로 target 브랜치(develop)에 추가가 됩니다. (즉, original 브랜치(feature)의 똑같은 커밋들이 target 브랜치(develop) 뒤에 재생성되는 것입니다.)
      • 이 방법은 커밋 히스토리를 선형적으로 만들지만, original 브랜치(feature)의 커밋들은 새로운 커밋으로 대체되어 original 브랜치의 히스토리는 target 브랜치에서 보이지 않습니다. 
    • Squash and merge
      • original 브랜치(feature)의 모든 커밋을 하나의 커밋으로 합친 다음, 이를 target 브랜치(develop)에 병합합니다.
      • 이 방법을 사용하면, original 브랜치(feature)의 개별 커밋들은 target 브랜치(develop)에 하나의 커밋으로 통합되어, 원래 브랜치의 개별 커밋 히스토리는 사라집니다.
  • 전체 히스토리를 보존하는 가장 투명한 방법은 Create a merge commit이지만, 히스토리가 복잡해질 수 있는 단점이 있습니다. 하지만 반대로 Rebase and Merge와 Squash and Merge는 히스토리를 깔끔하게 유지할 수 있지만, 개별 커밋의 세부사항을 잃을 수 있는 단점이 있습니다. (Rebase는 그래도 작업한 커밋내용을 재생산해서 작업내용은 기억할 수 있습니다. Squash는 모든 작업을 하나의 commit으로 대체해서 그동안 작업한 커밋내역들을 모두 잃게 됩니다.)
• merge 완료 후, merge된 develop 브랜치를 로컬저장소로 pull해야합니다.

  • git switch develop
    git pull origin develop

• merge 완료 후, 필요 없어진 feature 브랜치는 삭제할 수 있습니다.
  

  • git branch -d 브랜치이름
    git branch -D 브랜치이름

     
    • 참고 : merge가 완료된 브랜치 삭제 시엔 -d / 실수로 만든 브랜치 삭제 시엔 -D 사용
• 원격저장소에서 PR을 통해 merge한 feature브랜치를 삭제하면 원격저장소에서 feature브랜치가 삭제되게 됩니다. 하지만 이제 로컬저장소에서 pull을 진행할경우 origin/feature브랜치와 feature브랜치는 그대로 남아 있게 됩니다. 이 두개의 브랜치를 삭제해주려면 다음 명령어를 사용하면 됩니다. 

  • git branch -d feature/기능

    
    
    • 로컬에서 feature/기능 브랜치 제거

  • git fetch --prune

    
    
    • 원격저장소에는 삭제된 feature브랜치가 로컬저장소에 남아있을경우 삭제해주기 위한 명령어
    • origin/feature/기능 브랜치 제거

release 브랜치 생성 및 테스트

• develop 브랜치가 merge 되었기 때문에 우선 develop 브랜치의 최신 변경사항을 로컬에 가져와야 합니다.

  • git switch develop
    git pull origin develop

• develop 브랜치의 최신 변경사항이 반영되었으면 develop 브랜치에서 release 브랜치를 생성 후 이동합니다. (뒤에 숫자는 버전을 의미합니다.)

  • git branch release/1.2.4
    git switch release/1.2.4

• release 브랜치에서 각종 테스트, 버그 수정, 문서 업데이트(README.md 파일 등)를 진행합니다.
  • 새로 추가된 기능, 개선사항, 중요한 변경사항 등을 README.md 에 추가합니다.

release 브랜치를 main 브랜치와 develop 브랜치에 merge (Pull Request)

• 우선 완성된 release 브랜치를 원격 레포지토리에 푸시합니다.

  • git push -u origin release/1.2.4

• 그 후 release/1.2.4 브랜치로부터 main 브랜치와 develop 브랜치로 Pull Request를 생성합니다.
• Pull Request를 검토하고, 문제가 없다면 main 브랜치에 먼저 병합합니다.
• 그다음 develop 브랜치에도 병합하여 릴리스에서 이루어진 변경사항을 develop 브랜치에 반영합니다.
• merge 완료 후, 마찬가지로 필요 없어진 브랜치는 삭제할 수 있습니다.
  

  • git branch -d 브랜치이름
    git branch -D 브랜치이름

    • 참고 : merge가 완료된 브랜치 삭제 시엔 -d / 실수로 만든 브랜치 삭제 시엔 -D 사용

(참고) 협업 시에 고려할 점

• 혼자서 작업할 경우에는 develop 브랜치가 자주 업데이트 되지 않을 것입니다. 하지만 협업 시에는 다른 사람들이 feature 브랜치에서 작업을 한 뒤에 PR(Pull Request)을 보내서 merge가 되게 된다면, develop 브랜치는 계속해서 업데이트될 것입니다. 따라서 feature 브랜치 개발을 시작하기 전이나 push 하기 전에는 항상 develop 브랜치를 pull을 통해 업데이트된 내역을 반영해서 수정해 주는 것이 좋습니다. (충돌 방지) 

  • git switch develop
    git pull origin develop