저는 SVN의 사용자이며 이제 Git을 배우고 있습니다.

SVN에서는 일반적으로 로컬 컴퓨터에서 프로젝트의 모든 분기를 포함하는 리포지토리를 체크 아웃하고 관심이 있고 거기에서 작업하는 내 분기의 폴더를 선택했습니다.

Git을 사용하면 차이점이 있습니다.

현재 repo를 복제하고 gitk를 사용하여 특정 분기를 복제하고 있습니다.

프로젝트 폴더에는 해당 브랜치의 내용 만 포함되어 있으며 SVN에서와 같이 모든 브랜치를 볼 수 없으므로 약간 혼란 스럽습니다.

Git을 사용하여 로컬 저장소의 모든 지점을 쉽게 볼 수있는 방법을 찾을 수 없습니다.

• 내가 설명 한 Git 프로세스가 "표준"인지, 어떤 것이 얼마나 정확하거나 누락되었는지 알고 싶습니다.

• 또한 두 분기에서 동시에 작업 해야하는 프로세스를 처리하는 방법을 알고 싶습니다. 예를 들어 마스터에 핫픽스를 만들어야하지만 다른 분기의 내용도 유지해야합니다.

• Git의 저장소에서 복제 된 분기를 포함하는 폴더를 만드는 권장 이름 규칙은 무엇입니까 myproject-branchname?

저는 SVN의 사용자이며 GIT를 배우고 있습니다.

갱에 오신 것을 환영합니다!

SVN 재교육

SVN에서 나는 보통 [...]

잠시만 기다려주세요. CVS 및 SVN 및 기타 기존 (예 : 중앙 집중식) 버전 제어 시스템은 수은 및 Git과 같은 최신 (즉, 분산) 버전 제어 시스템과 동일한 목적을 달성하지만 (대부분) Git을 처음부터 배우는 것이 훨씬 낫습니다. SVN 워크 플로우를 Git으로 전송하려고합니다.

Joel Spolsky (Stack Exchange의 창립자 중 하나)의 http://hginit.com ( 아카이브에서보기 )은 Git이 아닌 수은을위한 튜토리얼이지만 "Subversion Re-education" 은 0 번째 장 입니다. 에 SVN에서 멀리 전환 사람들에게 유용 어떤 당신이 (일시적으로)에 무슨 SVN 개념을 설명으로, 분산 버전 관리 시스템 유엔 (또는 -learn stash떨어져 머리 분산 주위에 수 랩으로 망할 놈의 사용자가 말할 수로) 버전 제어 시스템 개념과 함께 작동하도록 설정된 관용적 워크 플로우.

따라서 당신은 제로 챕터를 읽고 대부분 "mercurial"이라는 단어를 "Git"으로 바꾸어 Git을위한 자신과 마음을 적절하게 준비 할 수 있습니다.

작은 글씨

(이제이를 건너 뛸 수 있습니다.) 수은 및 힘내 훨씬 더 유사한 SVN보다 서로에 있지만, 거기에 있는 그들 사이에 약간의 개념 차이는 "Subversion을 다시 교육"의 진술과 조언 중 일부는 기술적으로 잘못 될 수 있도록 "수은"을 "Git"으로 교체 할 때 :

• 수은은 내부적으로 변경 세트를 추적하고 저장하지만, Git은 Subversion과 마찬가지로 개정 (즉, 디렉토리 트리의 내용 상태)을 내부적으로 추적하고 저장합니다. 그러나 Subversion Git 이외의 각 관련 브랜치와 공통 조상 개정 (실제 3 포인트 병합)의 차이점을보고 병합을 수행하므로 결과는 수은과 거의 동일합니다. 병합이 훨씬 쉽고 오류가 적습니다. SVN보다 발생하기 쉽습니다.
• 저장소를 복제하여 Git에서 분기 할 수 있지만 (수은의 관례대로) Git 저장소 내에 새 분기를 작성하는 것이 훨씬 일반적입니다. (Git 브랜치는 단순히 개정판에 대한 포인터를 이동시키는 반면 수은 브랜치는 모든 개정판에 적용되는 영구 레이블입니다.이 영구 레이블은 일반적으로 원치 않기 때문에 개발을 분기하기 위해 전체 저장소를 복제하여 수은 워크 플로가 작동합니다.)

SVN에서 모든 것은 디렉토리입니다 (그러나 반드시 그렇게 취급해서는 안됩니다)

하지만 난 당신을 방해했습니다. 너가 말 했잖아?

SVN에서는 일반적으로 로컬 컴퓨터에서 프로젝트의 모든 분기를 포함하는 리포지토리를 체크 아웃하고 관심이 있고 거기에서 작업하는 내 분기의 폴더를 선택했습니다.

즉, SVN 저장소의 루트 폴더 (또는 trunk하나 이상의 분기에 해당하는 다른 폴더 , 예를 들어 기존 SVN 저장소 레이아웃에서 branches모든 비 트렁크 분기를 포함 하는 폴더)를 체크 아웃 한 경우 SVN을 잘못 사용했거나, 트렁크, 브랜치 및 태그가 모두 수정본 / 코드베이스 내의 디렉토리와 함께 단일 (계층 적이지만) 네임 스페이스로 접힌다는 사실을 적어도 남용했다고 말합니다 .

여러 SVN 분기를 병렬로 변경하려는 유혹이있을 수 있지만 SVN을 사용하려는 방식이 아닌 AFAIK입니다. (그렇지만 특정 단점이 어떻게 작동하는지 확실하지 않습니다.)

Git에서는 디렉토리 만 디렉토리입니다

Git 리포지토리의 모든 복제본은 자체적으로 Git 리포지토리입니다. 기본적으로 모든 리비전, 분기 및 태그를 포함하여 원본 리포지토리 기록의 전체 복사본을 가져옵니다. 그러나 Git은 저장소의 루트 폴더에 숨겨진 .git/하위 폴더에있는 일종의 파일 기반 데이터베이스에 파일을 저장합니다 .

그러나 저장소 폴더에 숨겨지지 않은 파일은 무엇입니까?

때 git clone저장소가 힘내는 몇 가지 작업을 수행합니다. 대충:

1. 대상 폴더.git/ 와 "데이터베이스"가 있는 하위 폴더를 만듭니다.
2. 원본 리포지토리 데이터베이스 의 참조 (태그, 브랜치 등)를 전송하고 새 데이터베이스에 사본을 만들어 "원격"참조로 표시하는 약간 수정 된 이름을 지정합니다.
3. 이 참조가 가리키는 모든 개정 (즉, 파일 트리 상태)과이 개정이 가리키는 모든 개정 (직접 부모 및 조상)을 새 데이터베이스로 전송하고 저장하여 새 원격 참조가 실제로 새 저장소에서 사용 가능한 것을 가리 킵니다.
4. 원본 리포지토리의 기본 분기 (일반적으로 master)에 해당하는 원격 개정을 추적하는 로컬 분기를 만듭니다 .
5. 해당 지역 지점을 체크 아웃합니다.

마지막 단계는 Git이이 브랜치가 가리키는 개정판을 찾고 거기에 저장된 파일 트리 (데이터베이스가 압축 및 중복 제거를 사용하는 일부)를 저장소의 루트 폴더에 압축 해제한다는 것을 의미합니다. 루트 폴더와 모든 하위 폴더 (특수 .git하위 폴더 제외 )를 리포지토리의 "작업 복사본"이라고합니다. 이곳에서 현재 체크 아웃 된 개정 / 분기의 내용과 상호 작용할 수 있습니다. 그들은 단지 일반적인 폴더와 파일입니다. 그러나 리포지토리 별 저장소 (개정 및 참조의 "데이터베이스")와 상호 작용하려면 git명령 을 사용 합니다.

Git 브랜치를보고 Git 브랜치와 상호 작용

현재 repo를 복제하고 gitk를 사용하여 특정 분기를 복제하고 있습니다.

gitk내가 가진 버전은 저장소를 복제 할 수 없습니다. 리포지토리 내역 만보고 분기를 만들고 분기를 체크 아웃 할 수 있습니다. 또한 분기를 "복제"하지 않습니다. 리포지토리 만 복제 할 수 있습니다.

당신은 당신이 사용 REPO를 복제하셨습니까 git clone ...사용하여 다음과 gitk, 체크 아웃 지점을?

프로젝트 폴더에는 해당 브랜치의 내용 만 포함되어 있으며 SVN에서와 같이 모든 브랜치를 볼 수 없으므로 약간 혼란 스럽습니다.

[...]

• 내가 설명하는 자식 프로세스가 "표준"인지 그리고 얼마나 정확한지 알고 싶다 ...]

예, 그것은 꽤 표준입니다.

• 다음을 사용하여 리포지토리 복제 git clone ...
• 작업하려는 지점을 확인 git checkout ...하거나 다음과 같은 그래픽 도구를 사용하십시오.gikt

GIT를 사용하여 로컬 저장소의 모든 분기를 쉽게 볼 수있는 방법을 찾을 수 없습니다.

• [...] 또는 smt가 없습니다.

아마도:

• 당신은 지역 지점을 나열 할 수 있습니다 git branch
• 당신은 함께 git branch -r또는 모든 지점으로 원격 지점을 나열 할 수 있습니다git branch -a

• 당신이 사용할 수있는 gitk그것을 호출하여 (모든 지점 태그 등 지역의 repo가 알고있는)을 전체 역사를 볼 수 있습니다

  gitk --all
  

여러 분기를 병렬로 작업하는 방법

• 또한 두 분기에서 동시에 작업 해야하는 프로세스를 처리하는 방법을 알고 싶습니다. 예를 들어 마스터에 핫픽스를 만들어야하지만 다른 분기의 내용도 유지해야합니다.

여기에는 다른 시나리오가 있습니다.

새로운 (아직 만들려는) 변경 사항을 여러 분기에 적용해야합니다.

이 워크 플로우를 사용하십시오.

1. c이 모든 분기의 조상에 이미있는 개정 (예 : 변경이 버그 수정이 될 때 버그를 도입 한 개정) 또는 (모든 조상을 포함하여) 도입 가능한 개정에서 새 분기 를 작성하십시오. 이 모든 가지들.
2. 새 지점에서 변경하고 커밋하십시오 c.

3. b변경이 필요한 각 지점에 대해 :

   1. 체크 아웃 b:

      git checkout b
      

   2. 병합 c에 b:

      git merge c
      

4. 분기 제거 c:

   git branch --delete c
   

다른 지점에서 기존 변경이 필요합니다.

(...하지만 변경 사항이있는 위치에서 다른 변경 사항이없는 경우)

1. 변경이 필요한 지점을 확인하십시오
2. 체리 - 선택 순서에 개정 (들)을 변경하기를

한 지점 a에서 하나 또는 일부 파일을 다른 지점에있는 정확한 상태로 변경하려고합니다.b

1. 체크 아웃 a

2. 분기에서 파일 내용을 가져옵니다 b.

   git checkout b -- path/to/a/file.txt path/to/another/file.cpp or/even/a/complete/directory/ ...
   

   ( git checkout경로를 전달 하지 않는 한 분기로 전환 되지 않고b 요청 된 파일 내용 만 가져옵니다.이 파일은 이미 존재하거나 존재하지 않을 수 있습니다. 파일이 존재하는 a경우 파일의 내용으로 덮어 씁니다 b.)

한 지점에서 작업하는 동안 다른 지점에서 상황이 어떤지 살펴보고 싶습니다.

작업하려는 지점을 확인하십시오.

그런 다음 다른 지점을보고

• 현재 체크 아웃되지 않은 개정판의 내용을 볼 수있는 그래픽 도구를 사용하십시오 (예 : gitk라디오 버튼을 "패치"에서 "트리"로 전환)
• 또는 저장소를 임시 디렉토리에 복제하고 그곳의 다른 지점을 확인하십시오.
• 또는 다른 저장소 를 체크 아웃 할 수 있는 동일한 저장소 (예 : 현재 로컬 저장소 디렉토리의 데이터베이스 git worktree를 사용)의 별도 작업 디렉토리를 작성하는 데 사용.git/

SVN에서는 일반적으로 로컬 컴퓨터에서 프로젝트의 모든 분기를 포함하는 리포지토리를 체크 아웃하고 관심이 있고 거기에서 작업하는 내 분기의 폴더를 선택했습니다.

트렁크 위의 디렉토리를 체크 아웃하지 않으면 Subversion에서 일반적으로 모든 브랜치를 로컬에서 사용할 수있는 것은 아닙니다 . Git에서 모든 컨텐츠 (커밋, 메시지, 브랜치 등)는 항상 모든 사본에 복제됩니다.

현재 repo를 복제하고 gitk를 사용하여 특정 분기를 복제하고 있습니다.

불가능합니다. 위를 참조하십시오. 할 수 git checkout branch-name는 있지만 할 수는 없습니다 git clone something branch-name. Subversion에서 브랜치는 폴더입니다. Git에서 브랜치는 커밋에 대한 포인터입니다.

GIT를 사용하여 로컬 저장소의 모든 분기를 쉽게 볼 수있는 방법을 찾을 수 없습니다.

를 실행하십시오 git branch. 기본적으로 로컬 브랜치 만 표시됩니다. git branch --remote원격 지점을 보는 데 사용 합니다.

이것은 git 태그가 붙어 있기 때문에 SVN 지식이 부족하다는 것을 무시할 수 있기를 바랍니다.

현재 repo를 복제하고 gitk를 사용하여 특정 분기를 복제하고 있습니다.

특정 지점뿐만 아니라 전체 원격 저장소를 복제하고 있습니다.

저장소는 데이터베이스로 가장 잘 상상되므로 원격 데이터베이스의 현재 상태를 복제하고 있습니다. 그러나 그 후에는 자신의 데이터베이스 사본에서 작업하고 있습니다. 커밋하면 로컬 데이터베이스가 변경됩니다.

이 fetch명령은 로컬 데이터베이스를 원격 데이터베이스와 동기화 상태로 유지하는 데 사용됩니다.

일반적으로 해당 로컬 데이터베이스에서 작업 할 분기를 체크 아웃합니다. 이것은 현재 작업이 시작된 git의 내부 마커와 다릅니다.

을 제외한 분기가없는 간단한 리포지토리에서 작업중인 경우 "매직"을 공개하기 위해 폴더를 master살펴볼 수 있습니다 .git.

마지막 커밋 ( master)이 있다고 가정 182e8220b404437b9e43eb78149d31af79040c66하면 아래에서 정확히 찾을 수 cat .git/refs/heads/master있습니다.

그로부터 당신은 새로운 지점 git checkout -b mybranch에서 분기 , 당신은 파일에서 정확히 같은 포인터를 찾을 수 있습니다 cat .git/refs/heads/mybranch.

지점은 "포인터"에 지나지 않습니다. "작업 중"마커를이라고합니다 HEAD.

당신이 어디에 있는지 알고 싶다면 HEAD:

cat .git/HEAD이는 예를 들어 말한다 ref: refs/heads/mybranch, 턴 포인트 (이 cat .git/refs/heads/mybranch해시를 커밋)를에78a8a6eb6f82eae21b156b68d553dd143c6d3e6f

실제 커밋은 objects폴더 아래에 저장됩니다 (자체 주제는 어떻습니까).

프로젝트 폴더에는 해당 브랜치의 내용 만 포함되어 있으며 SVN에서와 같이 모든 브랜치를 볼 수 없으므로 약간 혼란 스럽습니다.

working directory전체를 "git-database"와 혼동하지 마십시오 . 위에서 말했듯이 작업 디렉토리는 하위 집합의 스냅 샷 일뿐입니다.

다른 브랜치가 있다고 가정하면 작업 디렉토리는 해당 브랜치에서만 작업하는 데 전념합니다 (다른 곳에서 작업을 할 수는 있음).

일반적으로 프로젝트에 어떤 분기가 정의되어 있는지 확인하려면 다음과 같은 가능성이 있습니다.

• git branch 현지 지점
• git branch --remote 원격 지점
• git branch -a 모두

(또는 git branch -v)

git은 분산 버전 제어 시스템이므로 다른 브랜치를 로컬 / 원격으로 만드는 것이 가능하지만 권장됩니다.

내 일반적인 작업 과정은 다음과 같습니다

• 기능 분기 해제
• 해당 지점에서 WIP (작업 진행 중) 지점
• 단 한 줄만 커밋하더라도 원하는대로 작동합니다. 상관 없어

기능이 완료되면 :

• WIP지점을 스쿼시 / 재 작업 (대화식 rebasing 사용) = 그로부터 단일 커밋 만들기
• WIP브랜치를 피처 브랜치로 병합하고 안정적인 (마스터) 브랜치에 통합 할 수 있도록 제공합니다 (github에서 작업하는 경우 "풀 요청"이라고 함).

또한 두 분기에서 동시에 wprl 해야하는 프로세스를 처리하는 방법을 알고 싶습니다. 예를 들어, 마스터에 핫픽스를 만들어야하지만 다른 분기의 내용도 유지해야합니다.

프로젝트 구성 방식에 따라 다릅니다.

안정적인 주인이 있다고 가정 해보십시오. 그리고 기능은 안정적인 지점에서만 개발되므로 일반적으로 기능 지점 뒤에 있습니다. 그런 다음 기능 분기의 루트가 될 마스터에 대한 마지막 커밋이 있습니다.

그런 다음 마스터 브랜치를 커밋하고 두 브랜치를 함께 병합 할지 아니면 리베이스 (고급 요구 사항이있는 사용자에게는 일종의 병합)로 결정할 수 있습니다.

또는 항상 분기 (예 master:)를 변경 하고 다른 분기로 체리 픽을 선택할 수 있습니다.

GIT의 저장소에서 복제 된 분기를 포함하는 폴더를 만드는 권장 이름 규칙은 무엇입니까? 예 : myproject-branchname

너하기에 달렸다.

일반적으로 리포지토리 이름으로 끝납니다.

그러나 이것이 바람직하지 않은 경우가 있습니다.

예를 들어, 당신은 오 - 내 - zsh을 가진 복제 git clone git://github.com/robbyrussell/oh-my-zsh.git ~/.oh-my-zsh 여기가 .oh-my-zsh명시 적으로 대상으로 지정됩니다.

Git clone 실제로 전체 저장소를 복제하지만 작업 디렉토리를 기본값 (보통 마스터)으로 설정합니다.

다른 분기를 사용 git branch하여 로컬 분기 git branch -r를 보거나 원격 분기 를보고 git checkout기존 분기로 전환하거나 현재 분기를 기반으로 새 분기를 만들 수 있습니다.

자세한 내용은 git 문서를 읽어야하며 Atlassian에도 좋은 기사가 있습니다.

git과 svn의 브랜치는 근본적으로 다릅니다.

svn에서 브랜치 (또는 태그)는 repo의 디렉토리입니다.

자식에서 분기 (또는 태그)는 커밋에 대한 포인터입니다.

svn을 사용하면 저장소의 루트를 체크 아웃 할 수 있습니다. 이것은 모든 지점과 태그를 한 번에 체크 아웃했음을 의미합니다. svn을 사용하는 일반적인 방법은 아닙니다.

git 브랜치는 디렉토리가 아니므로 "리포지토리의 루트를 체크 아웃"할 필요가 없습니다. 여러 개의 작동하는 트리가 지원되므로 스크립트를 함께 묶어 모든 분기를 동시에 체크 아웃 할 수 있다고 생각하지만 실제로는 그렇지 않습니다.

또한 SVN에는 정확히 하나의 저장소가 있습니다. 자식으로 모든 개발자는 자신의 저장소를 가지고 있습니다. 이는 개발자가 오프라인에서 작업 할 수 있음을 의미하지만 개발자마다 각 브랜치에 대해 다른 아이디어를 가질 수 있음을 의미합니다.

디렉토리라는 장점과 svn의 간단한 선형 이력 모델 덕분에 svn 브랜치는 강력한 역사를 가지고 있습니다. 날짜 y의 x 지점에 무엇이 있는지 알고 싶다면 쉽게 질문 할 수 있습니다.

반면에 Git 브랜치는 실제로 역사가 없습니다. "reflog"가 있지만 장기 이력보다는 재난 복구 메커니즘으로 사용됩니다. 특히, reflog를 원격으로 읽을 수 없으며 기본 리포지토리에 대해 기본적으로 비활성화되어 있습니다.

커밋은 물론 역사가 있지만 그 역사는 "날짜 z의 저장소 x에 무엇이 있었는지"라는 질문에 대답하기에는 충분하지 않습니다.

Git을 사용하여 로컬 저장소의 모든 지점을 쉽게 볼 수있는 방법을 찾을 수 없습니다.

"git branch"를 입력하여 모든 로컬 브랜치를 나열 할 수 있습니다.

"git branch -a"를 사용하여 로컬과 원격 모두의 모든 브랜치를 나열 할 수 있습니다.

또한 두 분기에서 동시에 작업 해야하는 프로세스를 처리하는 방법을 알고 싶습니다. 예를 들어 마스터에 핫픽스를 만들어야하지만 다른 분기의 내용도 유지해야합니다.

몇 가지 옵션.

"기타 지점"에서 변경 사항을 커밋하고 마스터로 전환 한 후 작업을 수행 한 다음 다시 전환 할 수 있습니다.

추가 작업 트리를 만들 수도 있습니다. 구문에 대한 자세한 내용은 Google "git-worktree"입니다.

Git의 저장소에서 복제 된 분기를 포함하는 폴더를 만드는 권장 이름 규칙은 무엇입니까 (예 : myproject-branchname)?

나는 확립 된 협약이 없다고 생각합니다. 여러 작업 트리를 한 번에 체크 아웃하는 것은 예외가 아닙니다.