[오픈 소스 프로그래밍] Git

OSS의 관리를 위해 개발자는 수천 명이 있고, 수십 만개의 파일, 그리고 다른 시차에서 전 세계로 퍼져있는 사람들이 있습니다.

심지어 다양한 프로세서를 사용하고, 이전의 버전들이 필요하기도 합니다.

 

이러한 관리를 vcs를 통해서 합니다. vcs는 code base를 관리합니다.

이때 code base는 코드, 문서, 빌드 tool, 설정 파일 등을 모두 포함합니다.

 

---

1. VCS (version control system)

 

 

VCS는 아래와 같은 점들을 도와줍니다.

• 소스코드의 변경을 관리
• 수정의 흔적을 보관함
• 필요하다면 이전 버전으로 Roll back
• 팀이 동시에 작업할 수 있게 해줌
• 테스트 및 배포 프로세스를 자동화 해줌

Benefits

• 이식성
• Branching and mergin
  • Manual mergint is difficult and messy
• Rollback to clean safe point

 

VCS의 기본적인 컨셉은

• Check-out the code
• Work on the local copy
• Diff - 파일 간 차이를 알려주는 유틸리티
• Commit your work to the server
• Update
• Conflict

잘 알려진 VCS로는 CVS, SVN (Subversion), Mercurial, Git이 있습니다.

 

 

1.1 CVS (Concurrent Versions System)

 

CVS는 다양한 개발자들이 동시에 접속이 가능합니다.

하나의 Repository를 가지고 있고, version마다 Diff를 알려줍니다.

하지만 중앙 집중화의 방식 때문에 서버가 터지면 큰일이 납니다. 즉, single point of failure입니다.

 

 

1.2 SVN (Subversion)

 

중앙 집중화는 CVC와 같습니다.

하지만 CVS보다 좋은 점은 CVS는 파일마다 변경 사항을 가지고 있지만, SVN은 revision history를 가지고 있습니다.

또한 Atomic commit으로 인해 커밋이 실패하면 초기로 돌아갑니다.

반면에 CVS는 commit이 실패하면 앞의 파일은 커밋이 되고, 뒤의 파일은 커밋이 안 됩니다.

 

 

1.3 Git

 

모두가 잘 알고 있는 Git입니다. 

Git은 분산 형태를 가지고 있습니다.

이때 모든 contirbutor는 각자 repository의 복사본을 가지고 있습니다.

Commit은 local copy를 변경합니다.

 

Git의 장점은 다음과 같습니다.

• Speed
  
  • VCS, CVS에 비해 매우 빠르다 - 메타데이터로 전송하기 때문
• Space
  
  • 압축이 파일 단위가 아닌 repository 단위로 일어납니다.
  • push/pull 데이터 전송의 local size를 최소화 합니다.
• Simplicity
  • 모델이 단순합니다.
• Large userbase with robust tools

Git interface는 우리가 익히 알고 있는 Github가 있습니다.

 

---

2. Github

 

 

자세한 명령어는 다음에 올리겠습니다.

 

이때 Branch라는게 있는데, 동시에 작업하기 위한 가지라고 생각하면 됩니다.

같이 하기 때문에, 여러개 생겨도 문제가 되지 않으며 나중에 master branch로 merge하면 됩니다.

 

 

이런 방식을 통해서 새로운 특성을 평행하게 테스트할 수 있고, 다른 branch의 수정과 충돌을 피할 수 있습니다.

 

따라서 브랜치는 작업자들이 새로운 작업을 테스트할 수 있는 공간이고, 다른 작업과의 충돌을 막아준다.

 

새로운 Branch에서 수정을 한 후, master branch에 pull request를 요청할 수 있습니다.

Master Branch에서 Merge pull request를 하면 내 수정사항이 비로소 merge가 됩니다.

 

이것도 자세한 명령어는 다음에..

 

아무튼 merge를 하는 방식에는 크게 세 가지가 있습니다.

• Create a merge commit
• Squash and merge
• Rebase and merge

 

2.1 Create a merge commit

 

그냥 두 개의 파일을 하나로 만듭니다.

이때 모든 변경 이력을 합칩니다.

여기서 Merge Commit은 C와 Init을 모두 부모로 가지고, C는 B, B는 A, A는 Init을 부모로 가지게 됩니다.

 

 

2.2 Squash and Merge

 

 

각자 commit 되었던 a, b, c를 합쳐서 하나의 새로운 commit을 생성하고 브랜치에 추가합니다.

새롭게 생성된 a, b, c 통합 commit은 부모를 Init 하나만 가지게 됩니다.

 

 

2.3 Rebase and Merge

 

 

 

이때 각자 commit된 a, b, c는 관계를 그대로 유지하면서 메인 branch에 추가됩니다.

 

시간의 순서대로 배치됩니다.

 

 

 

오픈소스프로젝트 진행 시 팀장이 해야할 일

 

작업할 repository를 생성

팀원을 collaborators로 추가

각자 역할에 나눠서 브랜치 생성

팀원이 새로운 브랜치를 만들어서 pr을 날리면, 팀장은 merge한다.

그리고 브랜치를 관리함

 

 

 

감사합니다.

 

 

지적 환영합니다.