github - 在学习GIT，一个小问题

Question

为什么别人总说 linus 反感SVN，是因为他必须连网才能使用，所以不用他，说得好像GIT不联网就能使用一样，不联网他咋提远程服务器啊？

phpcn_u1582 · Answer

다른 사람의 코드와 병합하려면 결국 인터넷에 연결해야 하는 것이 사실입니다.

그런데 그 문장이 의미하는 바는 Git 로컬 창고가 있기 때문에 버전 관리를 위해 인터넷에 연결할 필요가 总是 없다는 것입니다. 브랜치 생성, 제출, 코드 롤백 등 많은 버전 관리 관련 작업을 인터넷 연결 없이도 로컬에서 수행할 수 있습니다.

항상 사무실에 앉아 LAN을 사용하여 작업하는 일반 소규모 팀의 경우 Git의 이점을 충분히 활용하지 못할 수도 있습니다. 즉, 일반적인 상황에서는 SVN이면 충분합니다.

그러나 프로젝트 구성원이 어디에나 분산될 수 있는 "전통적인" 팀의 경우 Git가 더 나을 수 있습니다.

원래는 댓글로 직접 답변드리고 싶었는데 내용이 많아서 여기에 추가하겠습니다.

혼란스러운 모습을 보면 版本管理의 본질을 잘 이해하지 못할 수도 있다는 것을 알 수 있습니다. 버전 관리의 버전은 소프트웨어의 최종 릴리스 버전만을 의미하는 것이 아닙니다. 0.8, 1.0 및 2.0은 최종 사용자를 위한 버전일 뿐입니다. 版本管理의 版本은 일반적으로 개발 과정 중 프로그램의 중간 상태를 나타냅니다. 이러한 버전 중 일부는 공개 버전으로 병합되어야 하며 일부는 결국 폐기되거나 이후 다른 프로젝트로 발전할 수도 있습니다. Ctrl+S을 누를 때마다 버전이 생성된다고 할 수 있습니다.

버전 관리의 본질을 더 잘 설명하기 위해 우리가 일상에서 자주 접하는 몇 가지 예를 더 들어보겠습니다.

시나리오 1

현재 개발 중인 이 기능에 대한 아이디어는 있지만 실현 가능한지는 잘 모르겠어서 먼저 시도해 볼 생각은 있지만 작업 공간에서 직접 변경하고 싶지는 않습니다( SVN의 작업 공간은 종종 기본 버전과 직접적으로 일치합니다. 왜냐하면 이는 기존 코드를 오염시키기 때문입니다. 나중에 이 방법이 실행 가능하지 않다는 것을 알게 되면 관련 코드를 모두 삭제해야 하지만 무엇을 삭제해야 하는지 기억하지 못할 수도 있습니다. 그때에.

SVN과 같은 중앙 집중식 버전 관리 도구에서 구현할 수도 있습니다(너무 많은 기능과 기능이 더 편리할 뿐입니다). 즉, 브랜치를 사용하면 되지만 이 방법으로는 여전히 서버를 자주 처리해야 하고 브랜치를 생성해야 합니다. , 브랜치 삭제, 브랜치 병합, 브랜치에 코드 커밋 등 하지만 실제로는 이 모든 작업을 로컬에서 수행할 수 있습니다(역시 LAN에서는 큰 문제가 아닐 수 있음). 로컬 창고에 지점을 만들고 코드를 작성하여 테스트하면 작동합니다. 만약 그렇지 않다면, 메인 버전에 병합할 수 있습니다. 작동하는지 여부는 중요하지 않습니다.

시나리오 2

특정 제출물에서 프로그램이 잘못된 것을 발견했습니다(예를 들어 특정 기능이 절반만 변경되어 사용할 수 없고, 심지어 컴파일도 실패했는데 이때는 빨리 서버를 롤백할 수 밖에 없었습니다). , 그러나 너무 늦을 수도 있고, 다른 사람이 이미 귀하의 코드를 확인했을 수도 있으므로 문제를 설명하는 그룹 이메일을 보내야 합니다(또는 모두가 함께 있으면 소리를 지르십시오).

하지만 Git에서는 로컬에서 먼저 제출되기 때문에 제출 동작에 버퍼 시간을 주어 다른 사람에게 영향을 주지 않고 제 시간에 실행 취소할 수 있습니다(너무 늦게 발견하면 할 수 있는 일이 없습니다).

시나리오 3

"로컬" 롤백 기능도 있습니다. 기능은 비교적 복잡하고 개발하는 데 며칠이 걸리지만 영향을 주고 싶지 않기 때문에 개발되기 전에 서버에 제출하고 싶지 않습니다. 컴파일이나 실행 오류로 인해 다른 사람들이. 그래서 로컬에서 다 변경해서 제출하고 싶었는데 이 방법으로는 이런 프로그램이 보장되지 않고, 롤백하고 싶거나, 이전 코드와 비교하고 싶은 경우에는 어렵습니다.

일부 도구는 로컬 히스토리 기능도 제공하지만 사용하기가 쉽지 않습니다. 로컬 히스토리는 매번 Ctrl+S 로컬 히스토리를 형성할 수도 있고 형성하지 않을 수도 있습니다. 즉, 지역 역사는 원하는 방식으로 기록을 유지하지 않습니다. 급하게 필요한 역사적 기록이 저장되지 않고, 보다가 한숨만 나올 가능성이 매우 높습니다(이런 문제는 실제로 그렇게 드문 것은 아닙니다)

요약

너무 많이 말씀드렸지만 이는 중앙 집중식과 분산식 사이의 몇 가지 부차적인 예일 뿐입니다. 사실 이 문제는 객체지향과 프로세스지향의 절대적인 좋고 나쁨은 없습니다. 복잡한 프로그램에는 객체지향을 사용하는 것이 더 나을 수도 있지만, 프로세스지향에도 장점이 있습니다. 도구 선택은 팀과 개인의 결정에 따라 다릅니다

ringa_lee · Answer

질문자는 한 사람이 오프라인으로 사용할 수 있는 git의 장점에만 너무 집중하고 있습니다. Git은 분산 구조이므로 데이터 무결성이 svn보다 훨씬 좋을 것이라는 의미입니다. svn Warehouse. 파일 손상이 발생하고(매우 쉽게 발생합니다! 예를 들어 정전) svndump로 내보낸 모든 기록 제출에도 설명할 수 없는 문제가 있습니다.

또한, 대상이 노출될 수 있는 프로젝트의 규모는 아직 상대적으로 작으며, 기본적으로 svn과 같은 git을 여전히 사용하므로 충돌 및 병합 문제에 중점을 둡니다. 제가 말씀드리고 싶은 것은 당연히 충돌은 해결되어야 하지만 버전 관리의 기본 목적은 코드를 병합하고 충돌을 해결하는 것에만 있는 것이 아니라 모든 사람이 다른 사람과 릴리스에 영향을 주지 않고 작업할 수 있도록 하는 것이 가장 중요할 것입니다

우리 회사에서 git을 사용하는 방식은 git flow의 관행을 따릅니다. Master는 트렁크 릴리스(웹 프로젝트이므로 지속적으로 반복되는 안정적인 버전)에 사용되며, 개발은 새로운 개발을 시작하는 모든 사람에게 사용됩니다. 요구사항은 개발 브랜치에서 생성됩니다. 작업을 마친 후 다시 병합하여 개발하고, 릴리스를 만들고, 모든 것이 정상이면 릴리스를 마스터에 병합하고 기다립니다. 다음 릴리스
이것이 개선이라고 말하는 목적은 자신의 기능 브랜치에서 작업할 때 실제로 개발 브랜치에서 일어나는 일에 대해 너무 많이 신경 쓸 필요가 없습니다(중앙 브랜치와 상호 작용할 필요가 없음). 서버), 그러나 기능을 완성하려면 버전 관리가 여전히 필요합니다. 이를 해결하려면 많은 제출이 필요합니다.
긴급하게 복구해야 하는 패치인 경우 마스터에서 핫픽스 브랜치를 생성하고 병합합니다. 변경이 완료된 후 마스터(및 개발)로 돌아가기

이러한 수단을 통해 주로 해결됩니다

새로운 기능의 개발은 다른 새로운 기능의 개발에 영향을 미치지 않습니다(각 기능은 독립적인 분기입니다)
새 버전으로의 업그레이드(개발 시)와 이전 버전(마스터)의 버그 수정은 서로 충돌하거나 영향을 미치지 않으며, 누군가가 개발 중이라는 이유만으로 이전 버전의 마스터에서 버그가 발생하지 않습니다. 새 버전을 즉시 출시하려면 새 버전이 개발될 때까지 기다려야 합니다.

SVN은 가능하지만 브랜치 기능은 본질적으로 웨어하우스의 또 다른 디렉터리라고 할 수 있습니다. 병합 여부는 실제로 속성을 통해 저장되므로 사용하기가 쉽지 않습니다.

보충:

http://git-scm.com/book/zh/v1/%E5%88%86%E5%B8%83%E5%BC%8F-Git-%E4%B8%BA에서 확인하실 수 있습니다. % E9%A1%B9%E7%9B%AE%E4%BD%9C%E8%B4%A1%E7%8C%AE는 많은 Git 모범 사례를 소개했습니다

迷茫 · Answer

중앙집중식과 분산식의 차이점이 바로 이것입니다.