[Git] 버전 관리 시스템(VCS) history

Git과 버전 관리 시스템

소프트웨어 개발에서 버전 관리는 핵심적인 과정입니다. 과거에는 수동 백업과 릴리스 관리를 통해 이루어졌던 이 작업이, 오늘날에는 훨씬 더 체계적이고 효율적인 방식으로 발전했는데 그 중심에는 Git이라는 강력한 도구가 있습니다.

버전 관리의 진화

과거의 방식

초기의 소프트웨어 개발에서는 버전 관리를 수동으로 수행했습니다. 개발자들은 프로젝트의 각 버전을 수동으로 백업하고 관리해야 했고, 이는 시간과 노력이 많이 드는 작업이었습니다. 또한 여러 명이 동시에 작업할 경우 충돌이 발생하기 쉬웠습니다.

 

버전 관리 시스템

현대에는 세 가지 주요 유형의 버전 관리 시스템이 사용됩니다:

1. 로컬 버전 관리 시스템 (Local VCS): 개인 컴퓨터에서 버전을 관리합니다. 예를 들어 RCS와 같은 시스템은 파일의 로컬 버전을 추적합니다. 이는 간단하지만, 협업에는 적합하지 않습니다.
2. 중앙집중식 버전 관리 시스템 (CVCS): 중앙 서버에서 모든 버전을 관리합니다. 대표적인 예로는 SVN(Subversion)이 있습니다. 이 방식은 협업을 가능하게 하지만, 중앙 서버에 의존적이라는 단점이 있습니다. 서버에 문제가 생기면 모든 사용자가 영향을 받게 됩니다.
3. 분산 버전 관리 시스템 (DVCS): Git과 Mercurial이 이에 속합니다. DVCS는 모든 개발자가 전체 저장소의 복사본을 가지고 있어 더 유연하고 안전합니다. 각 개발자는 독립적으로 작업할 수 있으며, 필요할 때 중앙 서버에 변경 사항을 푸시할 수 있습니다.

	로컬 VCS	중앙집중식 VCS (CVCS)	분산 VCS (DVCS)
예시	RCS	SVN (Subversion)	Git, Mercurial
저장소 위치	개인 컴퓨터	중앙 서버	로컬 및 중앙 서버 모두
협업	불가능	가능	가능
서버 의존성	없음	높음	낮음
데이터 안전성	상대적으로 낮음	서버 문제 시 위험	높음
초기 설정 복잡성	낮음	중간	높음
장점	간단하고 사용하기 쉬움	협업 가능, 중앙에서 버전 관리	유연하고 안전함, 독립적으로 작업 가능
단점	협업에 적합하지 않음	서버 문제 시 모든 사용자가 영향을 받음	초기 설정 복잡, 로컬 저장소 공간 많이 필요

Git: 현대 개발의 핵심 도구

https://en.wikipedia.org/wiki/Linus_Torvalds

Linus Torvalds - Wikipedia

 

Git은 Linus Torvalds가 Linux 커널 개발을 위해 만든 분산 버전 관리 시스템입니다. Git의 주요 장점은 다음과 같습니다:

1. 효율적인 버전 관리: Git은 모든 변경 사항을 세밀하게 추적하고 필요시 이전 버전으로 쉽게 되돌아갈 수 있게 합니다. 각 커밋은 고유한 SHA-1 해시 값을 가지며, 이는 변경 이력을 정확하게 추적할 수 있게 합니다.
2. 뛰어난 협업 지원: 여러 개발자가 동시에 작업할 수 있습니다. 각 개발자는 자신만의 브랜치를 생성하여 독립적으로 작업하고, 나중에 변경 사항을 병합할 수 있습니다. Git의 분산 특성 덕분에, 개발자들은 중앙 서버 없이도 작업을 계속할 수 있습니다.
3. 오프라인 작업 가능: Git은 로컬 저장소를 사용하기 때문에 인터넷 연결 없이도 대부분의 작업을 수행할 수 있습니다. 이는 개발자들이 어디서든 작업을 계속할 수 있게 합니다.
4. 데이터 안정성: Git은 분산 저장소 구조로 인해 데이터 손실 위험이 낮습니다. 각 개발자의 로컬 저장소가 전체 프로젝트의 백업 역할을 합니다.

 

GitHub: Git을 더 강력하게 만드는 공간

 

GitHub는 Git을 기반으로 한 웹 호스팅 서비스로, Git의 기능을 더욱 확장시켜줍니다. GitHub의 주요 기능을 살펴보겠습니다:

1. 프로젝트 호스팅: GitHub는 공개 또는 비공개 프로젝트를 온라인에서 관리할 수 있는 플랫폼을 제공합니다. 이를 통해 전 세계 어디서든 프로젝트에 접근하고 협업할 수 있습니다.
2. 협업 도구: GitHub는 이슈 트래킹, 풀 리퀘스트, 코드 리뷰 등의 다양한 협업 기능을 제공합니다. 이슈 트래킹을 통해 버그나 기능 추가 요청을 관리하고, 풀 리퀘스트를 통해 코드 변경 사항을 검토하고 병합할 수 있습니다. 이는 개발자들이 보다 체계적으로 협업할 수 있게 합니다.
3. CI/CD 통합: GitHub Actions를 통해 자동화된 테스트와 배포가 가능합니다. 이를 통해 코드 변경 사항이 자동으로 테스트되고, 문제가 없으면 배포까지 이어질 수 있습니다. 이는 소프트웨어 개발의 연속성을 유지하고 품질을 보장하는 데 큰 도움이 됩니다.

 

---

Git 대표 명령어

• Working Directory는 파일이 실제로 존재하는 로컬 디렉토리, 여기서 파일을 수정하고, 추가하거나 삭제
• Staging Area는 커밋할 파일들을 임시로 보관하는 공간, 커밋 전에 파일을 추가하거나 변경 내용을 준비하는 단계
• Local Repository는 로컬 시스템에 저장된 프로젝트의 히스토리를 관리하는 저장소, 모든 커밋 기록이 이곳에 저장
• Remote Repository는 네트워크를 통해 접근 가능한 원격 서버에 있는 저장소, 팀원들과 협업할 때 주로 사용

각 영역 간의 명령어 흐름은 다음과 같습니다:

1. git add (Working Directory -> Staging Area)
   • 변경된 파일을 Working Directory에서 Staging Area로 이동
   • 예: git add <파일명>
2. git commit (Staging Area -> Local Repository)
   • Staging Area에 있는 파일들을 Local Repository에 커밋
   • 예: git commit -m "커밋 메시지"
3. git push (Local Repository -> Remote Repository)
   • Local Repository의 커밋을 Remote Repository로 전송
   • 예: git push origin <브랜치명>
4. git fetch (Remote Repository -> Local Repository)
   • Remote Repository에서 변경된 내용을 가져옵니다. Local Repository에 변경 내용이 추가되지만, Working Directory는 업데이트되지 않됨
   • 예: git fetch
5. git pull (Remote Repository -> Local Repository -> Working Directory)
   • git fetch와 git merge를 결합한 명령어입니다. Remote Repository에서 변경된 내용을 가져와 Local Repository와 Working Directory를 동시에 업데이트
   • 예: git pull
6. git merge (Local Repository -> Working Directory)
   • Local Repository의 브랜치를 Working Directory로 병합
   • 예: git merge <브랜치명>
7. git checkout (Local Repository -> Working Directory)
   • 특정 브랜치나 커밋으로 Working Directory를 변경.
   • 예: git checkout <브랜치명>
8. git clone (Remote Repository -> Local Repository -> Working Directory)
   • Remote Repository를 복제하여 Local Repository와 Working Directory를 설정
   • 예: git clone