문맥

8 명의 엔지니어 팀이 현재 다음 큰 것을 위해 Git (Subversion에서)으로 전환하고 있습니다. 우리는 Git을 선택하기가 매우 어려운 소수의 '보다 숙련 된'엔지니어를 보유하고 있습니다. 사용자 매뉴얼, 교육 활동 및 화이트 보드 세션을 제공했지만 동일한 사소한 질문을받습니다. 우리는 며칠 만에 모든 것을 습득 한 두 명의 주니어 컨설턴트가 있었으며 실제로이 문제에 대해 빛을 발했습니다. 이것은 Git으로 제한되는 패턴은 아니지만 결과적으로 보입니다.

질문

나는 배우지 못하거나 배우지 못하는 엔지니어들, 특히 우리가 여기있는 선배 수준의 직원들에게는 특히 호의적이지 않습니다. 그러나 나는 팀이 성공하고 훌륭한 제품을 만들기를 원합니다. 우리는 중앙 집중식 Git Flow 모델을 사용하고 있으며 모든 새로운 용어가 당황 스럽습니다.

이 직원들이 Git을 배우도록 도울 수있는 방법이 있습니까?

Sourcetree 는 전체 팀에서 사용중인 클라이언트입니다.

그들에게 장난감을주세요.

힘내 어렵다. 특히 다른 패러다임에서 소스 제어를 수행 한 경우. git으로 처음 작업을 시도했을 때 빌드를 중단했습니다. 그것은 모든 것을 마칠 때까지 체크인하고 싶지 않은 편집증이되었습니다. 폴더에 버전을 숨기고있었습니다. 그런 다음 마침내 그것을 지나는 데 필요한 것을 알아 냈습니다.

플레이하기에 안전한 장소가 필요했습니다.

일단 그런 일이 생기면 의도적으로 문제를 일으켜 문제를 해결하는 방법을 안전한 곳에서 배울 수있었습니다. 중단 되더라도 사용할 수있는 패턴을 개발했지만 여전히 양호한 상태로 돌아 왔습니다. 얼마 지나지 않아 사람들이 git에 대한 도움을 받기 위해 나에게 왔습니다. 장난감을 가지고 노는 데 시간이 걸렸기 때문입니다.

당신이 그들을 깊은 곳으로 던져 버린다면, 그들이 부유하게되면 운이 좋을 것입니다.

평균 개발자는 많은 git 's goodies가 필요하지 않습니다. 분산 소스 제어 시스템이지만 대부분의 팀은 중앙 표준 저장소와 함께 사용하여 밀어 넣습니다.

팀에 필요한 핵심 명령은 다음과 같습니다.

• 원격에서 변경 사항을 가져 와서 병합하고 결과 충돌을 처리합니다 (잠재적으로 재조정)
• 커밋 및 푸시 커밋을 원격으로 (또는 검토 후 변경 사항을 메인으로 가져 오기 위해 리포지토리 / 분기로 푸시)
• 지원 : 잘못된 일을 한 후 엉망을 해결하십시오.

고급 사용자가 필요로하는 사람들은

• 로컬 커밋 처리
• 지점 관리

git에 익숙하지 않은 사람들과 배우기를 원하지 않는 사람들에게는 몇 가지 빠른 별칭 명령을 설정하여 모든 것이 올바른지 확인하십시오 (새 파일 추가, 저장소에서 삭제 된 파일 제거 등).

이것들이 잘 문서화되고 괜찮은 바보 증거인지 확인하십시오.

이것은 xkcd comic 의 정맥에 있습니다 . 명령을 외우고 전문가에게 요청할 때 너무 많이 엉망이되기를 바랍니다.

Git UI를 사용하도록합니다.

TortoiseSVN에 경험이있는 경우 TortoiseGit (Windows 만 해당) 는 거의 동일하게 작동합니다. 그렇지 않으면 SourceTree (Windows + Mac) 가 훌륭합니다. SourceTree 덕분에 Git에서 복잡한 작업을 쉽게 마스터 할 수있는 개발자가 아닌 여러 QA가 있습니다.

이 답변 은 가장 빠른 방법 git을 배우는 방법이 아니라 상급 프로그래머가 관심을 갖도록하는 방법을 다루려고 git합니다. 우수한 git book 이 훌륭하거나, 많은 튜토리얼 (=> Google)입니다. 이 답변에 대한 좋은 링크는 Git은 순전히 기능적인 데이터 구조 이거나 특히 git이 데이터를 저장하는 방법 입니다.

나는 이것에 대해 다소 황량한 견해를 가지고 있습니다. 나는 정확하게 당신의 신발에 있었어요-나는 git대단하고 팀을 멀리 svn하고, 직면하고, 작은 결과 를 바꾸고 싶었습니다 . 제 경우에는 적극적으로 자신의 인식을 바꾸고 사람들을 받아들이는 것만으로 "행복을 강요"할 수 없습니다. 사람들은 컴퓨터가 아니며 프로그래밍하기가 매우 어렵습니다. 나는 시도한 것에 대해 여전히 행복하다. 그것은 내가하는 일과 직업 생활에서하고 싶지 않은 일을 다소 부드러운 방식으로 보여 주었다.

새로운 것들이 관여 할 때 동기를 부여하기 시작하는 사람들이 있고, 동기를 부여하는 사람들이 있습니다. 이것은와는 아무런 관련이 git없지만, git특히 "만약 svn괜찮다 면 왜 사용해야 합니까?"라는 효과가 있습니다. 이는 엄청난 심리적 장벽입니다.

또한 실제로 git데이터를 처리하려면 추상적 인 데이터 구조에 많은 관심을 기울여야합니다. 그것은 믿을 수 없을 것 같지만, 내 경험상 전혀 관심이없고 단순한 배열보다 복잡한 요소에 의해 지루하고 부담이 많은 프로그래머가 있습니다. 그들이하고있는 일을해야하는지 여부를 앞뒤로 논쟁 할 수 있지만 그것이 바로 그 일입니다.

사람들이 관심이 없다면 이해하지 못할 것입니다. 평범하고 단순합니다. 나는 지식이 빠지지 않고 학교에서 나쁜 성적의 주된 이유가 무관심이라고 내기를했습니다.

즉, 아래에서 위로 쌓은 지식을 바탕으로 적용 할 수있는 커리큘럼이 있습니다. 그것은 나를 위해 일하지 않았지만, 당신은 그것을 자신의 롤을 영감으로 취할 수 있습니다.

GUI

다음 접근법은 조치에 대한 GUI 지원이 반드시 필요한 것은 아니지만 ( git addhello world 저장소에서 ...) 처음부터 저장소를 시각화하기위한 GUI를 갖는 것이 엄청나게 도움이됩니다 . 사용할 것을 결정할 수 없다면 gitk최후의 수단으로 사용하십시오. 여러분의 시각적 편집기를 사용하는 경우 gitGUI 구성 요소를 찾으십시오 .

(정적) 데이터 구조가 핵심

내부 데이터 유형 (블롭, 트리, 커밋, 주석이 달린 태그, 마지막 단계는이 단계에서 전혀 중요하지 않음)과 그 구조에 대해 설명하는 것으로 시작하십시오. 화이트 보드 / 연필로 쉽게 할 수 있습니다. 나무는 절대로 변경할 수 없으므로 그리기가 쉽습니다. 문자 그대로 항상 물건을 추가 할 수 있습니다. 새로 만든 로컬 리포지토리에서 재생 세션을 수행 git cat-file하여 실제 개체를 조사하여 실제로 광고 된 것처럼 사소한 것임을 나타낼 수 있습니다 .

그들이 이해하도록 도울 수 있다면

• ... 역사상 말 그대로 3 가지 유형의 객체가 있습니다.
• ... 대부분의 git부속 명령은 사소한 조작 (기본적으로 어딘가에 새 커밋을 추가 함)을 사용하여 이러한 오브젝트를 한 가지 방법으로 "마사지"합니다.
• ... 모든 것이 쉽게 할 수있다 알 권리와 당신의 앞에 ls와 git cat-file...

그런 다음 실제로 저장소에있는 내용을 정신적으로 번역합니다. 이 시점에서, seniours는 수 의 내부가 기억 svn(또는 "재 통합"나뭇 가지와 같은과? 지금 SVN 저장소 내부 잠금 장치에 문제가 있었다) 비전 마법, 그리고이 수 그들에게 약간의 동기를 부여 단지.

하나의 문제는, 특별히 사용 사람들과 svn항상 하나 (객체가 아닌 행동을) 저지한다는 생각에 익숙해하는 것입니다 전체 디렉토리 트리. 에서 svn, 사람들은 개별 파일을 커밋하는 데 사용됩니다. 근본적으로 다른 접근법입니다. 아, 그리고 "commit"이라는 동일한 용어가 정적 객체와 둘 다에 사용된다는 사실도 도움이되지 않습니다.

svn남자의 또 다른 문제 svn는 나무가 아닌 선형 이력 을 사용 한다는 것입니다. 다시 말하지만 이것은 크게 다릅니다. 이 시점에서 이러한 차이 를 많이 지적해야합니다 .

구조 측면에서 설명 된 동작

이들이 git저장소를 구성하는 부분을 이해했으면 개별 부속 명령이 해당 기능과 관련하여 수행하는 작업을 정확하게 표시해야 합니다git .

내가 얘기하고 add, commit로컬 작업 디렉토리와 단계 (그들이 작업 디렉토리가 저장소와 동일하지 않습니다 스테이징 영역과 동일하지 않습니다 알고 있어야합니다)와 함께한다.

때 그들은 이러한 명령은 단순히 나무 성장하는 것을 이해 (다시,이 단계에서, 구성 3 종류의를 - 모양, 나무,뿐만 아니라 커밋 커밋), 당신이 먼저 할 수있는 git push및 git pull빨리 감기 모드 (! ) git문자 그대로 객체를 밀고 있음을 보여주기 위해 해시는 실제로 콘텐츠 해시 일 뿐이며 파일 시스템 복사 명령 등 으로이 내용을 쉽게 복사 할 수 있습니다.

분명히, 이러한 명령의 불필요한 옵션에서 멀리 떨어지 git add hello.txt십시오. 우리는 여기서 이야기하고 있습니다.

지점

분기 svn는 완전히 다르기 때문에 사람들에게 특히 어렵습니다 . svn모델은 훨씬 기본적으로 시각화하는 것이 존재하지 않기 때문에, 시각화하기 쉬운 - 그것은 일반보기입니다. git모델을 너무 많이하지. 시작부터 브랜치와 태그가 어딘가를 가리키는 "스티커 노트"라는 사실을 인식하고 정적, 불변의 히스토리와 관련하여 실제로는 존재하지 않는지 확인하십시오.

그런 다음 쉬운 예를 들어 실제로 할 수있는 일을 보여주는 예를 들어보십시오. 당신이 익숙해 져있는 것처럼 git, 동기 부여를 찾는 데 어려움이 없어야합니다. 나무가 자라는 방식으로 항상 이것을보아야합니다.

그들이 그것을 가지고 있다면, 당신 git pull은 실제로 어떻게 설명 할 수 있습니다 git fetch && git merge; 모든 리포지토리에 실제로 정확히 동일한 객체 가 포함되는 방법 ( git 객체 디렉토리 내부에서 git fetch물건을 복사하는 것과 거의 동일 함 scp) 등.

아마, 지금까지 당신이 그들의 관심을 불러 일으키지 않았다면, 당신은 또한 포기할 수 있지만, 그들이 지금까지 얻을 수 있다면, 그들은 모든 정신적 도구를 사용할 수 있으며, 거의 없어야합니다. 더 이상 걱정이 없습니다. 나머지는 (git workflow ...) 내리막 길이어야합니다.

마지막 말

이것은 많은 노력처럼 들리지만 실제로 있습니다. 이것을 "우리는이 프로젝트에 필요합니다"라고 팔지 말고 "이것은 개인적으로 개발하는 데 도움이되고 앞으로의 모든 상호 작용에 도움이 될 것입니다"라고 판매하지 마십시오. 이를 위해서는 많은 시간이 필요 하며 시간은 돈입니다. 이에 대한 관리 승인이 없다면 가치가 없을 수도 있습니다. 상사와상의해야 할 수도 있습니다.

당신이 그것을 이해하지 못하는 것처럼 보이는 개발자들을 가르치기를 포기하기로 결정했지만 git, 앞으로 반드시 사용해야 할 경우, 모든 상호 작용을 git요리 스크립트 또는 GUI 로 모든 상호 작용을 명령으로 대체하는 것을 고려하십시오 git. 스크립트에서 모든 오류 제어 등을 따르고 작동하도록하십시오.

Joel Spolsky 의이 블로그 항목 을 참조하고 싶습니다 .

이 주니어 개발자가 빠르게 선택하는 이유는 일반적인 버전 제어 방식에 대한 사전 결정된 개념이 없거나 적어도 심오한 정신적 모델이 아니기 때문일 가능성이 높습니다. 따라서 그들은 슬레이트가 깨끗합니다. 상급 프로그래머들은 이미 알고있는 개념을 적용하려고하는데 그 결과로 실패합니다.

이것 외에, 내가 말하고 싶지 않은만큼; 누가 실제로 사용자 매뉴얼을 읽습니까? 일반적으로 기본 사용법을 설명하는 데 매우 나쁩니다. 매뉴얼 의 git commit 페이지 를 보고 개념에 익숙 하지 않은 사람에게 얼마나 많은 새로운 용어와 문구가 소개되는지 고려하십시오. 좋은 소개가 없다면 Git 사용을 포기했을 것입니다.

내 개인적인 조언은 명령을 설명하는 것입니다.

• git add <파일>
• 자식 커밋
• 자식 풀
• 자식 푸시
• 자식 상태

사람들이 코드를 커밋하는 법을 배우면 첫 번째 문제가 될 것이기 때문에 논리적 병합 충돌에 대해서는 다음에 설명해야합니다.

일반적으로 사람들이 학습에 많은 시간을 투자해야하는 상황이 발생합니다 (복귀, 태그, 병합 충돌, 분기, 리베 이싱, 갈고리). 필요하기 전에이 모든 것을 설명하려고 시도해도 문제가있는 사람들에게 도움이되지는 않습니다. 흐름.

결론 : 개인적인 경험에서 일부 사람들은 단순히 새로운 기술, 개념 또는 도구를 탐색하는 데 많은 시간을 소비하지 않으며 일반적으로 느린 속도로 소개하는 것들을 선택하는 경향이 있습니다. 이것은 그들이 나쁜 프로그래머 나 나쁜 사람들을 의미하지는 않지만 일반적으로 더 좁은 기술을 가지고 있습니다.

SVN에서 소스 제어를 수행하는 방법을 배웠다면 Git은 중요한 생각입니다. 여기에서 개발 한 많은 습관 (SVN에 대한 모범 사례 일 수 있음)은 git을 사용할 때 잘못 안내합니다. git의 브랜칭 모델이 근본적으로 다르기 때문입니다. 분기에 폴더 를 사용 하지 않으며 분산 사용 사례를 더 잘 지원하도록 설계되었으므로 비선형으로 만들 수도 있습니다. 그것은 SVN 습관을 잊다 당신이있어 방법을 이해하는 데 시간이 소요 되어 자식을 사용합니다.

간단하게 시작

지사 관리 표준으로 Gitflow를 선택했다고합니다. 이것은 나를 당신의 가장 큰 실수로 생각합니다.

Gitflow가 유해하다고 간주하는 인용문 :

사용되는 모든 분기는 GitFlow가 상호 작용 방식을 설명하는 복잡한 규칙을 정교하게 만들도록합니다. 이러한 규칙은 무형의 역사와 함께 개발자에게 일상적인 GitFlow 사용을 매우 어렵게 만듭니다.

복잡한 규칙 웹을 설정할 때마다 어떻게 될지 추측 할 수 있습니까? 맞습니다. 사람들은 실수를해서 실수로 부러 뜨립니다. GitFlow의 경우 항상 발생합니다. 여기에 내가 본 가장 일반적인 실수에 대한 철저한 목록이 있습니다. 이들은 같은 개발자들에 의해 지속적으로, 때로는 매일 반복적으로 반복되며, 대부분의 경우 다른 소프트웨어 분야에서 매우 유능한 동일한 개발자들에 의해 반복됩니다.

이 표준의 복잡성 때문에 개발자가 압도적 일 수 있습니다. 나는 개인적으로 그것이 이익이 있다고 생각하지 않으며, 위의 기사는 같은 주장을합니다. 그러나 그것은 별도의 토론입니다. 객관적으로, 그것은 많은 수동 관리를 가진 꽤 무거운 표준이며, 많은인지 노력이 필요합니다.

더 간단하게 시작해야합니다. 현재 분기 표준에 대해 걱정하지 마십시오. git을 먼저 사용하는 데 집중하십시오 . 시작하려면 몇 가지 작업 만 있으면됩니다.

• 복제
• 손잡이
• 분기
• 합병
• 범하다
• 푸시
• .gitignore작동 방식에 대한 지식
• 아마도 태그

그렇습니다. 당신의 역사는 처음에는 조금 혼란스러워 보일 수 있습니다. 괜찮습니다 지금 걱정하지 마십시오. 그냥 git 사용하십시오 .

점차 지식을 증가

여기에서 조금 더 고급 사용법을 점차적으로 교육 할 수 있습니다.

• 그들에게 서사시 스테이크 명령을 가르쳐
• 그들이 방금 만든 로컬 커밋을 버리고 싶을 때 어떻게 리셋을 사용하는지 가르쳐라
• 수정하는 방법을 가르쳐주십시오
• 불필요한 병합 커밋을 피하기 위해 리베이스하는 방법을 가르치십시오.
• 강요하기 전에 커밋을 구성하기 위해 대화식으로 리베이스하는 방법을 가르치십시오.
• 해시, 태그 또는 브랜치에서 어떻게 체크 아웃 할 수 있는지 가르쳐주세요

특히 코드를 리포지토리에 가져 오는 더 깔끔한 방법을 보여줄 수있는 기회를 활용하고 교육 활동과 그 내용에 대해 가르쳐주십시오. 사람들이해야 할 일이 확실하지 않을 때 접근 할 수있는 전문가 한두 명을 갖는 것도 많은 도움이 될 것입니다. 슬랙 (Slack)과 같은 것이 있다면 전용 채널을 만들고 사람들이 그곳에서 질문하고 답변하도록 격려하십시오.

그런 다음 분기 표준을 선택하십시오.

회사의 대부분이 git을 사용하는 데 능숙 하다면 지점 표준을 볼 수 있습니다. 하나를 미리 선택하는 것은 여러 가지 이유로 정말 나쁜 생각입니다.

• 표준이 회사의 사용 사례에 적합한 지 여부를 알려주는 도구에 대한 지식이 충분하지 않습니다.
• 대체 표준을 제공 할 수 없습니다
• 그들은 도구와 표준을 동시에 배워야합니다
• 일부는 선택한 표준이 git을 사용할 수있는 유일한 방법이라고 가정합니다.
• 표준이 좋은 것보다 더 큰 피해를주는 희귀 한 사례를 식별 할 수 없습니다.

산에서 Git 워크 플로를 전달해서는 안됩니다. 팀은 이에 대한 의견을 가지고 있어야하며 잘 진행되고 있는지에 대한 피드백을 제공 할 수 있어야합니다. 아직 기본 사항을 이해하지 못하면이 작업을 수행 할 수 없습니다. 이와 같이 깊이있는 지식을 갖기 위해 모든 단일 개발자가 필요하지는 않지만 실제로 그것을 얻는 사람이 반드시 필요합니다. 그리고 적어도 git에서 유능해야 대다수가 필요하기 때문에 레일에 다소 머무를 수 있습니다.

팀에서 고려할 수있는 Gitflow의 몇 가지 대안은 다음과 같습니다.

• OneFlow
• 기능 분기 워크 플로우
• 중앙 집중식 워크 플로우

Gitflow와 Gitflow를 살펴보고 사용 사례와 비교하여 적합한 것을 선택하십시오.

처음 Git 용어를 집어 들었을 때 stackoverflow가 매우 유용하다는 것을 알았습니다. 이 질문과 같은 질문은 저에게 정말 유용했습니다 (주로 간결함으로 인해). 나는 그것을 처음 사용했던 몇 주 동안 탭으로 열어 두었습니다. 어쩌면 몇 가지 답변을 굵게 인쇄 할 수 있습니까? 특히 첫 번째 다이어그램.

"git commit"과 "git push"의 차이점은 무엇입니까?

'git pull'과 'git fetch'의 차이점은 무엇입니까?

또한 트렁크의 시각적 표현이 놀랍도록 유용하다는 것을 알았지 만 이미 SourceTree로 트렁크를 덮고 있습니다.

_{옆으로,이 비트는 아마도 의견에 속하지만 담당자가 부족합니다. 나는이 문제에서 언급 한 하급 컨설턴트 중 하나입니다. 시작하기 전에 소스 제어 시스템이 무엇인지 알았으며 문자 그대로 SVN을 두 번 찌르는 것이 Gusdor는 나보다 더 많은 신용을 제공합니다. 전체 팀은 고품질의 특수한 Git 훈련, 장난감 및 놀이 시간을 가졌습니다. 문제는 Gusdor의 지시에 있지 않습니다. 나는 이것에 대한 좋은 대안 솔루션이 있기를 바랍니다. 그래서 열심히 북마크하고 더 배울 수 있습니다.}

그들에게 책을 사

솔직히, 나는 네가 묘사 한 진영에 푹 빠졌다. 나는 SourceSafe와 ClearCase의 배경에서 왔습니다. 처음에는 Git이 여러 번 걸었음에도 불구하고 Git은 나에게 완전히 구애받지 못했습니다.

저에게 도움이 된 것은 무슨 일이 있었는지 명확하게 설명하는 책 이었지만 더 중요한 것은 Git이 이전에 사용한 소스 제어 시스템과 근본적으로 어떻게 다른지에 대한 것입니다. 이제 다른 선택보다 Git을 선호합니다.

불행히도, 나는 당시에 읽은 책을 기억할 수 없지만, 당신이 그들 중 하나를 위해 (또는 그들을 가리 키는) 책이 어떻게 다른지 그리고 어떻게 다른 사고 방식이 필요한지에 초점을 두도록하십시오.

도서 추천에 대한 가장 좋은 추측은 다음과 같습니다.

스콧 차콘에 의해 프로 힘내 (쉽게 아마존 링크 ... 당신이 원하는 누구로부터 구입 : https://www.amazon.com/dp/1484200772/ref=cm_sw_r_cp_dp_T1_BNruzbBQ8G9A6 )

참고 : 마십시오 하지 힘내을위한 참고 도서를 구입할 수 있습니다. 그것은 전혀 도움이되지 않습니다.

내 경험상 일부 사람들은 git을 이해하지 않고 편안하게 사용할 수 있습니다. 그들은 기본 자습서를 찾고 기본 명령을 선택하여 잘 진행합니다. 그것은 아마도 당신이 주니어 컨설턴트가 적합한 곳일 것입니다. 나는 며칠 안에 실제로 자식을 배울 수 있다고 믿지 않습니다!

다른 사람들은 그것을 할 수 없으며, 자식이하는 일을 이해해야하며 더 많은 시간이 걸립니다. 나는 그 범주에있었습니다. 나는 .git디렉토리의 내용을 가지고 노는 것이 정말 도움이된다는 것을 알게되었습니다 . 또한 기술 담당자와의 일대일 세션이 도움이되었습니다.

사람들이 다르게 배우고 다른 부분에 대해 실제로 혼란 스러울 수 있기 때문에 하나의 튜토리얼에서 일대일로 할 수 있습니다. 한 세션에서 일대일로보고 이해하기가 더 쉽습니다. 그들이 git이 분기를 추적하는 방법을 이해하지 못한다는 사실에 정말로 신경 쓰면 .git디렉토리의 내용 등을 보여줍니다 .

나는 git(TFS 출신) 내가 어디 있는지 소개 하는 것과 관련이 있습니다. 특히 주제를 브로치 할 때 약간의 푸시 백이 있었기 때문에 귀하의 질문은 적시에 나에게 있습니다.

에서 피플웨어 (Peopleware) , 전체 책의 기본 논문은 다음과 같습니다

우리 작업의 주요 문제는 본질적 으로 사회 학적 기술 만큼 많지 않습니다 .

우리는 기술적 인 문제가 아니기 때문에 이것을 제기합니다. git약간의 애매하지만, 어리석은 사람이 아니면 당신이나 내 수석 개발자의 능력을 넘어서는 것이 아닐 것입니다.

기술적 인 기계가 아닌 사람들로서 개발자의 관점에서 살펴 보겠습니다.

당신은 그들에게 (아마도) 숙달 된 소스 제어 시스템을 사용하지 않는 시스템 제어 사용을 중단하라고 요구하고 있습니다. git전문가에게 사용을 중지 git하고 이동하도록 요청하는 svn것이 아닌가? 나는 git 전문가가 성가 시게 될 것이라고 생각하고 잘 작동 svn하기 때문에 많은 노력을 기울이지 않을 git것입니다. 그녀가 정말로 좋아하는 부분이 실제로하기가 어렵습니다 svn.

어쩌면 그들이 요령 없어 - 후배는 그에게 더 나은 촬영 한 이유는 아마 svn와 git^ 도랑 그들의 기회입니다.

노인은 비록주의입니다 기회 비용 - 그들은 배우면 git, 다음 그렇지 않은 :

• 학습 각도 / 반작용 / 스위프트 / Blockchain / 코 틀린 (그들이 느끼는 다른 일 해야 학습 할).
• DIY / 휘 슬링 / 세일링 /시 / glockenspiel / 실제로 하고 싶은 다른 일을합니다.
• 자녀 / 친척 / 친구 / 중요한 다른 사람들과 시간을 보냅니다.

• 이 "큰 새로운 것"을 제공-마감일, 예산 등이 있습니다. 아마도 걱정할 것입니다.

  "위의 모든 작업을 수행해야합니다. git 이미 소스 제어가있을 때 사용해야하는 이유는 무엇입니까?"

그들이 잘하는 것에서 새로운 것에 익숙하지 않은 것으로 바꾸고 다른 이유로 전환 한 이유는 무엇입니까? git기능 의 이점을 설명했습니까?

풀 요청? 세밀한 체크인? 분산 소스? 포크?

그들은 이런 이유들을 가져 왔습니까? 기술적 인 변화뿐만 아니라 문화적 측면에서도 중앙 집중식 소스 제어 마인드에있는 경우 이러한 구조적 변화는 방대하며 문화를 변화시키는 것이 얼마나 어려운지 잘 알고 있습니다.

따라서 기본적으로 개발자에게 무엇을 요구하는지 생각하고 올바른 이유인지 확인하십시오. svn어리 석고 늙어서 아무도 더 이상 잘 사용하지 않기 때문에 그렇게하고 싶다면 , 당신처럼 생각하지 않고 하루 종일 깨고 싶은 다른 사람들에게 판매하는 것이 더 어렵습니다. 팀과 프로젝트에 적합한 용어로 이점을 설명해야합니다. 그들이 git고통스러운 가치가 있다는 것에 동의하게 할 수 있다면 , 기술을 배우는 것에 대해 걱정할 필요가 없으며, 설정 한 워크 플로에 동의하는 것입니다.

행운을 빕니다.

나는 이것이 소프트웨어 공학 질문이 아니라 심리학 질문이라고 생각합니다. 을 참조하고 싶습니다 Algorithms to Live By: The Computer Science of Humand Decisions. 이 책에서 저자는 탐색 / 탐사 트레이드 오프 주제에 대해 설명합니다. 인간은 일반적으로 탐사 단계를 거친 다음 탐사 한 것을 악용 (사용)하는 단계를 거칩니다. 특정 간격으로 무언가를 최적으로 사용하기 위해 왜 그런지에 대한 확실한 수학적 이론이 있습니다.

이것은 또한 나이와 경험으로 확장됩니다. 인간은 자신의 삶을 간격으로보고 특정 탐색 단계 후에는 지식을 사용하는 것이 가장 좋습니다. 그들은 나이가 많은 참가자들에게 그들이 좋아하는 사람이나 가족을 만나기를 원하는지 묻는 연구를 인용했습니다. 그들은 일반적으로 가족을 선택했고, 젊은 사람들은 유명한 사람을 더 많이 선택했습니다. 그러나 20 세 이하의 나이를 어떻게 결정할 것인지 물었을 때 노인들도 일상적으로 유명한 사람을 선택했습니다. 이는 사람들이 자신이 이미 알고있는 것을 이용하는 것보다 탐험이 적다고 생각할 때 소셜 네트워크 구축을 중단한다는 것을 암시합니다.

선임 엔지니어는 아마도 나이가 많았으며 아마도 몇 가지 버전 제어 시스템을 겪었을 것입니다. SVN아마도 지금까지 사용했던 최고의 시스템 일 것입니다. (적어도 내가 사용했던 이전 버전 관리 시스템을 살펴보면 SVN이이 시스템을 모두 능가했습니다.)

그들의 최적의 전략은 SVN을 활용하는 것입니다. SVN은 탐험을 해왔으며 이것이 현재 최고의 것을 발견했기 때문입니다.

이것은 기본적인 인간 심리학이며, 당신이 싸우고있는 수십만 년의 진화 최적화입니다.

당신은 그들에게 a) 그들의 경력이 얼마나 오래 있는지, 그들이 보는 간격에 대해 다른 관점에서 생각하기 위해 프라이밍을해야하고, b) 그들이 어떻게 생각하는지와 그들이 무엇을 요구 하는지 물어봐야합니다. 에서 다시 누락되었습니다 SVN. 의 수백 가지 이점을 제공 할 수 git있지만 이전에는 SVN아마도 5 가지 버전 제어 시스템을 경험 한 후에도 왜 최상의 지 분명하게 알 수 있습니다. 당신은 그 주장의 갑옷에서 척을 찾아야하고 git, 그런 문제들을 해결할 수 있는지 알아봐야합니다 . 그러면 그들은 스스로 확신 할 것입니다.

Git을 사용하기위한 도구 나 GUI를 제공하지 마십시오. 혼동 될뿐입니다. 힘내 명령 줄에서 실행되도록 배웠으므로 아마도 배운 곳이되어야합니다. 모든 GUI에는 고유 한 용어와 특성이 있으며 간단한 것을 고수 할 수 있습니다.

다음은 Git이 SVN보다 나은 몇 가지 문제를 살펴 보는 것입니다. 팀이 그것을 배우게하려면 왜 git이 더 나은지 알아 보도록 동기를 부여해야합니다.

• 네트워크에 연결되지 않은 상태에서 커밋하는 기능
• 자신의 가지를 만들고 놀 수있는 능력
• 서로간에 전송되어 여전히 트랙을 병합 할 수있는 패치
• 고통없이 체리 따기.
• rebasing 변경
• 자식 접속으로 버그 찾기

나는 SVN이 지난 몇 년 동안 계속 움직였을 것이라고 확신했지만, 그것은 고통의 세계를 일으킬 수있는 것들이었습니다. 개발자들이이 새로운 도구가 단지 멋진 것이 아니라 작업에 대한 확실한 이점을 가지고 있다는 것을 알게되면, 그 도구가 뒤쳐 질 가능성이 더 높습니다.

배우는 것이 새롭고 혼란 스러울 수있는 유사성이 충분하지만 실제로 2017 년에 DCVS는 모든 개발자에게 필수적인 기술입니다.

걱정하지 말라고

Git에서 작업이 완료되면 잃는 것이 거의 불가능합니다. 쉽게 잃을 수있는 유일한 일은 아직 완결되지 않은 일입니다.

어떻게 git reflog작동 하는지 보여주세요 . 사용 방법을 몰라도됩니다. 그들은 단지 거기에 있다는 것을 알기 만하면 문제가 생길 경우 업무를 다시받을 수 있도록 도움을받을 수 있습니다.

그런 다음이 간단한 규칙 하나를 적용하십시오. 커밋은 나중에 (원격에서도 가능) 나중에 언제든지 되돌릴 수 있습니다.

GUI를 사용하지 마십시오

GUI를 사용하면 더 빨리 시작할 수 있지만 Git을 실제로 이해하지는 못합니다. 또한, Git GUI를 사용할 때 커밋 된 작업을 "잃을 가능성이 거의" 없다는 것을 알게되었습니다 . GUI가 병합에 체크리스트를 표시하는 것과 같은 끔찍한 일을 한 다음 사용자가 항목을 선택 취소하면 경고없이 기록에서 기록에서 파일을 지우십시오. GUI는 단순히 명령 줄 Git을 배우는 것보다 훨씬 나쁩니다.

페어 프로그램 코드 커밋

학습 git add -A과 학습 git commit이 너무 어려워서는 안되지만, 특히 리모컨과 병합 (또는 리베이스) 할 때는 도움이 필요합니다. 누구든지 언제든지 도움을 요청할 수 있음을 분명히하십시오. 명령을 입력하고 메모하는 동안 대기하십시오. 시간이 지남에 따라 도움없이 처리 할 수있는 상황의 수가 점차 늘어납니다.

힘내는 이미 안전하다

위의 누군가가 "놀이하기에 안전한 장소"에 대해 이야기했습니다. 그러나 Git 은 안전한 곳입니다. 직장을 잃기 쉬운 일상적인 경우는 두 가지뿐입니다.

• 커밋되지 않은 코드
• GUI 사용

그들이 조기에 자주 커밋 하고 GUI로 잘못된 경로를 시작 하지 않도록 하십시오. 곧 그들은 다른 소스 제어 시스템보다 코드로 Git을 신뢰할 수 있음을 곧 알게 될 것입니다.

나는 Gitless 를 살펴볼 것이다. 협업을 위해 기본 git 저장소를 유지하면서 기본 워크 플로우를 크게 단순화하는 git의 래퍼입니다 (스테이징 영역에 대해 걱정할 필요가 없으며, 브랜치가 파일의 작업 사본을 유지하고, 더 간단한 사용법을 git rebase처리하는 gl fuse등) 또는 비정상적인 일을해야하는 경우. 또한 메시지는 좀 더 초보자에게 친숙합니다. 그리고 명령은 어떤 이유로 든 시스템없이 시스템을 사용해야하는 경우 깃대 역할을하기에 충분합니다.

git의 명령 줄 사용법에 대한 기본 사항을 문서화하려고했습니다. Perforce와 Source Safe 사용 경험이있는 나 자신과 이전의 "관련 폴더 압축"패러다임을 선호하는 프로그래머들에게는 여전히 혼란 스러웠다. 불투명 한 툴이 내 작업 디렉토리의 내용을 수정하는 것이 걱정스럽고 종종 특정 변경 사항을 내 작업 디렉토리에 통합하기 위해 툴과 논쟁해야했습니다.

대신, 나는 두 종류의 간접 지시를 사용합니다.

• GitKraken을 사용하여 분기의 시각적 이력과 명령 줄 문을 숨기는 GUI를 제공합니다. GitKraken은 "origin"원격 저장소와 git이 로컬 작업 디렉토리라고 생각하는 것 사이의 상호 작용을 처리합니다.

• 또한 git이 로컬 작업 디렉토리라고 생각하는 것과 다른 "실제"로컬 작업 디렉토리를 유지합니다. 이 두 작업 디렉토리를 수동으로 동기화하므로 작업 디렉토리의 변경 사항이 내가 원하는 것보다 훨씬 편안합니다.

이 직원들이 Git을 배우도록 도울 수있는 방법이 있습니까?

문제가 Git이고 다른 것이 아니라고 확신합니까? 내가 의견에서 얻은 것은 경영진이 선임 기고자로부터 물건을 사지 않고 무언가를 변경하기로 결정하고 중년 누군가에게 변화를 추진하도록 지시한다는 것입니다. 그것은 변화를위한 실패의 출발점이 될 것 같습니다. 힘내 복잡성은 문제가 아니며, 문제는 그들이 필요하다고 느끼지 않는 변화가 그들에게 강요된다는 것입니다.

따라서 스위치를 사용할 때 발을 끌 수있는 장점이 없다면 Git을 가르치는 방법에 집중하지 마십시오. Git이 현재 가진 문제에 대한 해결책을 제시하십시오. Git이 아직 필요하지 않은 것을 제공 할 수있는 방법이 아니라 Git이 다른 사람들의 문제에 대한 해결책을 제공하는 방법이 아니라 Git이 현재 싸우고있는 문제를 해결하는 방법. 그런 다음 Git을 가르치는 것은 문제가되지 않습니다.

종종 Git은 회사에서 지점 문제를 해결하기 위해 사용됩니다. 그렇습니다. Subversion보다 분기에서 더 낫지 만 마술은 없습니다.

숙련 된 개발자가 많은 회사에서 근무하고있을 가능성이 높습니다.

• 경영진이 상충하는 요구를 결정하지 않기 때문에 지점을 만들었습니다.
• 구성 스위치 대신 각 고객에 대해 지점을 사용했습니다.
• 경영진이 모든 고객을 동일한 버전의 소프트웨어로 업그레이드 할 의사가 없기 때문에 각 고객에 대해 버그 수정 지점이 있어야했습니다.
• 기타.

따라서 일부 사람들은 도구가 좋은 브랜칭에 능숙하다고 말하자마자 나에게 말합니다.

경영진은 회사가 어떤 방향으로 가고 있는지 결정하기를 원치 않으며 101 개의 서로 다른 릴리스의 소프트웨어를 테스트해야하는 동시에 업무를 101 개의 다른 지점으로 병합해야했기 때문에 낭비하고 싶습니다.

또한 두 사람이 같은 파일을 동일하게 작업한다는 개념은“좋음”이며, 잘 진행된 프로젝트를 경험 한 사람에게는 받아 들일 수 없으므로 Git을 도구로 홍보하는 것은 경험이 없을 것입니다. 개발자가 좋아합니다.

Git에서 히스토리를 볼 때마다 논리적으로 공개되어서는 안되는 50 % 이상의 히스토리가 병합되어 코드가 개발자를 떠나 자마자 의미가 없어지기 때문에 코드가 왜 변경되었는지 알기가 매우 어렵습니다. 기계.

그러나 나는 어딘가에서 일하고 싶습니다 :

• 코드는 트러스트 서버에서 컴파일되고 단위 테스트 될 때까지 중앙 시스템에 들어 가지 않습니다.
• 코드 검토를 쉽게 추적 할 수있는 방법이 있습니다
• "get"을 할 때마다 코드는 항상 컴파일되고 작동합니다.
• 다른 사람과 경쟁하거나 사무실에서 길을 잃지 않고 변경 사항을 적용 할 수있는 곳.

따라서 실제 문제를 해결하고 Git이 숙련 된 개발자가 구매할 솔루션의 일부인 경우 "매직 병합"을 수행 할 수있는 멋진 장난감이기 때문에 Git을 좋아할 것으로 기대하지 마십시오.

따라서 개발자가 로컬 Git에서 중앙 Git으로 푸시 할 수있는 곳에서는 잘못되고 제어 된 자동 프로세스가 개발자의 변경 사항을 가져 와서 테스트 한 후 합병을 확인하는 것이 중앙 Git을 모두 업데이트합니다. 장기 관심이없는 지점 등.

Kiln ( http://www.fogcreek.com/fogbugz/devhub ) 또는“풀 요청”워크 플로우를 사용하는 GitHub도 숙련 된 개발자를 만족시킬 것입니다. 예를 들어 낮은 수준부터 시작하지 마십시오. 방법.