Git 및 GitHub 사용자를위한 27 가지 필수 팁

Git 사용자는 선택할 수있는 시작 가이드가 수십 개 있고 GitHub는 자체 가이드를 많이 제공하지만 Git 및 GitHub로 더 스마트하게 작업하려는 개발자를위한 유용한 팁 모음을 찾는 것은 여전히 ​​쉽지 않습니다. 수정하겠습니다.

Git 또는 GitHub에 익숙하지 않은 분들을 위해 다음 몇 개의 단락에서 팁을 이해하기에 충분한 배경 ​​지식을 제공합니다. 이 기사의 끝에는 약 12 ​​개의 유용한 리소스가 나열됩니다.

Git은 원래 Linus Torvalds가 2005 년에 Linux 커널 커뮤니티의 도움을 받아 작성한 분산 버전 제어 시스템입니다. 나는 Git에서 당신을 팔기 위해 여기있는 것이 아니기 때문에 그것이 얼마나 빠르고 작고 유연하며 인기가 있는지에 대해 이야기 할 것입니다. 그러나 당신은 당신이 Git 저장소를 복제 할 때 알고 있어야합니다 (줄여서“repo”) , 한 번에 한 지점의 스냅 샷뿐만 아니라 자신의 컴퓨터에서 전체 버전 기록을 얻을 수 있습니다.

Git은 Linux 커널 커뮤니티의 기원에 걸맞게 명령 줄 도구로 시작되었습니다. 원하는 경우 Git 명령 줄을 계속 사용할 수 있지만 그럴 필요는 없습니다. 특히 GitHub를 호스트로 사용하는 경우 Windows 또는 Mac에서 무료 GitHub 데스크톱 클라이언트를 사용할 수 있습니다. 반면 Git 명령 줄은 모든 호스트에서 작동하며 대부분의 Mac 및 Linux 시스템에 사전 설치되어 제공됩니다.

명령 줄을 사용하는 것이 가장 편한지 아니면 그래픽 사용자 인터페이스가있는 기본 클라이언트를 사용하는 것이 가장 편한지를 결정할 수 있습니다. GUI를 좋아한다면 GitHub 클라이언트 (Windows 및 Mac) 외에도 SourceTree (Windows 및 Mac, 무료), TortoiseGit (Windows 전용, 무료) 및 Gitbox (Mac 전용, $ 14.99)를 고려할 수 있습니다. 또는 내부적으로 Git을 지원하는 편집기 또는 IDE를 사용할 수 있습니다 (팁 번호 11 참조).

Git / GitHub 팁 1 : 거의 모든 것을 복제

자신의 컴퓨터에 자유롭게 복제 할 수있는 GitHub 및 기타 공용 Git 리포지토리에서 사용할 수있는 흥미로운 프로젝트가 많이 있습니다. 왜 그렇게 하시겠습니까? 한 가지 이유는 커밋 로그 주석 스타일을 포함하여 관심 언어의 코딩 스타일, 연습 및 도구에 대해 배우기위한 것입니다 (팁 4 번 참조). 두 번째 이유는 주어진 프로젝트가 목표를 달성하는 방법을 배우는 것입니다. 세 번째 이유는 라이선스가 허용하고 목적에 맞는 경우 프로젝트를 자신의 노력이나 제품에 통합하는 것입니다. 그런데 나중에 규정 준수 문제가 발생하지 않도록 라이선스를 다시 확인하십시오.

git clone매뉴얼 페이지에서 정의 :

저장소를 새로 생성 된 디렉토리에 복제하고, 복제 된 저장소의 각 분기에 대한 원격 추적 분기를 git branch -r생성하고 (를 사용하여 표시됨), 복제 된 저장소의 현재 활성 분기에서 분기 된 초기 분기를 생성 및 체크 아웃합니다.

복제 후 git fetch인수가없는 일반 은 모든 원격 추적 분기를 업데이트하고 git pull인수가없는 경우 추가로 원격 마스터 분기를 현재 마스터 분기 (있는 경우)에 병합합니다.

Git / GitHub 팁 2 : 자주 당기기

Git (그리고 실제로 모든 버전 제어 시스템에서)을 엉망으로 만드는 가장 쉬운 방법 중 하나는 파일이 동기화되지 않도록하는 것입니다. git pull자주 사용하는 경우 리포지토리 사본을 최신 상태로 유지하고 변경된 코드를 다른 사람의 변경 사항과 병합 할 수있는 기회를 갖게되며 병합은 이해하고 수행하기 쉽습니다. 자동으로 수행됩니다. 이 팁의 결과는 프로젝트 상태를 관찰하는 것입니다. 많은 Git 클라이언트는 최신 상태를 유지하기 위해 업데이트해야 할 때 자동으로 표시합니다.

Git / GitHub 팁 3 : 조기 및 자주 커밋

커밋은 프로젝트에 대한 세부적인 업데이트로, 하나 이상의 파일에 대한 하나 이상의 변경 사항을 포함합니다. 완료된 작업 단위의 기록으로 생각하면 논리적 전체로서 프로젝트에 적용하거나 제거 할 수 있습니다. 테스트하기 전에도 완료 한 모든 논리적 변경 사항을 커밋하십시오. 커밋은 로컬 저장소에만 적용됩니다. 이 팁의 결과에 대해서는 팁 4와 5를 참조하십시오.

git commit매뉴얼 페이지에서 정의 :

변경 사항을 설명하는 사용자의 로그 메시지와 함께 인덱스의 현재 내용을 새 커밋에 저장합니다.

Git / GitHub 팁 4 : 다른 사람이 댓글을 달게하는 것처럼 커밋에 댓글을 달아주세요.

코더에는 10 가지 종류가 있습니다. 커밋을 주석 처리하는 사람과 그렇지 않은 사람입니다. (오래된 농담. 힌트 : 내가 사용하는베이스는 무엇입니까?)

나는 좋은 커밋 로그 메시지에 대해 고집을 부리는 것을 자유롭게 인정합니다. 모든 커밋에 대해 메시지를 요구하도록 리포지토리를 설정했으며 커밋이 "xx"순서로 로그와 함께 도착하면 성가신 심야 메시지를 보내는 것으로 알려져 있습니다. (1) 코드가 스스로를 말해야하고 (2) 인라인 주석이 변경 로그보다 훨씬 더 중요하다고 생각하는 개발자라면 이전에 본 적이없는 저장소를 복제하고 모든 코드를 읽지 않고 게시 된 최신 문제를 일으킨 최근 커밋. 보시다시피 정확한 커밋 로그는 두 배로 좋습니다.

Git / GitHub 팁 5 : 변경 사항을 테스트 할 때 푸시

내가 아는 불행한 최악의 Git 관련 버그는 아웃소싱 회사가 Subversion에서 전환했지만 분산 소스 제어와 중앙 집중식 소스 제어의 차이점에 대해 개발자를 교육하지 않았을 때 발생했습니다. 약 한 달 후,이 프로젝트는 아무도 추적 할 수없는 이상한 버그를 개발했습니다. 매일 스탠드 업 회의에서 오작동하는 애플리케이션 영역을 담당하는 개발자는 "2 주 전에 고쳤습니다!"라고 항의했습니다. 또는 다른 개발자가주의 깊게 확인한 변경 사항을 가져 오지 않는다고 비난합니다.

결국 누군가가 문제를 식별하고 모든 개발자 push에게 커밋 방법과시기를 가르쳤습니다 . 간단히 말해서 커밋이 로컬 빌드에서 성공적으로 테스트 될 때마다. 그런 다음이 회사는 업데이트 된 통합 제품을 구축하고 배포하기 전에 이틀 동안 합병 축제를 열었습니다.

Git / GitHub 팁 6 : 자유롭게 분기

Git이 다른 버전 제어 시스템에 비해 가장 큰 장점 중 하나는 병합이 일반적으로 잘 작동한다는 것입니다. 적어도 부분적으로는 Git이 병합에 사용할 가장 좋은 공통 조상을 자동으로 선택하기 때문입니다. 대부분의 소프트웨어 개발자는 프로젝트에서 브랜치를 더 자주 생성해야합니다. 고뇌에 찬 모든 손을 대는 전략 회의의 주제가 아닌 일상적인 일이어야합니다. 가능성은 브랜치 프로젝트가 완료되고 승인되어 주 프로젝트로 이동할 준비가되었을 때 병합으로 인해 극복 할 수없는 문제가 발생하지 않을 것입니다.

특히 CVS로 소스 코드 제어를 수행하는 회사에 갇혀 있다면 조정이 필요하다는 것을 알고 있습니다. 그러나 그것을 시도하십시오. 크래킹 버그로 인해 트렁크 프로젝트를 게시해야 할 때 고객이 실수로 완료되지 않은 실험 코드를 보게하는 것보다 훨씬 낫습니다. (이 기사에서는 기본 분기 및 병합에 대해 잘 설명합니다.)

Git / GitHub 팁 7 : 신중하게 병합

Git과의 병합은 일반적으로 잘 작동하지만 생각없이 수행하면 때때로 어려움이 발생할 수 있습니다. 1 단계는 커밋되지 않은 변경 사항이 없는지 확인하는 것입니다. 로부터 git merge매뉴얼 페이지 :

외부 변경 사항을 적용하기 전에 자신의 작업을 양호한 상태로 만들고 로컬로 커밋해야 충돌이 발생해도 방해받지 않습니다. 을 (를) 참조하십시오 git-stash.

8 번 팁도 참조하십시오.

에서 모든 것이 남쪽으로 이동하더라도 git merge호스에 얽매이지 않습니다.

복잡한 충돌을 초래 한 병합을 시도하고 다시 시작하려는 경우 git merge —abort.

후속 명령 git merge은 일반적으로 git mergetool병합을 위해 GUI를 사용한다고 가정합니다. 구식 방법을 선호하는 경우 선호하는 프로그래밍 편집기와 충돌하는 파일을 편집하고 ,, 및 행을 완전히 제거하고 <<<<<<<, 수정 된 파일과 수정 한 각 파일을 저장할 수 있습니다.=======>>>>>>>git add

Git / GitHub 팁 No. 8 : 분기 전환 전 숨김

소프트웨어 개발자의 워크 플로는 거의 선형 적이 지 않습니다. 사용자는 버그를보고 할 수 있고 관리자는 작업하기 위해 선택한 티켓 이외의 티켓의 우선 순위를 정할 수 있으며 자신이 원하는 작업에 대한 마음을 바꿀 수 있습니다.

릴리스를 위해 커밋 된 세 개의 파일과 변경되었지만 작동하지 않는 상태의 네 번째 파일이 있습니다. ( git status어디에 있었는지 기억 나지 않는 경우 명령이이 모든 것을 알려줍니다.) 갑자기 프로덕션 버전에서 버그 수정 작업을해야합니다. 분기를 빠르게 전환해야하지만 할 수 없습니다. 작업 디렉토리가 더럽고 잃고 싶지 않은 작업 시간이 2 시간입니다.

를 입력하십시오 git stash. Voilà! 이제 모든 변경 사항이 WIP (진행중인 작업) 브랜치에 저장되었으며 깨끗한 디렉토리에서 프로덕션 브랜치로 전환 할 수 있습니다. 이 작업을 마치면 git stash apply.

Git / GitHub 팁 9 : 요점을 사용하여 스 니펫 및 붙여 넣기 공유

GitHub "gists"(공유 코드 스 니펫)는 Git 기능이 아니지만 Git을 사용합니다. 모든 요점은 Git 저장소이며 GitHub Gist를 사용하면 쉽게 공유 할 수 있습니다. 주제, 프로그래밍 언어, 분기 된 상태 및 별표 표시된 상태별로 Gist에서 공개 요점을 검색 할 수 있습니다. 비밀 요점을 만들고 URL로 공유 할 수도 있습니다.

Git / GitHub 팁 10 : GitHub 살펴보기

많은 흥미로운 오픈 소스 프로젝트에는 GitHub에 저장소가 있습니다. Explore GitHub는 일부를 찾을 수있는 브라우징 인터페이스를 제공하지만 대부분 검색 상자에 프로젝트 이름의 몇 글자를 입력하여 저장소를 찾는 것이 더 쉽습니다. 예를 들어, 입력 jq하거나 back또는 ang주요 오픈 소스 자바 스크립트 프레임 워크의 세 가지를 찾을 수 있습니다.

Git / GitHub 팁 11 : 오픈 소스 프로젝트에 기여

오픈 소스 프로젝트를 탐색하는 한 기여하지 않으시겠습니까? 생각만큼 어렵지 않으며 많은 것을 배울 것입니다. 예를 들어 jquery / jquery (jQuery Core) 프로젝트를 복제하고 README.MD를 통해 찾아 볼 수 있습니다. 상단 근처에 다음이 표시됩니다.

오픈 소스 소프트웨어 개발의 정신에 따라 jQuery는 항상 커뮤니티 코드 기여를 장려합니다. 시작하는 데 도움이되고 코드 작성을 시작하기 전에이 중요한 기여 지침을 철저히 읽으십시오.

그 뒤에 세 개의 링크가 있습니다. 세 가지 중 첫 번째는 매우 빠르게 시작할 수 있도록합니다. 모든 오픈 소스 프로젝트가 계획을 명확하게 설명하는 것은 아니지만 모두 시도합니다.

기여자와 커미터의 차이점을 이해하십시오. 기여자가 필요한 계약에 서명하고 프로젝트에 기여할 수 있도록했습니다. 커미터는 제안 된 기여를 프로젝트 저장소에 실제로 커밋 할 권한이 있습니다. 커미터가 여러분의 기여를 테스트하는 동안 지연이있을 것이고 여러분은 마스터 브랜치를 묶고 싶지 않을 것이므로 풀 요청을 보내기 전에 다른 브랜치 (팁 6 번 참조)에서 변경해야합니다 (팁 번호 참조). 16).