Git : Repository, fork, branch, clone, track에서이 단어의 의미는 무엇입니까?

130

나는 여기서 의미론에 대해 솔직히 명확하지 않다. 그들은 모두 코드 + 역사 단위의 사본 / 변형에 관한 것이지만 과거에 내가 말할 수 있는지 확실하지 않습니다. 이 논리적 구조가 어딘가에 설명되어 있습니까?

git branch clone

— 에릭 앤더슨
소스

5

Pro Git 서적 ( progit.org/book ) 의 첫 몇 장을 읽는 것이 좋습니다 .

— ewall

61

+1. 많은 git 튜토리얼은 특정 단어의 의미 또는 git 작동 방식을 설명하지 않고 특정 작업을 수행하는 방법을 보여줍니다. 이러한 주제를 다루는 리소스를 요구하는 것은 합법적 인 질문입니다.

— Daniel Stutzbach

14

Daniel의 의견을 더 +1 할 수 있기를 바랍니다. 일부 용어 (예 : 저장소)의 의미는 분명해야하지만 그 관계가 항상 (분기와 포크) 관계는 아니며 중앙 VCS에 익숙한 사람이 실제 의미를 쉽게 잘못 해석합니다. 게다가 Pro Git의 "지점은 무엇입니까?"를보십시오. 섹션-기본 사용자가 실제로 블롭과 나무에 대해 알고 싶습니까, 아니면 분기가 무엇인지 정 성적으로 알고 싶습니까?

— Cascabel

1

@DanielStutzbach 그것은 책에서 명확하지 않은 것들에 대한 의견을 제출할 수 있습니다. (나는 그것을 말할 올바른 용어를 모른다.) 나는 그것을했다. 나는 그 책이 저장소가 무엇인지 정의해야한다고 말했다. 나는 무언가를 잘 이해하는 사람들로부터 개념적 자료를 얻는 것이 매우 어렵다는 것에 동의합니다. 그 책은 (현재)이 맥락에서 데이터베이스를 정의하지 않고 데이터베이스에 대해 이야기하고 저장소가 무엇인지에 대해서는 아무 것도 말하지 않습니다.

— user34660

146

저장소는 단순히 작업 기록이 저장되는 장소입니다. .git작업 사본 의 하위 디렉토리 인 작업중인 파일의 최신 상태 사본에 종종 있습니다 .

프로젝트를 포크하고 (특정 시점에서 누군가의 저장소에서 소스를 가져 와서 자신의 다른 변경 사항을 적용하려면) 원격 저장소를 복제하여 사본을 작성한 다음 로컬 저장소에서 직접 작업을 수행하십시오. 커밋 변경.

리포지토리 내에는 자체 리포지토리 내의 포크 인 분기가 있습니다. 브랜치는 저장소에 조상 커밋을 가지며 변경 사항과 함께 해당 커밋과 다릅니다. 나중에 분기 변경 사항을 병합 할 수 있습니다. 브랜치를 사용하면 여러 개의 서로 다른 기능을 한 번에 작업 할 수 있습니다.

원격 리포지토리에서 개별 분기를 추적 할 수도 있습니다. 이를 통해 다른 개인의 지점에서 변경 사항을 가져 와서 자신의 지점으로 병합 할 수 있습니다. 이것은 나와 친구가 새로운 기능을 함께 작업하는 경우에 유용 할 수 있습니다.

온라인으로 훌륭한 git book이 많이 있습니다. 공식 자습서 및 커뮤니티 북뿐만 아니라 시작하기 위해 ProGit 및 Git Magic 을 살펴보십시오 .

— NFM
소스

물론 F 매뉴얼과 튜토리얼을 읽는 것이 기본입니다. 그러나 이것은 전체 내용에 대한 훌륭한 요약으로 보입니다. 매우 감사!

— brasofilo

로컬 작업 디렉토리를 새 분기 ( "git checkout <new_branch>")로 전환 할 수 있습니다. 이 경우 로컬 작업 디렉토리의 파일은 전환하려는 분기의 컨텐츠로 대체됩니다. Git "database"(숨겨진 .git 폴더)의 이전 브랜치에서 수행 한 모든 커밋 된 변경 사항 ( "git commit")을 저장하고 파일을 다시 전환 할 수 있도록합니다.

— KrisWebDev 2016 년

3

역사적으로 어떤 VCS를 사용했는지에 관계없이 포크와 분기는 두 가지로 간주되었다는 특별한 언급이 필요하다고 생각합니다. 분기는 개발자 간의 호의적이고 암시적인 계약으로 간주되었습니다. Forking은 프로젝트를 진행하는 개발자가 어떤 것에 동의하지 않고 부분적으로 결정하기로 함을 암시하면서 더욱 심각했습니다. 성공적인 포크는 일반적으로 양측이 합의한 후 나중에 하나의 프로젝트로 다시 병합되었습니다. 그 이후로 Git (및 GitHub)은 이러한 용어를 흐리게했으며 두 용어는 기본적으로 동일한 아이디어를 나타내지 만 다른 방식으로 나타냅니다.

— redteam316

리포지토리에 프로젝트 파일이 없습니까? 당신 은 당신의 작업의 역사가 저장되는 장소를 말합니다 . 그게 다야? 파일의 역사는 있지만 파일 자체는 아닙니다.

— user34660

13

RTFM으로 내 자신의 질문에 대답하겠습니다.

그러나 읽기 이 좋은 설명서를. 저자가 말한 것처럼 :

“내가 얻은 결론은 Git의 작동 방식을 이해해야 Git을 실제로 사용할 수 있다는 것입니다. 어떤 시간에 어떤 명령을 실행해야하는지 간단히 기억할 수 있지만, 문제가 발생하거나 문제가 발생하기 전에는 시간 문제 일뿐입니다.

“Git에있는 기존 리소스의 절반은 불행히도 그와 같은 접근 방식을 취합니다. 즉, 언제 실행할 명령을 안내하고 해당 명령을 모방하면 잘 수행해야한다고 기대합니다. 나머지 절반은 모든 개념을 다루지 만, 내가 본 것에서 Git의 작동 방식을 이미 이해하고 있다고 가정하는 방식으로 Git을 설명합니다.”

— 에릭 앤더슨
소스

이 소개는 sbf5.com/~cduan/technical/git 로 옮겨 간 것으로 보입니다 . 원래 URL은 여전히 작동합니다.

— 에릭 앤더슨

1

이것은 맥락에서 사실입니다. 즉시 생산적이거나 실제로 코드를 체크인 해야하는 경우 git 작동 방식에 대해 깊이 이해하지 않아도됩니다. 튜토리얼은 괜찮습니다. 이것이 내가 자식에 들어가는 방법입니다. 그러나 브랜치, 포크, 리베이스 및 기타 고급 작업 만들기와 같이 더 발전해야 할 경우 특히 배경이 중앙 집중식 소스 컨트롤에있는 경우 git의 작동 방식을 알아야합니다.

— Phil

3

이 GoogleTechTalk 는 언어를 배우면서 실제로 배후에서 일어나는 일을 배우는 Git에 대한 환상적인 소개입니다. 그것은 초기에 Git에 기고 한 사람이 주었으며 2007 년에 Git을 소개하는 방법으로이 연설을했습니다. 이 강연을 보면 저장소, 포크, 브랜치 등과 같은 각 단어가 무엇인지 알 수있을뿐만 아니라 각각의 단어가 만들어 지거나 병합 될 때 장면 뒤에서 무슨 일이 일어나고 있는지 알 수 있습니다.

주소는 길지만 매우 유익합니다. 또한 Git을 다른 버전 제어 시스템과 대조하여 Git이 왜 만들어 졌는지, 그리고 다른 제어 시스템에 비해 비교 이점이 무엇인지에 대한 통찰력을 얻습니다. 대화가 오래되었지만 일어나서 실행하는 것이 매우 도움이됩니다. 매뉴얼에 들어가기 전에 이것을 보았습니다. 결과적으로 상황이 훨씬 더 합리적이라고 생각합니다.

— 매트
소스