원글 페이지 : 바로가기
버전관리 도구란 동일한 소스 코드, 문서 등을 여러 버전으로 관리하는 것이다. 버전 관리 도구를 통해서 여러 개발자들과 협업을 할 수 있고 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전으로 다시 돌릴 수 있다. 버전관리 도구하면 가장 먼저 생각나는것이 “Git”이다. 하지만 버전관리 도구에 대해서 공부하면서 다양한 방식의 버전관리가 있다는 것을 알게되었다. 1) 로컬형 버전관리 시스템(Local VCS) : 버전 관리 자료가 로컬 컴퓨터의 공유 폴더에 저장되어 관리한다. < 공유 폴더 방식이 돌아가는 방식> -> 개발자가 개발이 완료된 파일을 공유 폴더로 복사 -> 이 파일을 담당자가 파일을 자기 PC로 복사한 후 이상유무 확인 -> 오류가 발견되면 수정을 의뢰하고, 없다면 개발자들이 동작 여부를 확인 이러한 공유 폴더 방식은 비교적 사용하기 간단하나 상대적으로 다른 사람들과 공유가 어렵고 사용자의 컴퓨터에 문제가 생겼을때 복구가 어렵다. 2) 중앙형 버전관리 시스템(Center VCS) : 버전 관리 자료가 사용자의 컴퓨터가 아닌 중앙 서버에서 관리한다. < 중앙 서버 방식이 돌아가는 방식> -> 중앙 서버의 자료를 개발자의 개별 PC로 복사하여 작업한 후 변경된 내용을 서버에 반영한다. 팀원은 최신 자료를 다운받을 수 있다. 하나의 중앙 서버에서 관리할 수 있기 때문에 편리하지만 중앙 서버에 문제가 생길경우 복구하지 전까지는 다른 개발자와의 협업과 버전 관리 작업을 할 수 없게 된다. 3) 분산형 버전관리 시스템(Division VCS) : 중앙에서 관리하고 있는 모든 이력을 가진 저장소 전체를 복사해서 사용자의 컴퓨터로 가져와 사용한다. <분산형 버전관리 방식이 돌아가는 방식> -> 서버(저장소, Repository)에 최신 버전의 파일들과 변경내역이 저장된다 -> 서버의 자료를 복사해와 작업 후 변경된 자료를 서버에 반영한다(commit). -> 개별작업은 중심 디렉토리에서 수행되며 디렉토리 안에 추가 작업을 위해서 별도의 서브 디렉터리를 만들어서 작업한후 중신 디렉터리와 병합한다(merge). 사용의 로컬 컴퓨터로 개발한것을 중앙 서버로 보낼 수 있고 중앙 서버의 진행상황을 사용자의 컴퓨터로 갱신해서 사용할 수 도 있다. 분산형의 경우 중앙서버에 문제가 생겨도 사용자의 local 저장소에 저장된 데이터로 복구시킬 수 있다. 모든 이력을 가진 저장소 전체를 복사하는 것이므로 서버와 일부 사용자의 데이터가 날아가더라도 다른 팀원들의 저장소 정보를 통해 복구가 가능하다. 국제적으로나 국내적으로 가장 많이 사용되고 있는 분산형 버전과리 시스템은 Git이다. git을 통해 다른 개발자들과 협업이 쉽게 이루어질 수 있고 버전기록을 통해 오류가 발생했을때 이전의 코드로 되돌 수 있다. 또한 코드가 변경되는 기록, 과거 기록이 저장되어 있기 때문에 오류의 추적이 용이하다. 이전에 팀프로젝트를 진행했을 때도 git통해 협업을 진행했다. 1. GitHub에 해당 프로젝트 repository를 만든후 2. 가장 기본적인 뼈대의 코드를 main 브랜치에 저장한 후 각자 다운 받고 3. 새로운 기능과 수정이 이루어질 경우 따로 서브 브랜치를 만든 후 변경하고 4. 팀원들의 리뷰 후에 또다시 수정하거나 오류가 없다면 main에 병합하는 과정으로 진행되었다. 개인프로젝트만 진행하다가 github을 통해 협업을 진행하니 신경써야하는 부분이 여러가지였다. 첫번째, 새로운 기능 개발이나 코드 수정이 필요할때는 main 브랜치의 코드를 수정하는 것이 아니라 따로 서브 브런치를 따서 만들어야된다는 것이다. 만약 test 브런치가 아닌 main 브랜치에 바로 코드를 변경한다면 다음과 같은 단점이 발생하게 된다. 1. 안정성 감소 : 테스트 되지 않은 코드가 프로덕션 환경에 바로 반영될 수 있어 예상치 못한 동작이나 버그 발생 가능성을 높이고 안정성을 저하시킬 수 있다. 2. 다른 개발자들의 작업에 영향 : main 브랜치를 직접 수정하여 동기화가 발생한다면 다른 개발자들의 변경사항과 충돌이 발생할 가능성이 높다. 이는 협업 프로세스를 혼란스럽게 만들고 이를 해결하기 위해 추가적인 조치가 필요하게 된다. 두번째, github에 업데이트된 코드를 commit할때 팀원들이 무슨 목적으로 어떻게 코드가 업데이트 되었는지 쉽게 알기 위해서 commit message convention을 미리 정해놓는것이 효율적이라는 것이다. 이와 관련된 내용은 아래 페이지에 정리해놓았다. https://in-my-universe23.tistory.com/entry/Git-%EC%BB%A4%EB%B0%8B%EC%BB%A8%EB%B2%A4%EC%85%98%EC%9D%B4%EB%9E%80 Git 커밋컨벤션이란? (Git Commit Message Convention)이란… 커밋메세지를 작성할때 사용하는 규칙같은 것이다. ⇒ 커밋 메세지를 어떻게 작성할지 개인 또는 팀의 스타일에 맞게 규칙을 정한 후에 , 정해진 양식대로 커밋메 in-my-universe23.tistory.com <참고 자료> https://velog.io/@clay/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EB%B2%84%EC%A0%84-%EA%B4%80%EB%A6%AC-%EB%8F%84%EA%B5%AC 소프트웨어 버전 관리 도구 공유 폴더 방식은 버전 관리 자료가 로컬 컴퓨터의 공유 폴더에 저장되어 관리되는 방식으로, 다음과 같은 특징이 있다.개발자들은 개발이 완료된 파일을 약속된 공유 폴더에 매일 복사한다.담 velog.io https://velog.io/@muman_kim/Git%EB%B6%84%EC%82%B0%ED%98%95-%EB%B2%84%EC%A0%84%EA%B4%80%EB%A6%AC%EC%8B%9C%EC%8A%A4%ED%85%9C Git(분산형 버전관리시스템)이란? git에 대한 내용을 설명하는 입장에서 한번 나의 생각을 정리보았다. 생각을 정리한다는 것은 나의 머릿속 git이란 단어를 들었을 때 어떻게 설명을 해야할까?를 정하고 개념과 개념을 설명하는 velog.io