Git에서 사용하는 용어

Git에서 사용하는 용어

---

git 사용법을 배워야 할 것 같습니다. 아마도 좋은 일 (TM) 일 것입니다. 그러나 온라인 가이드와 맨 페이지를 읽으면서 용어를 이해하기가 어렵습니다. 모든 것은 항상 그들 자신이나 다른 설명 할 수없는 용어로 정의됩니다 ( "man git"를 실행하면 내가 의미하는 바를 알 수 있습니다).

따라서 다음 중 일부를 포함하여 용어 정의에 대한 DAG와 유사한 구조가 있습니까 (모두 git man 페이지에서 가져옴!). 아마도 파일 시스템을 시작점으로 사용하고 독자가 svn에 능숙하다고 가정하지 않을 수 있습니다 (나는 아닙니다).

• repo
• 저장소
• 자식
• "놈"
• 인덱스
• 복제하다
• 범하다
• 분기
• 나무
• 상류
• 머리
• 머리
• 버전
• 꼬리표
• 아카이브
• 반점
• 제출
• 변경 세트
• 숨기는 장소
• 아카이브
• 목적
• 기준 치수
• 하위 모듈
• refspec
• 역사

일부에 대한 설명을 찾을 수 있지만 일반적으로 다른 측면에서 설명합니다. 또한 UNIX diff와 같은 다른 컨텍스트에서 알고있는 다른 용어도 있습니다. 그러나 내가 알고 있다고 생각한 다른 것 ...

저장소 (gits? 및 / 또는 tree? 업스트림?과 비슷 함)가 있다는 사실을 수집했습니다.이 저장소를 복사 (클론? 브랜치?)하여 하드 드라이브에 물리적으로 파일을 가져옵니다. 그런 다음 브랜치 (변경 세트와 비슷합니까?), 태그 및 커밋 (패치와 비슷합니까?)이 있지만 그 구분은 명확하지 않습니다. 어떤 파일을 수정합니까? 내 파일을 로컬로 유지하는 것은 무엇이며 인터넷에 내 코드를 제출할 수있는 것은 무엇입니까 (천국이 금지)?

브랜치, 태그 및 커밋과 관련하여 권장되는 작업 방법은 무엇입니까? 그러므로 버전 간 교체가 쉽고 공개적으로 사용 가능한 Git에서 업데이트를 가져 오기가 쉽습니다.

// T, 좌절감을 조절하기 위해 혀를 깨물고 ...

---

다음은 용어집을 완성하기위한 시도입니다 (제 머리 위에서 내 자신의 말을 사용하려고합니다).

• repo, repository : 이력과 구성이 저장된 객체 데이터베이스입니다. 여러 가지를 포함 할 수 있습니다. 종종 작업 트리도 포함됩니다.

• git, "the git": 들어 본 적 없음, 죄송합니다. "the git"은 소프트웨어 자체를 설명 할 수 있지만 확실하지 않습니다.

• 인덱스, 스테이징 영역 : 이것은 작업 트리와 저장소 사이의 '캐시'입니다. 인덱스에 변경 사항을 추가하고 다음 커밋을 단계별로 빌드 할 수 있습니다. 색인 콘텐츠가 마음에 들면 여기에서 커밋을 만들 수 있습니다. 또한 실패한 병합 동안 정보를 유지하는 데 사용됩니다 (사용자 측, 해당 측 및 현재 상태).

• clone : 저장소의 복제본 ( "다른 저장소") 또는 그렇게하는 행위 ( "저장소 복제 (새 복제본 생성)")

• commit : 특정 시간의 프로젝트 상태. 부모 커밋에 대한 포인터 (병합의 경우 : 여러 부모)와이 시점의 디렉토리 구조에 대한 포인터를 포함합니다.

• branch : 다른 개발 라인. git의 브랜치는 커밋을 가리키는 "레이블"일뿐입니다. 부모 포인터를 통해 전체 기록을 얻을 수 있습니다. 기본적으로 브랜치는 리포지토리에만 로컬입니다.

• 트리 : 기본적으로 디렉토리를 말합니다. 파일 (blob) 및 하위 디렉터리 (트리) 목록 일뿐입니다. (하위 모듈을 사용하는 경우 목록에 커밋이 포함될 수도 있지만 이는 고급 주제입니다)

• 업스트림 : 저장소를 복제 한 후 "원래"저장소를 "업스트림"이라고 부르는 경우가 많습니다. git에서는 별칭이 지정됩니다.origin

• 헤드 : 브랜치의 최상위 커밋 (라벨이 가리키는 커밋)

• HEAD : 현재 체크 아웃 된 커밋을 설명하는 기호 이름입니다. 종종 최상위 커밋

• 버전 : 커밋과 동일 할 수 있습니다. 프로젝트의 출시 버전을 의미 할 수도 있습니다.

• 태그 : 커밋 (또는 트리 또는 블롭) 중 하나에 제공되는 설명적인 이름입니다. 메시지 (예 : 변경 로그)를 포함 할 수도 있습니다. 태그는 GPG로 암호화 서명 할 수 있습니다.

• 아카이브 : 간단한 아카이브 (.tar, .zip), 특별한 wrt git은 없습니다.

• patch: A commit exported to text format. Can be sent by email and applied by other users. Contains the original auther, commit message and file differences

• submission: no idea. Submitting a patch to a project maybe?

• changeset: Synonym for "commit"

• stash: Git allows you to "stash away" changes. This gives you a clean working tree without any changes. Later they can be "popped" to be brought back. This can be a life saver if you need to temporarily work on an unrelated change (eg. time critical bug fix)

• object: can be one of commit, tree, blob, tag. An object has associated its SHA1 hash by which it is referenced (the commit with id deadbeaf, the tree decaf). The hash is identical between all repositories that share the same object. It also garuantees the integrity of a repository: you cannot change past commits without changing the hashes of all child commits.

• (module,) submodule: A repository included in another repository (eg. external library). Advanced stuff.

• revspec: A revspec (or revparse expression) describes a certain git object or a set of commits through what is called the extended SHA1 syntax (eg. HEAD, master~4^2, origin/master..HEAD, deadbeaf^!, …)

• refspec: A refspec is pattern describing the mapping to be done between remote and local references during Fetch or Push operations

• history: Describes all ancestor commits prior to a commit going back to the first commit.

---

Things you didn't mention, but are probably good to know:

Everything you do is local to your repository (either created by git init or git clone git://url.com/another/repo.git). There are only a few commands in git that interact with other repositories (a.k.a. teh interwebz), including clone, fetch, pull, push.

Push & pull are used to syncronize repositories. Pull fetches objects from another repository and merges them with your current branch. Push is used to take your changes and push them to another repository. You cannot push single commits or changes, you only can push a commit including its complete history.

A single repository can contain multiple branches but does not need to. The default branch in git is called master. You can create as many branches as you want, merging is a piece of cake with git. Branches are local until you run git push origin <branch>.

A commit describes a complete state of the project. Those states can be compared to one another, which produces a "diff" (git diff origin/master master = see differences between origin/master and master)

Git is pretty powerful when it comes to preparing your commits. The key ingredient here is the "index" (or "staging area"). You can add single changes to the index (using git add) until you think the index looks good. git commit fires up your text editor and you need to provide a commit message (why and how did you make that change); after entering your commit message git will create a new commit – containing the contents of the index – on top of the previous commit (the parent pointer is the SHA1 of the previous commit).

---

Git comes with documentation for exactly what you are looking for.

$ git help glossary

---

I found this (free) book very useful when learning how to use git: http://progit.org/. The book exists in printed form as well.

I think the quickest way to learn git is probably to pick up a book or tutorial which teaches you the basic concepts and terms.

---

Another good resource for learning Git is Edgecase's Git Immersion. Trying to learn Git through the man pages is probably very difficult, there is a short, steep learning curve that has to be overcome first. You need to be introduced to the concept of a DCVS (Distributed Version Control System) first.

Progit as recommended by @fulhack is also very good.

I can also strongly recommend Think Like A Git. The explanation of rebase here is worth its weight in gold.

---

The best I have found for understanding git is The Git Parable

Imagine that you have a computer that has nothing on it but a text editor and a few file system commands. Now imagine that you have decided to write a large software program on this system. Because you’re a responsible software developer, you decide that you need to invent some sort of method for keeping track of versions of your software so that you can retrieve code that you previously changed or deleted. What follows is a story about how you might design one such version control system (VCS) and the reasoning behind those design choices...

---

I think you might like this article: Git for Computer Scientists

And another important aspect to understand when using git is the workflow. Read this wonderful blog post: Git branching model

ReferenceURL : https://stackoverflow.com/questions/7076164/terminology-used-by-git