Skip to content

#90DaysOfDevOps - The Big Picture: Git - Version Control - Day 35

큰 그림: Git - 버전 관리

Git을 시작하기 전에 버전 관리가 무엇이며 왜 필요한지 이해해야 하나요? 이번 Git 시작 단계에서는 버전 관리가 무엇인지, 그리고 Git의 기본 사항에 대해 살펴보겠습니다.

버전 제어란 무엇인가요?

Git이 유일한 버전 관리 시스템은 아니므로 여기서는 버전 관리와 관련하여 어떤 옵션과 방법론을 사용할 수 있는지 살펴보고자 합니다.

버전 관리의 가장 분명하고 큰 장점은 프로젝트의 이력을 추적할 수 있다는 것입니다. 우리는 git log를 사용하여 이 리포지토리를 되돌아보고 많은 커밋과 많은 코멘트가 있으며 프로젝트에서 지금까지 무슨 일이 일어났는지 확인할 수 있습니다. 명령어에 대해서는 나중에 설명할 테니 걱정하지 마세요. 이제 이것이 소스 코드로 가득 찬 실제 소프트웨어 프로젝트이고 여러 사람이 서로 다른 시간에 소프트웨어에 커밋하고, 다른 작성자와 검토자가 모두 여기에 기록되어 무슨 일이 언제, 누가, 누가 검토했는지 알 수 있다고 생각해보세요.

과거 버전 제어는 변경을 하기 전에 수동으로 버전 복사본을 만드는 것과 같은 방식이었을 것입니다. 또한 혹시 모른다는 생각으로 쓸모없는 오래된 코드를 주석 처리했을 수도 있습니다.

저는 소스 코드뿐만 아니라 거의 모든 프로젝트에 버전 관리를 사용하기 시작했고, 이와 같은 프로젝트에 대해 이야기합니다(90DaysOfDevOps). 진행된 모든 것을 롤백하고 기록하는 기능을 받아들이는 것은 어떨까요?

그러나 버전 제어는 백업이 아닙니다!

버전 관리의 또 다른 이점은 프로젝트의 여러 버전을 관리할 수 있다는 점입니다. 예를 들어 모든 운영 체제에서 사용할 수 있는 무료 앱이 있고 모든 운영 체제에서 사용할 수 있는 유료 앱이 있다고 가정해 봅시다. 대부분의 코드는 두 애플리케이션 간에 공유됩니다. 각 앱에 코드를 복사하여 붙여 넣을 수도 있지만, 개발 인원이 한 명 이상으로 늘어나면 매우 지저분해지고 실수도 발생할 수 있습니다.

프리미엄 앱에는 추가 기능을 프리미엄 커밋이라고 부르고 무료 버전에는 일반 커밋만 포함할 수 있습니다.

버전 관리에서 이를 달성하는 방법은 branch를 사용하는 것입니다.

branch를 사용하면 위에서 설명한 것처럼 동일한 앱에 대해 두 개의 코드 스트림을 사용할 수 있습니다. 하지만 소스 코드가 없는 버전에 포함된 새로운 기능이 프리미엄 버전에 포함되기를 원하며, 이를 위해 Merge라는 기능을 사용합니다.

무료 버전에서 작업하는 팀과 프리미엄 유료 버전에서 작업하는 팀이 있을 수 있고, 둘 다 전체 코드의 일부에 영향을 주는 코드를 변경하면 어떻게 될지 모르기 때문에 merge는 복잡할 수 있습니다. 변수가 업데이트되어 무언가를 망가뜨릴 수도 있습니다. 그러면 기능 중 하나가 중단되는 충돌이 발생합니다. 버전 관리로는 이러한 충돌을 해결할 수 없습니다. 하지만 버전 제어를 사용하면 이를 쉽게 관리할 수 있습니다.

지금까지 버전 관리를 선택하지 않았다면 일반적으로 가장 큰 이유는 공동 작업 기능입니다. 개발자 간에 코드를 공유할 수 있는 기능, 그리고 앞서 말씀드린 대로 코드라고 하면 동료와 함께 작업하는 공동 프레젠테이션이나 프로젝트 전반에 걸쳐 커뮤니티가 수정 및 업데이트를 제공하는 90DaysOfDevOps 챌린지 등 다른 이유로 소스 제어를 사용하는 사례가 점점 더 많아지고 있습니다.

버전 관리가 없다면 소프트웨어 개발자 팀은 어떻게 이런 일을 처리할 수 있을까요? 저는 프로젝트를 진행하면서 상황을 추적하는 것만으로도 충분히 힘들다는 것을 느낍니다. 저는 그들이 코드를 각 기능 모듈로 분리할 것이라고 예상합니다. 아마도 퍼즐 조각을 한데 모은 다음 릴리스하기 전에 문제와 이슈를 파악했을 것입니다.

버전 관리를 통해 우리는 단일 소스를 확보할 수 있습니다. 여전히 서로 다른 모듈에서 작업할 수 있지만 협업이 더 잘 이루어질 수 있습니다.

여기서 한 가지 더 언급할 것은 버전 관리의 이점을 누릴 수 있는 것은 개발자뿐만 아니라 모든 팀원이 가시성을 확보할 수 있을 뿐만 아니라 프로젝트 관리 도구도 여기에 연결하여 작업을 추적할 수 있다는 것입니다. 다른 모듈에서 다룰 Jenkins와 같은 빌드 머신도 있을 수 있습니다. 시스템을 빌드하고 패키징하여 배포 테스트와 메트릭을 자동화하는 도구입니다.

Git이란 무엇인가요?

Git은 소스 코드 또는 모든 파일의 변경 사항을 추적하는 도구이며, 오픈소스 분산 버전 관리 시스템이라고도 할 수 있습니다.

시스템에서 Git을 사용할 수 있는 방법은 여러 가지가 있는데, 가장 일반적으로는 커맨드라인에서 사용하는 것이 가장 일반적이지만, GUI와 Visual Studio Code와 같은 도구에서도 Git을 인식하는 작업을 활용할 수 있습니다.

이제 로컬 머신에 Git을 설치하기 전에 개략적인 개요를 살펴보겠습니다.

앞서 만든 폴더를 살펴보겠습니다.

이 폴더를 버전 제어에 사용하려면 먼저 git init 명령을 사용하여 이 디렉토리를 초기화해야 합니다. 지금은 이 명령이 디렉토리를 컴퓨터 어딘가에 있는 데이터베이스의 리포지토리로 저장한다고 생각하면 됩니다.

이제 몇 가지 파일과 폴더를 만들 수 있으며 소스 코드가 시작될 수도 있고 이미 여기에 무언가가 있을 수도 있습니다. 우리는 git add . 명령을 사용하여 디렉토리의 모든 파일과 폴더를 스냅샷에 넣을 수 있지만 아직 해당 데이터베이스에 아무것도 커밋하지 않았습니다. 우리는 단지 .가 있는 모든 파일을 추가할 준비가 되었다고 말하는 것입니다.

이제 파일을 커밋하고 싶으면 git commit -m "My First Commit" 명령으로 이 작업을 수행합니다. 커밋에 대한 설명을 할 수 있으며 각 커밋에 대해 무슨 일이 일어났는지 알 수 있도록 도와줍니다.

이제 프로젝트의 히스토리에서 어떤 일이 일어났는지 확인할 수 있습니다. git log 명령어를 사용합니다.

samplecode.ps1라는 파일을 추가로 생성하면 상태가 달라집니다. 또한 git status를 사용하여 리포지토리의 상태를 확인할 수 있는데, 커밋할 항목이 없음을 보여주며 samplecode.ps1이라는 새 파일을 추가할 수 있습니다. 그런 다음 동일한 git status를 실행하면 커밋할 파일이 있는 것을 볼 수 있습니다.

git add samplecode.ps1명령을 사용하여 새 파일을 추가한 다음git status를 다시 실행하면 파일이 커밋될 준비가 된 것을 확인할 수 있습니다.

그런 다음 git commit -m "My Second Commit" 명령을 실행합니다.

git status를 한 번 더 입력하면, 모든 것이 다시 깨끗해졌음을 확인할 수 있습니다.

이제 최신 변경 사항과 첫 번째 커밋을 보여주는 git log 명령을 사용할 수 있습니다.

커밋 사이의 변경 사항, 즉 어떤 파일이 추가되거나 수정되었는지 확인하려면 git diff b8f8 709a를 사용하면 됩니다.

그러면 새 파일을 추가한 경우 변경된 내용이 표시됩니다.

나중에 더 자세히 설명하겠지만 커밋을 이동하면서 시간 여행을 할 수 있습니다! 커밋 번호를 사용하면 git checkout 709a 명령을 사용하여 새 파일을 잃지 않고 시간을 거슬러 올라갈 수 있습니다.

마찬가지로 커밋 번호와 같은 방법으로 앞으로 이동하고 싶을 수도 있고, 여기서 git switch - 명령을 사용하여 작업을 취소할 수도 있습니다.

TLDR;

  • 프로젝트 히스토리 추적하기
  • 프로젝트의 여러 버전 관리
  • 개발자 및 더 넓은 범위의 팀과 도구 간에 코드 공유
  • 팀워크 조정
  • 아, 그리고 시간 여행!

너무 많은 내용을 설명한 것 같지만, 어떤 명령어를 사용하는지 몰라도 버전 관리의 큰 그림을 이해할 수 있기를 바랍니다.

다음에는 로컬 머신에 Git을 설치 및 설정하고 Git을 통해 얻을 수 있는 다른 사용 사례와 명령어에 대해 좀 더 자세히 살펴보겠습니다.

자료

Day 36에서 봐요!