Git Session

youngsung·2024년 11월 16일
git
0

git, github

목록 보기
3/3

session 진행 이유

1. 체계화 강화
2. 원활한 개발 환경 구축
3. 협업 및 소통의 개선
4. 배포시 문제사항 개선

SVN

  • SVN이란

    SVN은 SubVersion 단어의 줄임말로 중앙집중형 버전 관리 시스템(CVCS)입니다.

    각각의 개발자들이 본인의 코드 변경 사항을 하나의 중앙 저장소 (Center Repository) 에 commit 하는 방식으로 운영합니다.

    즉, 로컬 PC에서 커밋 시 중앙 저장소에 바로 반영되고 중앙 저장소에 있는 내용들을 다른 로컬 PC에 업데이트 시킬 수 있습니다.

Git

  • Git이란 
> `Git` 이란 **분산형 버전 관리 시스템(DVCS)**입니다. 모든 사용자가 중앙 서버와 독립적으로 로컬에 프로젝트의 전체 히스토리와 파일을 복사해둡니다. 즉, Git을 사용하면 중앙 서버와 연결되지 않은 상태에서도 로컬에서 커밋하고, 나중에 서버와 동기화할 수 있습니다.
>

SVN과 Git의 차이점

Git과 SVN은 모두 버전 관리 시스템(VCS)이지만, 구조와 기능 면에서 큰 차이가 있습니다. 이 두 시스템의 차이점을 이해하면 어떤 환경에서 어떤 시스템이 더 적합한지 판단할 수 있습니다. 아래는 주요 차이점입니다.

1. 중앙집중형 vs. 분산형

  • SVN: 중앙집중형 버전 관리 시스템(CVCS)입니다. 모든 프로젝트 파일과 버전 히스토리는 중앙 서버에 저장되며, 사용자는 서버에서 파일을 내려받아 작업하고 다시 중앙 서버에 업로드(커밋)합니다. 따라서 중앙 서버에 문제가 생기면 작업이 중단될 수 있습니다.
  • Git: 분산형 버전 관리 시스템(DVCS)입니다. 모든 사용자가 중앙 서버와 독립적으로 로컬에 프로젝트의 전체 히스토리와 파일을 복사해둡니다. 즉, Git을 사용하면 중앙 서버와 연결되지 않은 상태에서도 로컬에서 커밋하고, 나중에 서버와 동기화할 수 있습니다.

2. 로컬 작업 및 커밋

  • SVN: 로컬에서 변경 사항을 저장하기 위해서는 항상 중앙 서버와 연결되어 있어야 합니다. 로컬에서는 커밋할 수 없고, 서버에만 커밋이 가능합니다.
  • Git: 로컬에서 커밋할 수 있고, 중앙 서버와는 나중에 동기화(push)하면 됩니다. Git은 로컬에서도 완전한 버전 관리 시스템으로 동작합니다.

3. 속도

  • SVN: 모든 변경 사항이 중앙 서버에서 처리되므로, 특히 대규모 프로젝트에서 네트워크가 느리면 성능이 저하될 수 있습니다.
  • Git: 로컬에서 많은 작업을 처리하기 때문에 속도가 더 빠릅니다. 커밋, 브랜치 생성, 체크아웃 등의 작업이 로컬에서 즉각적으로 처리됩니다.

4. 브랜치 및 병합(merge)

  • SVN: 브랜치 생성 및 병합은 가능합니다. 하지만 브랜치와 태그를 디렉토리 구조로 관리하기 때문에 일부 복잡한 브랜치 작업이 어렵고, 병합 시 충돌 관리가 복잡할 수 있습니다.
  • Git: 브랜치 생성과 병합이 매우 가볍고 빠릅니다. Git은 브랜치 기반 워크플로우에 최적화되어 있어 여러 브랜치를 쉽게 만들고 병합할 수 있으며, 충돌 관리도 효과적으로 할 수 있습니다.

5. 히스토리 접근 및 백업

  • SVN: 프로젝트의 모든 버전 기록이 중앙 서버에 저장되기 때문에, 히스토리에 접근하려면 중앙 서버가 필요합니다. 서버가 다운되면 히스토리에 접근하기 어려워집니다.
  • Git: Git은 각 사용자의 로컬에 프로젝트 전체 히스토리가 저장됩니다. 따라서 중앙 서버에 문제가 생기더라도 각 사용자의 로컬에서 프로젝트의 모든 기록에 접근할 수 있습니다.

6. 파일 크기 처리

  • SVN: 큰 파일이나 이진 파일을 처리하는 데 유리하며, 변경 사항을 관리하는 방식이 텍스트 파일과 유사합니다.
  • Git: Git은 기본적으로 소스 코드와 같은 텍스트 파일을 효율적으로 관리하기 위해 설계되었습니다. 큰 파일이나 이진 파일을 다룰 때는 성능이 저하될 수 있으며, 이를 위해서는 Git LFS(Large File Storage) 같은 추가 도구를 사용해야 합니다.

7. 사용성

  • SVN: 중앙 서버 기반의 작업 흐름이 더 직관적일 수 있어, 버전 관리에 익숙하지 않은 사용자에게 적합할 수 있습니다.
  • Git: 분산형 특성으로 인해 초기에는 학습 곡선이 있을 수 있지만, 유연성과 강력한 기능을 제공하기 때문에 복잡한 프로젝트와 팀 환경에 적합합니다.

8. 커뮤니티와 지원

  • SVN: 기존의 프로젝트나 일부 대규모 조직에서 여전히 많이 사용되지만, 최신 개발 트렌드에서는 Git에 비해 사용 빈도가 줄어드는 추세입니다.
  • Git: 오픈소스 커뮤니티와 대규모 프로젝트에서 표준 버전 관리 시스템으로 자리 잡았습니다. GitHub, GitLab 등의 플랫폼 덕분에 사용 사례가 매우 광범위합니다.

결론

  • SVN은 중앙집중형 시스템으로서 안정성과 일관성을 중시하는 프로젝트에 적합하며, 특히 큰 파일 처리에 유리합니다.
  • Git은 분산형 시스템으로, 여러 개발자가 독립적으로 작업해야 하는 환경이나 브랜치와 병합을 많이 사용하는 프로젝트에서 더 유리합니다. 빠른 속도와 유연성 덕분에 현대 소프트웨어 개발의 주류 도구로 자리 잡고 있습니다.

Git Flow 전략

여러 개발자가 하나의 저장소에 작업을 할 때, 협업을 좀 더 효과적으로 하기 위해

git branch 에 대한 규칙을 정하고 저장소를 잘 활용하기 위한 workflow 를 정의하는 것을 바로 git branch 전략이라고 합니다.

**branch란?**
브랜치란 독립적으로 어떤 작업을 진행하기 위한 개념입니다.
필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에
여러 작업을 동시에 진행할 수 있습니다.

소프트웨어 개발 팀에서는 프로젝트의 특성에 따라 적절한 브랜치 배포 전략을 채택하는 것이 중요합니다.

브랜치 종류는 다음과 같습니다.

  1. master: 제품 출시 버전을 관리하는 메인 브랜치
  2. develop: 다음 출시 버전을 위해 개발하는 브랜치
  3. feature: 새로운 기능을 개발하는 브랜치
  4. release: 다음 출시 버전을 준비하는 브랜치
  5. hotfix: 출시된 제품의 버그를 고치기 위한 브랜치

  • Git-Flow전략을 도입했을 시, 문제 상황

    • git 관련 학습 시간이 필요
    • 소규모 팀으로 구성되어있거나 프로잭트를 진행했을때 번거로움이 존재할 수 있음 ⇒ MSA구조에서는 각각의 프로잭트들이 하나의 기능으로 존재함으로 오히려 복잡한 Git-Flow전략이 될 수 있음.

  • main branch 하나만 사용했을 시, 문제 상황

    1. 롤백 시키려면 하나하나 커밋을 다 찾아봐야하는 번거로움이 존재함.

    2. 누가 어떤 작업을 했는지 추적하기 어려워 질 수 있음.

    3. 시점이 다른 두 사람이 push를 하는경우 이전에 개발한 기능들이 없어지는 경우가 존재함.

      1. 항상 pull을 받아가면서 작업을 진행해야함

    4. 불완전한 코드가 머지될 가능성이 높아짐.

    5. 테스트 환경의 부족함이 발생할 수 있음.

    6. CI/CD 도입 시, 바로 배포되는 상황.

  • 해결 방안

    • 좀더 간단한 flow전략을 채택한다.(Trunk-Based Development)
      • master ⇒ 배포를 위한 브랜치
      • dev ⇒ 1명이 개발을 진행하더라도 dev브랜치는 필요
      • feature ⇒ 2명 이상 개발자가 투입 된경우 필요
    • 짧은 릴리스 주기를 설정 ⇒ 큰 기능이 아닌 작은 기능 단위로 브랜치를 생성
    • 자신의 Pull Request는 본인 스스로 merge ⇒ 충돌 혹은 오류 사항은 본인 책임

  • 추가적 필요 사항

    • commit convention 설정 (하단에 있는 내용은 예시) : 어떤 커밋을 했는지 쉽게 알아보기 위해

      Tag NameDescription
      [FEAT]새로운 기능을 추가
      [FIX]버그 수정
      [DESIGN]CSS 등 사용자 UI 디자인 변경
      [!BREAKING CHANGE]커다란 API 변경의 경우(URI 주소 외 Request, Response 가 변경되는 경우)
      [!HOTFIX]급하게 치명적인 버그를 고쳐야하는 경우
      [STYLE]코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
      [REFACTOR]프로덕션 코드 리팩토링
      [DOCS]문서 수정, 필요한 주석 추가 및 변경
      [TEST]테스트 코드, 리펙토링 테스트 코드 추가, Production Code(실제로 사용하는 코드) 변경 없음
      [PACK]빌드 업무 수정, 패키지 매니저 수정, 패키지 관리자 구성 등 업데이트, Production Code 변경 없음
      [RENAME]파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
      [REMOVE]파일을 삭제하는 작업만 수행한 경우
      [COMPLETION]작업을 완료하고 마지막 커밋을 작성하는 경우
      [MERGE]병합
      [CONFLICT]병합 시 충돌 해결
      [DEPLOY]배포 관련 커밋

      ex1) [FEAT] jwt를 활용한 로그인 기능 구현

      ex2) <요구사항 번호 OR 이슈번호> 간략화된 제목 및 내용 ⇒ Jira와 연동시에 필요해보임

    • 리뷰어 설정

      • 팀장급 사람들로 선정 ⇒ 피드백을 바로 반영할 수 있음.
      • 각자 서로가 리뷰어로 선정 ⇒ 코드 재사용성을 높일수 있음.
      • 빠른 개발 실력 상승 효과 볼 수 있음

    • 하나의 이슈(티켓)에는 한번의 커밋을 목표로 설정

      • 하나의 브랜치라고 하더라도 여러개의 불필요한 커밋 상황이 있다면 찾아보기 불편할 가능성이 있음.

        • git rebase ⇒ 히스토리를 rebase를 하는 작업이므로 신중하게 진행

          1. 현재 불필요한 커밋 상황이 여러개 있다면 squash를 진행 (해당 작업은 merge직전에 진행)

            ⇒ git rebase -i HEAD~3 (3개의 커밋을 합친다.)

            ⇒ Vim이 열렸다면 “i”를 눌러 insert 진행

            pick <첫 번째 커밋 해시> 메시지 1
squash <두 번째 커밋 해시> 메시지 2
squash <세 번째 커밋 해시> 메시지 3

            이런식으로 커밋을 합쳐서 하나의 커밋으로 만들수있음

          2. 작업 브랜치를 rebase 진행 (해당 작업은 브랜치 작업을 순차적으로 만들기 위함)

            ⇒ git pull –rebase origin feature-user (로컬 브랜치의 **시작점을 원격 저장소의 최신 변경 사항으로 바꾸는 작업**)

⇒ 만약 conflict오류가 나왔다면 모든 충돌 해결후 나머지 진행

```bash
git add <충돌 해결된 파일>
git rebase --continue
```

            해당 모든 rebase 작업들을 마치게 된다면

            그래프가 깔끔하게 변경됨. ⇒ 히스토리를 찾아보기 쉬워짐

      • 개발 도중 원격 저장소에 있는 dev브랜치에 내가 필요로하는 기능이 update되었을 경우

        • git stash

          1. 현재 작업 중인 변경 사항을 stash를 통해 임시로 저장하는 작업

            git stash
git pull origin <개발 메인 브랜치>

          2. 성공적으로 pull을 했다면, 임시저장한 stash를 불러옴

            git stash pop

            해당 작업을 진행하면 충돌이 발생할 수 있음 해결 후 git add 진행

profile
youngsung
To Infinity and Beyond
이전 포스트

Git을 활용한 버전관리!

0개의 댓글