모두가 마스터 작업을 할 때 git pain을 최소화하려면 어떻게해야합니까?


123

최근 약 10 명으로 구성된 문서 팀이 SVN에서 Git으로 이동했습니다. SVN에서는 모두가 항상 싫어하는 모델 인 마스터 작업을 수행했지만 그 변화를 가져올 수 없었습니다. Git으로의 이동의 일환으로 우리는 그것을 고치기로 동의했지만 아직 할 수는 없습니다 (임의의 지점에서 빌드 할 수있는 빌드 변경을 기다리는 중). 한편 모두는 마스터 작업을하고 있습니다. 예, 이것이 끔찍하다는 것을 알고 있습니다.

우리는 SVN을 사용할 때보 다 지금 훨씬 더 많은 딸꾹질을 겪고 있습니다. 일부는 Git의 2 단계 모델 (로컬 및 원격)로 인해 발생합니다. 때때로 사람들은 커밋하지만 푸시하지 못하거나 보류중인 로컬 변경 사항을 가져와 충돌합니다. 어제 누군가 합병이 잘못되어 최근의 변경 사항을 어지럽 혔습니다. (그는 자신이 한 일을 정확하게 말할 수 없었으며 GUI를 사용하고 있기 때문에 쉘 기록을 검사 할 수는 없습니다.)

가장 능숙한 Git 사용자로서 (읽기 : 복잡하지는 않지만 이전에 사용해 본 적이 있음) 저는 정책을 설정하고 도구를 가르치며 혼란을 없애는 사람입니다. 지점에서 개발을 수행 할 때까지 도구를 사용하여 오류가 발생하기 쉬운 공유 마스터를 만드는 방법을 어떻게 변경할 수 있습니까?

팀은 Windows에서 Tortoise Git을 사용하고 있습니다. 우리는 전에 Tortoise SVN을 사용했기 때문에 Tortoise Git을 사용하고 있습니다. ( 저는 개인적으로 Cygwin에서 명령 행을 사용하여 일부 조작을 수행했지만 팀은 GUI가 필요하다는 사실을 확인했으며이 도구를 사용할 것입니다.)이 도구를 사용하여 교체 작업을 제안하지 말고 답변해야합니다.

Tortoise Git은 단일 작업으로 "Commit & Push"를 사용할 수 있으며 항상 그렇게하도록 지시했습니다. 그러나 그것은 원자 적이 지 않습니다-커밋 (결국 로컬)은 제대로 작동하지만 푸시는 작동하지 않습니다 (예 : 충돌 또는 네트워크 문제로 인해). 그렇게되면 모호한 오류가 발생합니다. 나는 그들이있는 경우의 bitbucket 로그를 저지 확인하기 위해 그들에게 한 어떤 그들이 밀어, 표시되지 않는 경우, 커밋 최근에 의문을합니다. (문제가있는 경우 충돌을 해결하거나 그들이 무엇을 해야할지 모르는 경우 도움을 요청하십시오.)

팀은 이미 "빠르고 자주 당기는"습관이 있습니다. 그러나 당기면 충돌이 발생할 수 있습니다. 새로운 것이 아니라면 SVN보다 훨씬 더 자주 발생합니다. 나는 Git이 어떻게 가져 오는지 (병합 대신 rebase)를 변경할 수 있다고 들었지만, 거기에서 타협점 (또는 우리 환경에서 수행하는 방법)을 잘 이해하지 못합니다.

서버는 BitBucket (Github 아님)입니다. 리포지토리에 대한 모든 관리 권한이 있지만 더 일반적으로 서버에는 없습니다. 그 중 어느 것도 바꿀 수 없습니다.

소스 파일은 XML입니다. 병합 할 수없는 모든 사람이 알고있는 그래픽 파일도 있지만 충돌이 거의 없습니다. 병합 충돌은 그래픽이 아닌 XML 파일에서 발생합니다.

검토되고 테스트가 완료된 풀 요청이있는 기능 분기를 사용할 수있을 때까지 Git을 사용하여 팀을보다 원활하게 공유 할 수 있도록하기 위해 어떤 변경을 할 수 있습니까?


52
거북이를 사용하지 말고 Git Extensions를 사용하십시오. 거북이는 Git이 SVN이 아니라는 것을 숨기려고 시도하고 대부분의 git greatness를 파괴합니다. 나는 SVN-> Git 전환을 두 번 겪었고 Git Extension은 사람들이 git way를 생각하게하는 훌륭한 도구였습니다.
Wilbert

91
힘내는 SVN이 아닙니다. Git을 사용하여 SVN을 복제하려고하면 SVN의 모든 고통 지점을 Git의 모든 고통 지점과 결합하면 아무런 이점도 얻지 못합니다. 절대로 작동하지 않을 것입니다. 가장 큰 문제는 사회적 문제이며, 새로운 개념을 배우기를 거부하는 팀원이 있습니다. 기술적 솔루션으로는이를 해결할 수 없으며, 팀원들로부터 구매를 통해 Git 개념을 배우는 것이 SVN과 같다는 것을 확신시키는 것보다 먼저 시작해야합니다.
Lie Ryan

10
다른 앱을 권장하지 않는다고 말했지만 @Wilbert가 적합합니다. TortoiseGit은 사물을 숨기려고하는데 실제로 내 경험에서 더 고통 스럽습니다. UI가 필요한 경우 가장 쉬운 전환 (읽기 : 툴링 및 DevOps에서 비 전통적인 소프트웨어 팀 교육)이 Atlassian의 SourceTree를 통해 이루어 졌다는 것을 알았습니다 (물론 적절한 교육). 또한 GitFlow를 사용하여 Git 모델을 이해하는 데 도움을주었습니다 (그러나 모든 팀에 적합한 것은 아닙니다).
JasCav

28
모든 사람들이 Continuous Integration 의 중심 교리 인 마스터에 대해 똥을 내고 있다는 사실에 놀랐습니다 . 강력한 테스트 스위트가 있고 빌드가 중단 될 때 모든 사람이 알고있는 한 마스터 작업은 팀 협업에 유리할 수 있습니다. 보호 기능을 갖추지 않고도 기능 분기 (다른 모든 워크 플로가 어느 정도 의존 함)는 똑같이 파괴적 일 수 있습니다. 아마도 여기에 더 깊은 뿌리 문제가있을 것입니다.
DanK

14
@ DanK, 나는 또한 op가 문제의 근원을 잘못 식별했다고 생각합니다. 마스터에서 사람들이 클로버 링 변경 사항을 가지고 있고 브랜치로 전환하면 브랜치에서 사람들이 클로버 링 변경 사항을 갖게됩니다. 개별 지점으로 이동하면 지점에서 병합하는 데 문제가 있거나 수개월 동안 병합하지 않고 지점에서 발전하는 사람들이 있습니다.
user3067860

답변:


11

지금까지 SourceTree는 각 단계에서 사용하는 모든 관련 대화 상자와 옵션을 표시하기 때문에 개념을 배우는 데 가장 적합한 IDE였습니다. 기본 옵션은 일반적으로 훌륭하고 rebase와 혼동하지 마십시오. 정상적인 흐름을 따르십시오.

  • 당신이 최신 상태인지 확인하기 위해 마스터에서 당겨
  • 파일 수정
  • 변경 사항을 커밋합니다 (로컬에만 해당).
  • 마스터에서 다시 당기면 충돌이 발생합니다.
  • 충돌이 해결 될 때까지 모든 파일을 편집하십시오. 이는 파일이 커밋하려는 적절한 상태에 있음을 의미합니다 (원시 파일에 <<<<< HEAD 및 >>>> 마스터 메시지 없음)
  • 병합 변경 사항 커밋
  • 푸시

모든 사람이이 레시피를 따르면 괜찮을 것입니다.

누군가가 더 크거나 중앙에서 변경을 수행 할 때마다 다른 사용자에게 로컬로 커밋하고 마스터에서 가져 오도록 알리면 나중에 너무 많은 충돌이 발생하지 않으며 첫 번째 사람이 여전히 그들과 함께 충돌을 해결하려고합니다.

모든 사람이 흐름을 이해하도록 많은 시간을 투자하십시오. 그렇지 않으면 시간이 많이 걸리고 실제로 마스터 브랜치를 조이는 동안 편안하게 느낄 수 있습니다 (예 : "원격 대신 내 파일 사용") 충돌을 해결하십시오. 다른 사람들이 만든 모든 변경 사항을

힘내 시스템을 배우기가 어렵습니다. 특히 Svn과 함께 자랐고 인내심을 가지고 올바르게 배울 수있는 시간을 주면 새로운 사용자와 함께 하루 종일 혼란을 청소할 수 있습니다. 정상입니다. ;)


9
nitpick : SourceTree가 아닌 통합 개발 환경 ...
마티유 Guindon

놀랍게도 / 문제를 해결하기 위해 (나 이외의) 누군가이 워크 플로우를 시험해 본 적이 있습니다. 아무 것도 없다고 가정하면 며칠 안에 팀에 배포 할 계획입니다.
Monica Cellio

이 투표이 투표 와 동일한 영역을 많이 포함 한다는 것을 알고 있지만,이 답변에서 단계별로 배치 된 레시피가 적용 방법을 실제로 이해하는 것을 볼 때까지는 아니 었습니다. 이 것을 받아들이고 있습니다 (IDE가 아닌 레시피 용 :-)). 추가 문제없이 며칠 동안이 과정을 따르고 있습니다. 또한 "git way"를 탐색하고 이해하는 데 더 중점을 둘 것입니다.
Monica Cellio

100

다른 사람과 같은 지점에서 일할 때 기억해야 할 세 가지 주요 사항이 있습니다.

  • 자신이하고있는 일 --force정말로 알지 않는 한 절대 사용 하지 마십시오 .
  • 하나 commit또는 stash모든 전에 진행중인 작업 pull.
  • 당신이 pull바로 앞에 있다면 보통 더 쉬워집니다 push.

그 외에도, 분산 버전 관리를 사용하면 "공식"저장소가 지점을 사용하는지 여부는 중요하지 않습니다. 개별 사용자가 로컬 리포지토리에서 수행하는 작업과는 아무런 관련이 없습니다. 회사에서 완전히 다른 중앙 VCS를 사용할 때 git을 사용하여 로컬 지점을 얻었습니다. 기능에 대한 로컬 브랜치를 만들고 로컬에 실수를 병합 하면 Reflog 또는 다른 마술에 가지 master않고 수정하는 것이 훨씬 쉽습니다 .


51
항상 pull전에는 push훌륭한 조언이지만 한 걸음 더 나아가서 할 수 있는지 여부를 고려할 것을 제안합니다 pull --rebase.
anaximander

20
@anaximander, 나는 모두가 --rebase를 사용하거나 아무도 사용하지 않는 것이 좋습니다 ...
keuleJ

12
@TemporalWolf 그들이 케이크에 대해 나에게 말한 것입니다 ...
BlackVegetable

15
@anaximander "그러면 충돌을 해결하지 못했고 잘못하고 있습니다.이 경우 리베이스로 신뢰할 수 없습니다." 당신은 결코 한번도 말하지 않고, 병합 충돌을 망쳤습니까? 일반화 할 수있는 간단한 코드 기반으로 작업하는 것이 좋습니다. 여기 리누스의 리베이스에 관한 글이 있는데, 저는 개인적으로 그 어떤 흑백 접근법보다 훨씬 더 합리적이라고 생각합니다.
Voo

10
" --force무엇을하고 있는지 정말로 모른다면 사용 하지 마십시오 ." 나는 더 나아갈 것이다. 가장 신뢰할 수있는 개인을 제외한 모든 사람이 "기본"리포지토리에서 기록을 다시 쓸 수 없도록합니다. 이를 수행 할 수 있는지 여부는 적어도 부분적으로 호스팅에 달려 있지만 BitBucket에는 옵션이 있습니다.
jpmc26

68

모두가 자식을 배우는 데 하루가 걸릴 수 있습니까?

전문가를 사용하는 컴퓨터는 실제로 새로운 도구를 배우고 모든 VCS에서 많은 실수를 할 수는 있지만 사용하도록 설계된 도구를 사용해야합니다.

이것을 소개하는 가장 좋은 방법은 모든 사람들이 가능한 한 짧은 시간에 변경을 할 때 자신의 브랜치에서 작업하고 리베이스 한 다음 완료되면 다시 마스터로 병합하는 것입니다. 이것은 현재의 작업 방식에서 그리 멀지 않으며 더 복잡한 작업을 수행 할만큼 자신감이 생길 때까지 익숙해 질 수있는 간단한 워크 플로우를 소개합니다.

나는 창을 사용하지 않지만 Tortoise가 기본적으로 git을 숨기고 SVN 인 척하면 Tortoise가 잘못된 도구 일 수 있습니다.


37
"토르 토이즈가 기본적으로 git을 숨기고 SVN 인 척하는 경우 거북이가 잘못된 도구 일 수 있습니다." 이. OP가 도구를 대체하지 말라고 말했지만 git이 어떻게 작동하는지 모호하게하면 개발자의 개인적 성장과 운영 효율성에 해를 끼칩니다. 팀이 이해하지 못하면 VCS를 계속 오용합니다.
2rs2ts

3
또 다른 유용한 git 학습 리소스는 Learn Git Branching 입니다. 시각적 트리를 표시하고 추가로 샌드 박스가 있으므로 많은 명령을 조롱하고 어떤 종류의 트리 결과를 볼 수 있습니다.
TemporalWolf

4
개발자 팀의 모든 사람들이 git을 배우는 데 하루가 더 오래 걸렸으며 (그리고 그들은 어둡거나 느슨하지 않습니다), 나는 그것이 의사 팀에도 해당한다고 가정했습니다. 나는 여기에 언급 된 사이트를 의견으로 살펴볼 것입니다 (아마도 이것 또는 다른 대답에 있어야합니까?).
Monica Cellio

3
당신은 모든 실수를하고 충돌과 합병의 갈등을 겪을 때까지 자식을 배우지 않을 것입니다. 마스터와 지점을 다시 마스터로 병합합니다. 그들이이 흐름에서 겪는 고통을 해결하려고 할 때 그들이 할 수있는 다른 학습 (일부는있을 것임). 최소한 문서 팀은 코드베이스를 깨뜨릴 염려가 없습니다.
MarkJL

1
@ 2rs2ts Tortoise Git은 뛰어난 git gui입니다. 모든 Windows 상자에 설치하고 git 명령 줄에 매우 익숙합니다. 병합 도구는 내가 사용해 본 것 중 최고입니다. Tortoise Git을 사용하여 git을 사용하는 초보자 초보자를 많이 소개했습니다. 가장 큰 문제는 간단한 확인란으로 일부 고급 git 옵션을 표시한다는 것입니다. 따라서 푸시 GUI에서 확인란을 선택하면 --force push와 같은 옵션을 수행 할 수 있습니다. 이것은 일을 잃어버린 일이 무엇인지 가능성이 높습니다. 나는 거북이를 많이 사용하지 않지만 실제로 간단하게 만드는 몇 가지가 있습니다.
gnash117

26

때때로, 당신이하고있는 일이 바뀌어야합니다.

가장 큰 문제는 모든 사람 마스터 작업을하고 있다는 것 입니다. 이것은 코드 개발에는 일반적이지 않으며 귀하의 경우에는 잘못된 모델 일 수도 있습니다. 변경을 할 수 있다면, 별도의 브랜치에서 변경을 수행하도록 요구 / 요청함으로써 훨씬 나은 모양을 갖게됩니다. 가지를 사용하면 다음을 얻을 수 있습니다.

  • 직접 푸시를 master허용 하지 않도록합니다.
  • 풀 요청을 작성하고 병합하기 전에 하나 이상의 승인을 받도록 Bitbucket을 통해 시행하십시오 . 이렇게하면 UI가 사용자가 데스크탑에있는 것이 아니라 원격 버전의 코드와 충돌을 표시하므로 누군가가 변경 사항을보고 있는지 확인하고 병합 자체를 덜 고통스럽게 만듭니다. 이것은 커밋 성공하지만 푸시 실패 시나리오를 방지합니다.
  • 병합하기 전에 리포지토리에 대해 "빌드"를 실행하십시오. 나는 문서 저장소라는 것을 알고 있지만이 빌드에서 빌드 할 수있는 철자 검사, 합법적 스크랩 또는 자동화 된 번역 (STRING_DEF 항목을 CSV 파일로 내보내기)이있을 수 있습니다. 아니면 아닐 수도 있습니다.
  • 사람들이 여러 가지 다른 일을 동시에 쉽게 수행 할 수 있습니다. 예, 이것은 숨김으로도 가능하지만 조금 지저분하고 무언가를 사용하지 않는다고 알려줍니다.

분기를 사용할 수없는 경우 merge-and-push일부 문제를 자동화 할 수 있는 스크립트 작성을 고려할 수 있습니다. 어쩌면 사용자가 마스터 뒤에 있지 않은지 확인하고 가져 오기 및 가져 오기를 수행 한 다음 병합을 시도합니다 ( 가능하면--no-commit --no-ff ).


3
우리는 당신이 언급 한 모든 이유로 분기로 이동 할 것입니다 (그러나 가장 특히, 통제 된 PR 및 병합 전에 지점에서 충돌을 해결할 수있는 능력). 병합 및 푸시 스크립트를 공격하는 방법에 대해 더 말씀해 주시겠습니까?
Monica Cellio

6
이 조언에 동의하지 않습니다. 장기 실행 피처 브랜치는 마스터에서 작업하는 것보다 훨씬 더 치명적일 수 있습니다 (좋은 워크 플로가없는 경우 발생하는 상황). Martin Fowler는 이 주제에 관한 훌륭한 기사 를 가지고 있습니다. 그 다음 날 OPs 팀은 Git 문제가 아닌 워크 플로 협업 문제를 겪고 있습니다. 더 많은 지점에서이 문제를 복잡하게 만들 것이라고 주장합니다.
DanK

6
장기 실행 기능 분기는 내가 옹호했던 것이 아닙니다. 나는 그들이 "정규적인"개발에 나쁘다는 점에 동의한다. 병합하기 전에 검토 / 테스트 할 수있는 작은 변경 세트가있는 일반 "라비올리"브랜치는 매우 유용하며, 답변에 요약 된 모든 이유로 문서 저장소이기 때문에 여기서는 그다지 유용하지 않습니다.
Dan1701

3
물론, 나는 당신이 말하는 내가 동의하지 않는 이해 이론적으로 도 좋은 의도지만, 현재 여기에 설명되는 협업 문제, 나는 OP 팀의 지점이 모든 실수로 생각 변신 장기 실행 분기합니다. 하루가 끝나면 메인 라인과 기능 분기에 대한 작업은 여기서 근본적인 문제가 아닙니다. 문제는 분산 VCS의 입 / 출력에 대한 일반적인 이해 부족과 개발자 간의 협업 / 통합 부족입니다. 기능 분기 자체로는 문제를 해결할 수 없지만 IMO가이를 악화시킵니다.
DanK

2
채팅으로 이동해야 할 필요성에 가까워지고 있지만 항상 기능 지점에 있으면 작업을 마치지 않습니다. 배송 지점으로 병합 (또는이 경우 게시)해야합니다. 이를 통해 팀이 겪고있는 문제에 대한 자동 점검 및 보호 조치를 도입 할 수 있습니다. 기능 브랜치는 대부분의 툴 (적어도 Bitbucket)이 필요한 승인과 풀 요청을 브랜칭 모델의 일부로 끌어 오기 요청을 허용하도록 설정되어 있다는 점에서 마스터 작업과는 완전히 다릅니다. master.
Dan1701

12

병합을 다시 실행할 수 있음을 강조

그것은 당신에게는 명백 할 수도 있지만 이전 SVN 사용자는 병합을 여러 번 해결하려고 시도 할 수 있다는 것을 알지 못할 수 있습니다. 이렇게하면 수신 한 도움말 플래그 수가 줄어들 수 있습니다.

SVN에서 작업 할 때 trunk커밋되지 않은 변경 사항이 있습니다. 그럼 당신은 할 것 svn update입니다. 이때 변경 사항이 다른 사람의 변경 사항과 영원히 혼합됩니다. 그것을 취소 할 수있는 방법이 없었으므로 (afaik) 수동으로 모든 것을 확인하고 레포가 좋은 상태에 있기를 바랍니다. 실제로 병합을 다시 실행하면 훨씬 더 편할 것입니다.

우리가 자식으로 옮길 때에도 사람들은 같은 사고 방식을 가질 것입니다. 의도하지 않은 오류가 많이 발생합니다.

운 좋게도 git에는 로컬 커밋을 할 수 있기 때문에 되돌아 갈 수있는 방법이 있습니다. (이것이 커맨드 라인에서 어떻게 표현되는지에 대해서는 나중에 설명합니다)

이 작업을 수행하는 방법은 툴링에 따라 다릅니다. 풀을 다시 실행하는 것은 많은 GUI에서 단일 버튼으로 노출되는 것이 아니지만 가능할 수 있습니다. 나는 당신이 cygwin을 사용하는 것을 좋아합니다. 동료들이 소스 트리를 사용합니다. BitBucket을 사용하기 때문에 같은 회사 : Atlassian에서 관리하기 때문에 GUI로 사용하는 것이 좋습니다. 더 긴밀한 통합이 있다고 생각합니다.

당김에 대하여

합병 pull이 사람들을 혼란스럽게 만드는 것이 옳다고 생각합니다 . A pull는 실제로 git fetch서버에서 변경 사항을 검색 한 다음 git merge origin/<branchname>원격 변경 내용을 로컬 지점에 병합하는 *입니다. ( https://git-scm.com/docs/git-pull )

결론은 모든 표준 병합 명령이 pull과 함께 작동한다는 것입니다. 해당 병합에 충돌이 있으면에 의해 중단 할 수 있습니다 git merge --abort. 병합하기 전에 다시 가져와야합니다. 그런 다음 git pull또는로 다시 시도 할 수 있습니다 git merge origin/<branchname>.

동료의 GUI 도구를 사용하여 위의 작업을 수행하는 방법을 어떻게 든 배울 수 있다면 대부분의 문제를 해결할 것이라고 생각합니다. 더 구체적으로 말씀 드릴 수 없습니다.

* 나는 여기서 원산지가 항상 그런 것은 아니라는 것을 이해합니다.

git reflog문제 진단에 사용

나는 당신과 마찬가지로 GUI 도구를 잘못 사용하여 생성 된 문제를 진단해야합니다. 나는 그것이 git reflog저장소에서 상당히 일관된 조치의 흔적이기 때문에 때로는 도움 이 될 수 있음을 발견했다 . 때때로 읽기는 어렵지만.

대안

일시적인 상황이므로 프로세스를 롤아웃 할 때까지 SVN으로 돌아갈 수 있습니다. 많은 곳에서 '우리는 한 번 git을 시도했지만 작동하지 않았습니다 ...'라고 말하고 실제로 다시 가져 가지 않으므로 주저하지 않았습니다.

다른 일반적인 과도기 문제

  • 사람들은 종종 자신의 저장소를 삭제하고 복제하여 자신의 저장소가 사용할 수없는 상태라고 확신했습니다. 일반적으로 이는 로컬 및 원격 차이를 추적하지 않아서 발생했습니다. GUI 도구와 CLI는 모두 이것을 잘 보여주지 못합니다. CLI git log --decorate에서 차이점을 간략하게 설명하는 가장 쉬운 방법을 찾았 습니다. 하지만 주인이 예를 들어 머리카락이 너무 털이 많으면git reset --hard origin/master

2
마지막 요점 : 정말 빠르고 구조적인 개요는 git log --oneline --decorate --graph이상적입니다. 그래서, 그 정확한 조합을 위해 쉘 별명을 정의했습니다.
cmaster

1
당신의 대답에 +1, 나는 당신이 언급 한 이유 때문에 제안 된 대안이 나쁘다는 것을 알았습니다. SVN으로 돌아가서 나중에 git으로가더라도 고통을 겪을 것입니다. 팀원은 다른 옵션이없는 경우 새롭고 다른 고통스러운 도구 만 배우게됩니다. 사용법과 어리석은 실수를 한 후에야 git이 할 수있는 일을 감상하기 시작합니다.
CodeMonkey

8

- 하나의 가능한 메커니즘은 오픈 소스 팀이 많이 채택했다고는 포크 (fork) 모델을 사용하는 것입니다 https://www.atlassian.com/git/tutorials/comparing-workflows 포크 (fork)의 자식 워크 플로우를 논의 할 때 (명확하게 발음해야을 ) .

여기에서 각 개발자 또는 하위 팀은 BitBucket 에서 체크 아웃하는 저장소 의 자체 포크 를 가지고 있으며 이에 대한 메커니즘을 제공 하여 기본 원격 외에도 "업스트림"원점을 설정합니다. "및"원격 / 업스트림 / 마스터 병합 "을 정기적으로 수행하십시오.

빌드 도구가 다른 프로젝트, 즉 포크에서 마스터를 가리킬 수 있으므로 빌드 메커니즘 문제를 해결할 수 있습니다.

그런 다음 대부분의 사람들로부터 마스터 프로젝트로 직접 푸시 할 수있는 능력을 제거하고 역할을 검토하고 승인하는 소규모 팀으로 만들 수 있습니다. https://www.atlassian.com/git/tutorials/making-a-pull-request를 참조 하십시오

- 장소는 바람직 검사 푸시 전에 완료 단지에 대한 후크에있는 자식 책 섹션에 보장에 최대 읽기 https://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks - 사전 커밋 및 사전 푸시 후크를 사용하여 제안 된 커밋에서 일부 테스트를 실행하여 작업이 유효한지 확인하는 등의 작업을 수행 할 수 있습니다.-클라이언트 측 후크의 유일한 문제점은 개발자가이를 비활성화하거나 활성화 할 수 없다는 것입니다 그들.

TortoiseGit에서는 업스트림 페치 / 병합 및 후크를 모두 사용할 수 있습니다.


정말 나쁜 생각이 아닙니다. 또한이 팀이 더 편안해질 때까지 Merge Master의 혜택을 누릴 것 같습니다. +1
Greg Burghardt

2
BitBucket에는 가능하면 포크를 자동으로 빨리 감는 포크 동기화 기능이 있습니다. 오늘 포크하고 다음 주에 업스트림에 대해 걱정하지 않고 출발점에서 출발하는 것이 매우 편리합니다.
piedar

3

이것은 직관적이지 않은 것처럼 들리지만 내 말을 들어보십시오.

git으로 실험을 시작하도록 장려하십시오

git의 흥미로운 점 중 하나는 로컬 작업을 완전히 안전하게 만드는 것이 놀랍도록 쉽다는 것입니다. 내가 git을 처음 사용했을 때, 내가 찾은 것 중 하나는 무언가를 망 쳤을 경우를 대비하여 전체 디렉토리백업 으로 압축 하는 것이 었 습니다. 나중에이 거대한 kludge과 거의 절대 실제로 필요한 작업을 보호하는 것입니다,하지만 그것은 존재의 미덕이 있다는 것을 발견 매우 안전하고 매우 당신이 일을 어떻게하고있는 지옥에서 무엇을 알 수없는 경우에도, 간단하게 시도하려는 명령이 나타납니다. 이 작업을 수행 할 때 피해야하는 유일한 방법은 push입니다. 아무것도 밀지 않으면 원하는 것을 시도 할 수있는 100 % 안전한 방법입니다.

물건을 시험해 보는 것에 대한 두려움은 자식 학습에 가장 큰 장애 중 하나입니다. 그것은 당신에게 모든 것을 통제 할 수 있게 해줍니다 . 실제로 대부분의 일상적인 작업에서 매우 안전한 몇 가지 작업을 수행 할 수 있지만 어떤 명령을 탐색해야하는지 알아볼 수 있습니다.

그들에게 안전 감각을 부여함으로써 , 그들은 스스로 일을 수행하는 방법을 알아 내려고 훨씬 더 기꺼이 할 것입니다. 또한 로컬 컴퓨터에서 자신에게 적합한 개인 작업 흐름을 찾을 수 있습니다. 그리고 모든 사람이 로컬 에서 똑같은 일을하지 않는다면, 그들이 추진 하는 표준을 준수하는 한 괜찮습니다 . 그렇게하기 위해 작업을 수행하기 전에 전체 리포지토리를 압축해야하는 경우 괜찮습니다. 그들은 일을하고 시도 할 때 더 좋은 방법으로 일을 할 수 있습니다. 뭐든지 자신이 시작 얻기 위해 노력하고 물건을하고 무엇을보고.

그렇다고 훈련이 무가치하다는 의미는 아닙니다. 반대로 훈련은 기능, 패턴 및 규범을 소개하는 데 도움이 될 수 있습니다. 그러나 일상 생활에서 앉아서 실제로 일을하는 것을 대체하지는 않습니다 . git이나 SVN은 수업에 갈 수있는 것이 아니며 모든 것을 알고 있습니다. 당신은해야 사용할 그들과 어떤 기능에 익숙해하는 문제를 해결하기 위해 그들을 잘하는 문제에 대한 적합하다.

git의 내용을 배우지 못하게하십시오.

나는 당신이 그들에게 가르치고있는 것 중 하나에 반대되는 것을 밀어 붙이는 것에 대해 언급하지 않았습니다. 나는 당신이 그들에게 이것을하도록 말하고 그 반대를 시작하라고 말해야한다고 믿습니다. Git에는 기본적으로 5 개의 "장소"가 있으며 변경이 가능합니다.

  • 디스크에서 커밋되지 않은
  • 단계적이지만 완결되지 않은
  • A의 지역 커밋
  • 현지 은신처에서
  • 원격 리포지토리 (커밋 및 태그 만 다른 리포지토리간에 푸시 및 풀링 됨)

한 번에 모든 것을 끌어 당기도록 장려하는 대신이 5 가지 장소를 활용하도록 장려하십시오. 그들에게 다음을 권장하십시오.

  • 커밋하기 전에 변경 사항을 가져옵니다.
  • 메이크 결정에 가져온 변화를 처리하는 방법을. 옵션은 다음과 같습니다.

    • 로컬 변경 사항을 커밋 한 다음 가져온 변경 사항을 기반으로 변경합니다.
    • 로컬 변경 사항을 커밋 한 다음 가져온 변경 사항과 병합하십시오.
    • 변경 사항을 저장하고 병합 한 다음 충돌을 해결하고 해결하십시오.

      다른 것들이 있지만 여기에 들어 가지 않습니다. 풀은 말 그대로 페치 및 병합입니다. 그것은 아니에요 처럼 그들을; 그것은 이다 그. (통과 --rebase변경 사항은 가져 오기 + 병합에서 가져 오기 + 리베이스로 가져옵니다.)

  • 변경 사항을 준비한 후 검토하십시오.
  • 단계적 변경 사항을 커밋 한 다음 커밋을 검토하십시오.
  • 별도로 밀어 넣습니다.

이를 통해 모든 사람이 공개적으로 제공 하기 전에 자신의 작업을 확인하도록 권장하므로 실수를 빨리 포착 할 수 있습니다. 그들은 및 SVN 달리, 그들이 할 수있는 "즉 내가 원하지 않는 것을 잠깐,"커밋 생각의 볼 돌아가서 그들이 밀어 넣기 전에 다시 시도하십시오.

변경 사항의 위치 를 이해 하는 데 익숙해지면 단계를 건너 뛸 때와 특정 작업을 결합하는 시점을 결정할 수 있습니다 (이미 가져 오기 + 병합을 알고 있기 때문에 풀 때 또는 커밋 및 푸시 옵션을 클릭하는 시점) .

이것은 실제로 SVN에 비해 git의 큰 이점 중 하나이며 git은 이러한 사용 패턴을 염두에두고 설계되었습니다 . 반면 SVN은 중앙 리포지토리를 가정하므로 git 도구가 동일한 워크 플로에 대해 최적화되지 않은 경우 놀라운 일이 아닙니다. SVN에서 커밋이 잘못되면 실수를 취소하기위한 새로운 커밋이 유일합니다.

이렇게하면 실제로 다음 전략으로 이어질 것입니다.

지역 지점 을 사용하도록 격려

로컬 브랜치는 실제로 공유 파일 작업의 많은 어려움을 완화시킵니다. 나는 내 자신의 지점에서 원하는 모든 변경을 할 수 있으며, 그것을 밀지 않기 때문에 누구에게도 영향을 미치지 않습니다. 그런 다음 시간이 오면 동일한 병합 및 리베이스 전략을 모두 쉽게 사용할 수 있습니다.

  • 로컬 브랜치를 리베이스하여 마스터로 합병 할 수 있습니다.
  • 마스터에서 일반 병합 (새 커밋 만들기)을 사용하여 로컬 지점의 변경 사항을 가져올 수 있습니다.
  • 내 지점이 구제하기에 너무 엉망이라고 생각하면 전체 로컬 지점을 마스터의 단일 커밋으로 병합 할 수 있습니다.

현지 지점을 사용하는 것도 체계적인 지점 전략을 수립하기에 좋은 출발입니다. 사용자가 자신의 브랜칭 요구를 더 잘 이해하는 데 도움이되므로 모든 사람이 들었 기 때문에 Gitflow에 빠지지 않고 요구와 팀의 현재 이해 / 기술 수준을 기반으로 전략을 선택할 수 있습니다.

요약

간단히 말해서, git은 SVN이 아니며 그렇게 취급 될 수 없습니다. 다음을 수행해야합니다.

  • 안전한 실험을 장려함으로써 두려움을 제거하십시오.
  • git의 차이점을 이해하도록 도와 주어 이것이 일반적인 워크 플로우를 어떻게 변화시키는 지 확인할 수 있습니다.
  • 문제를보다 쉽게 ​​해결하는 데 도움이되는 기능을 이해하도록 도와줍니다.

이것은 표준 세트 구현을 시작할 수있을 때까지 점차적으로 더 나은 git 사용법을 채택 하는 데 도움이됩니다 .

특정 기능

당장 다음과 같은 아이디어가 도움이 될 수 있습니다.

리베이스

당신은 rebase를 언급했고 실제로 당신의 질문에서 그것을 이해하지 못한다고 언급했습니다. 여기 내 조언이 있습니다 : 방금 설명한 것을 시도해보십시오. 다른 사람이 일부 변경 사항을 푸시하는 동안 로컬로 변경하십시오. 로컬로 변경 사항을 커밋하십시오 . 저장소 디렉토리를 백업으로 압축하십시오. 상대방의 변경 사항을 가져옵니다. 이제 rebase 명령을 실행하고 커밋에 어떤 영향이 있는지 확인하십시오! 끝없는 블로그 게시물을 읽거나 rebase 및 사용 방법에 대한 교육을받을 수 있지만 실제로 사용하는 것을 대체하는 것은 아닙니다. 그래서 시도 그것을 밖으로.

merge.ff=only

이것은 개인적인 취향의 문제가 될 것이지만, 이미 충돌 처리에 문제가 있다고 언급했기 때문에 적어도 일시적으로 추천 할 것입니다. 다음으로 설정 merge.ff하는only 것이 좋습니다 .

git config --global merge.ff only

"ff"는 "빨리 감기"를 나타냅니다. 빨리 감기 병합은 git이 다른 커밋의 변경 사항을 결합 할 필요가없는 경우입니다. 단지 그래프의 직선을 따라 분기의 포인터를 새로운 커밋으로 이동시킵니다.

이것이 실제로하는 일은 git이 자동으로 병합 커밋을 만들지 못하게하는 것입니다. 따라서 로컬로 무언가를 커밋 한 다음 병합 커밋을 만들려고 시도하지 않고 잠재적으로 사용자가 충돌을 처리하지 않고 다른 사람의 변경 사항을 가져 오면 병합이 실패합니다. 실제로 git은 fetch. 로컬 커밋이 없으면 병합이 정상적으로 진행됩니다.

이를 통해 사용자는 커밋을 시도하기 전에 다른 커밋을 검토 할 수 있으며, 커밋 을 가장 잘 처리하는 방법에 대한 결정을 내릴 수 있습니다. 리베이스하거나 병합을 계속 진행 git merge --no-ff하거나 (구성을 무시하는 데 사용) 변경 사항을 병합하지 않고 나중에 처리 할 수도 있습니다. 이 작은 속도 충돌은 팀이 병합에 대한 잘못된 결정을 피하는 데 도움이 될 것이라고 생각합니다. 병합 처리에 익숙해지면 팀을 끌 수 있습니다.


2

나는 회사에서 똑같은 SVN-> git 경험을 겪었고 내 경험에서 유일한 해결책은 시간입니다. 사람들이 도구에 익숙해 지도록하고 실수를 저지르고 수정 방법을 보여줍니다. 당신의 속도는 잠시 동안 고통을 겪을 것이고, 사람들은 일을 잃게 될 것이고, 모든 사람들은 조금 어려워 질 것입니다. 그러나 그것은 VCS처럼 근본적인 것을 바꾸는 성질입니다.

즉, TortoiseGit이 과도기 초기에 도움이 아니라 방해가된다는 의견을 가진 모든 사람들에게 동의합니다. TortoiseGit은 ... 최고의 GUI는 아니지만, 간결성의 이름으로 git이 실제로 어떻게 작동하는지 모호하게함으로써 동료가 2 단계 커밋과 같은 핵심 git 개념을 이해하지 못하게합니다.

우리는 개발자가 일주일 동안 명령 줄 (git bash 또는 posh-git ) 을 사용하도록 강요하기보다는 (극심한) 결정을 내 렸으며 git이 실제로 어떻게 작동하고 SVN과 어떻게 다른지 이해하는 데 놀라운 결과를 얻었습니다. 과감하게 들릴지 모르지만 git 모델에 대한 이해를 돕기 때문에 간단하게 시도해보십시오. 동료가 있으면 동료는 git보다 GUI 외관을 사용할 수 있습니다.

마지막 참고 사항 : git의 작동 방식을 거의 즉시 파악한 동료가 있으며, 절대 그렇지 않은 사람들이 있습니다. 후자의 그룹에서는 모든 사람들이 볼 수 있도록 자신의 코드를 로컬 컴퓨터에서 서버로 가져 오도록 신비로운 주문을 가르쳐야합니다.


1

글쎄, 최근에는 마스터 브랜치를 방해하지 않도록 다음 워크 플로를 조정했습니다.

1) 모든 사람은 자신의 지점을 사용하는데, 이는 처음에는 마스터 지점의 사본입니다.

마스터 브랜치를 "master"로, 내 ​​브랜치를 "my_master"로 지정하겠습니다.

방금 마스터에서 지점을 만들었으므로 정확히 동일합니다. 내 지점에서 새로운 기능에 대한 작업을 시작하고 완료되면 다음을 수행합니다.

내 지점에 Currenly, 방금 코딩 완료

git add . && git commit -m "Message" && git push

마스터 브랜치로 돌아 가기

git checkout master

최신 상태가 아닌 경우 당기기

git pull

내 지점으로 돌아가

git checkout my_master

최신 마스터를 내 지점으로 병합

git merge master

충돌 및 병합 수정

모든 것을 다시 테스트하십시오

모든 것이 내 지점에 병합되고 고정되면 밀어냅니다.

git push

마스터 브랜치로 돌아 가기

git checkout master

내 지점과 병합

git merge my_master

이전 병합으로 자신의 브랜치에서 해결 될 때 충돌이 발생할 수 없음

푸시 마스터

git push

모두가 이것을 따르는 경우, 마스터 브랜치는 깨끗해질 것입니다.


0

그래서 우리는 TFS에서 git로 전환하고 구식 사고 방식을 유지 한 팀이 있습니다. 일반적인 작동 규칙은 거의 동일합니다.

예, 이것은 모든 사람이 마스터에서 일한다는 것을 의미합니다. 이것은 나쁘지 않습니다. TFS 나 SVN에 익숙한 팀이 가장 자연 스러울 것입니다.

이것을 가능한 한 고통스럽게 만드는 일반적인 절차 :

  1. 이렇게 git stash && git pull --rebase && git stash pop매일 아침
  2. 일찍 그리고 자주 커밋하십시오 (즉시 푸시 할 필요는 없습니다. 우리는 적어도 git의 이점을 일찍 시작할 수 있습니다)
  3. 푸시하려면 다음 루프를 수행하십시오.

    git add git commit git pull --rebase fix any merges compile git push loop until you don't get the can't fast forward error message.


이렇게하면 SVN을 유지할 수 있습니다. 자동차 시절에도 말 마차를 타면서도 마찬가지였습니다. 물론, 말 마차와 같은 속도로 차를 운전할 수 있습니다. 그러나 이것으로 당신이 달성하는 것은 스스로를 방해하고 자동차를 운전할 수있는 사람들을 화나게 만드는 것입니다. 차 운전을 배우십시오. 지금.
cmaster

@ cmaster : 우리에게 git의 가장 큰 장점은 서버 손실이 전체 소스 제어 기록을 잃지 않는다는 것입니다. (우리에게는 백업이 있었지만 테이프 드라이브는 복원하려고 할 때 테이프를 먹기 시작했습니다.)
Joshua

@ cmaster : 이후로 유용한 다른 git 기능을 소개하기 시작했지만 변경 분기는 아마도 사용되지 않을 것입니다.
Joshua

@cmaster 차를 천천히 운전하는 것과 말을 타는 것의 차이점은 차를 운전하면 더 빨리 운전할 수 있다는 것입니다. 말을 타고하지 않습니다. 차에 타는 모든 사람이 처음 몇 번이나 60mph를 타기 위해 가스를 칠 필요는 없습니다.
jpmc26

@ jpmc26 첫 운전 수업을 받았을 때, 30km / h를 운전하라는 요청을 받았으며, 그 수업에는 50km / h의 짧은 거리도 포함되어 있다고 생각합니다. 그것은 전형적인 말 마차보다 훨씬 더입니다. 그리고 같은 간다 git당신은 일반적으로 포크와 첫날부터 병합하는 법을 배워야 :. 이는을 사용하는 데 필수적인 부분입니다 git. 이를 피하십시오. 15km / h를 넘지 않을 때 자동차를 학대하는 것과 같은 방식으로 공구를 학대하고 있습니다.
cmaster

-3

모두가 마스터 작업을하고 있다면 할 수있는 일은 없습니다. 일이 필연적으로 엉망이 될 것입니다.

고객에게 발송되는 완제품에는 master를 사용해야합니다. 지속적인 개발을 위해서는 개발을 사용해야하며, 누군가가 개발을 추진하도록 허용 해서는 안됩니다 . 표준은 모든 사람이 dev에서 분기하여 변경을 수행하고 로컬에서 서버의 분기로 푸시하고 푸시 요청을 발행하는 것입니다. 그런 다음 누군가 변경 사항을 검토하고이를 개발에 병합합니다.

충돌을 피하기 위해 모든 사람은 추진하기 전에 개발을 자체 지점으로 병합하고 해당 단계에서 충돌을 해결합니다 (따라서 로컬에서는 한 개발자에게만 영향을 미침). 개발에 병합하면 충돌이 발생하지 않습니다. 병합되지 않습니다. 개발자가 개발을 지점으로 다시 병합하고 서버로 다시 푸시 한 다음 다시 검토합니다.

예를 들어 소스 트리를 사용하여 고통 없이이 작업을 수행 할 수 있습니다.


4
기본 체크 아웃 후에 사람들이 개발 지점으로 전환하지 않을 위험이 추가되어 "마스터"를 "개발"로 바꾸는 것입니다. 무거운 GitFlow와 스파 스 GitHub Flow 사이의 행복한 매체 인 GitLab Flow를 선호합니다 .
Cees Timmerman

당신이 Gitflow 마음에 들지 않으면 @CeesTimmerman, 당신은에 관심이있을 수 Oneflow 도.
jpmc26
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.