Git 소개

게시 됨: 2022-06-30

새로운 웹사이트를 구축하거나, 테마 또는 플러그인을 개발하거나, 고급 지속적 통합 및 배포 전략을 설정하는 경우에 상관없이 코드 작업을 하게 될 것입니다.

WordPress, WooCommerce, Drupal, Magento, NextJS 또는 손으로 코딩한 HTML을 사용하든 모든 웹사이트에는 실행 중인 코드가 있습니다. 각 페이지를 렌더링하고 콘텐츠를 세상에 표시하는 데 필요한 파일 세트가 있습니다.

시간이 지남에 따라 코드 변경 사항을 추적하는 방법이 필요하다는 사실을 빠르게 발견할 수 있습니다. 모든 파일의 최신 버전에 어떤 변경 사항이 있으며 누가 각 변경 사항을 적용했는지 알아야 합니다.

Git이 필요한 이유

Git 이해하기

Git은 개발자 및 파일 작업을 하는 모든 사람이 변경 사항의 버전을 쉽게 생성 및 저장하고, 변경 내역을 보고, 장치와 시스템 간에 변경 사항을 공유할 수 있는 버전 제어 시스템입니다. 문제가 발생하는 경우 변경 사항을 실행 취소합니다.

짧은 역사

2005년으로 거슬러 올라가면 개발자 팀이 무료 오픈 소스 운영 체제인 Linux라는 프로젝트를 만들고 있었습니다. 그들은 수백 명의 기여자들 사이에 변경 사항을 쉽게 전달할 수 있는 방법이 필요했습니다. 원래 그들은 업데이트된 코드가 포함된 개별 패치를 전달했지만, 특히 특정 변경 세트의 "진정한" 버전과 최신 버전을 결정할 때 많은 면에서 문제가 있는 것으로 나타났습니다.

이러한 문제에 좌절한 Linux 프로젝트는 Linus Torvald가 개발자 간에 전체 코드베이스를 공유하고 커밋이라고 하는 변경 사항의 "스냅샷"을 만드는 프로젝트에 대한 다소 참신한 아이디어를 구현하도록 했습니다. 전 세계 어디에서나 사용할 수 있는 코드입니다. 모든 프로젝트 변경 사항을 단일 기록으로 볼 수 있기 때문에 즉시 커뮤니케이션에 도움이 되었습니다.

이러한 스냅샷을 캡처하는 방법은 Git입니다. 이 도구는 신속하게 자체적인 생명을 얻었고 그 이후로 Linux 프로젝트와 독립적으로 개발되었습니다.

변화의 그래프

개념적으로 Git은 각 노드가 특정 시점의 전체 프로젝트 스냅샷인 노드의 그래프로 생각할 수 있습니다. git-scm.com에 있는 Git 책은 스냅샷의 구조를 설명합니다.

이 스냅샷 체인은 가장 최근 버전이 맨 앞 또는 변경 기록 맨 위에 오도록 시간 경과에 따른 그래프를 작성합니다. 각 스냅샷은 Git에서 "커밋"이라고 합니다.

가장 최근 변경 사항을 그래프 상단에 배치하면 Git 프로젝트가 어떻게 보이는지 간단히 살펴보겠습니다. 참고 - 이 예제는 GitKraken Git GUI를 사용하여 그래프를 시각화합니다.

Git 그래프 작성

Git은 변경 사항을 커밋하는 프로세스를 통해 Git 기록이라고도 하는 이 변경 사항 그래프를 작성합니다. 그러나 변경 사항을 커밋하기 전에 해당 스냅샷에 추가할 항목을 Git에 구체적으로 알려주거나 Git에서 올바르게 참조되는 커밋을 수행해야 합니다.

로컬에서 작업할 때 프로젝트에 저장하는 모든 변경 사항은 "작업 디렉토리"에 있습니다. Git은 이러한 변경 사항을 볼 수 있지만 커밋하려는 변경 사항을 아직 모릅니다. "git add"라는 명령을 사용하여 특정 파일을 Git의 "스테이징 영역"에 추가하여 커밋할 변경 사항을 Git에 명시적으로 알려야 합니다.

프로젝트 스냅샷의 그래프에 커밋하려는 파일 변경 사항이 있으면 "Git commit" 명령을 사용하여 해당 스냅샷을 그래프에 영구적으로 빌드할 수 있습니다.

과거로의 이동

Git의 장점 중 하나와 전체 프로젝트 기록을 사용할 수 있는 것은 언제든지 뒤로 이동하고 모든 변경 사항을 취소할 수 있다는 것입니다.

마지막 커밋으로 인해 무언가가 중단되거나 수행한 작업에 대해 마음이 바뀌면 "Git revert"를 수행하여 Git 커밋을 되돌릴 수 있습니다. 이렇게 하면 방금 변경한 내용을 실행 취소하는 새 커밋이 그래프에 생성됩니다.

시간을 되돌려 커밋하지 않은 것처럼 보이게 하려면 "Git reset"을 사용하면 됩니다.

Git에서 분기 및 병합의 힘

Git이 우리에게 제공하는 가장 강력한 기능 중 하나는 병렬 대체 현실을 생성하는 기능입니다. 아니, 정말.

시간 경과에 따른 커밋 그래프를 만들고 있으므로 기록의 어느 지점에서나 분기라고 하는 커밋의 평행선을 만들도록 선택할 수 있습니다. 새로 생성된 Git 브랜치는 기본 기록과 무관합니다. 즉, 원하는 대로 자유롭게 변경할 수 있으며 다른 작업에는 영향을 미치지 않습니다. 기본 타임라인은 분기이기도 하며 가장 일반적으로 "메인" 또는 "마스터" 분기라고 합니다. 새로운 브랜치와 메인 이외의 브랜치는 일반적으로 "기능 브랜치"라고 합니다.

기능 분기를 변경했으면 Git 병합을 수행하여 모든 변경 사항을 기본 분기에 적용할 수 있습니다.

이런 식으로 작업하면 큰 이점이 있습니다. 기능 분기는 코드 변경 사항을 격리하므로 오류가 발생하더라도 기본 분기가 안전하다고 안심할 수 있습니다. 브랜치에서 작업하면 진행 중인 개발 작업을 중단하지 않고 업데이트 또는 보안 수정 사항을 적용해야 하는 경우에 대비하여 기본 브랜치를 확보할 수 있습니다.

Git 병합을 사용하면 기본 분기에서 기능 분기로 변경 사항을 가져올 수도 있습니다. 이를 통해 "main"과 병합을 시도하기 전에 기본 분기에 대한 업데이트가 제안된 변경 사항과 계속 작동하는지 확인할 수 있습니다.

팀과 함께 작업하는 경우 Git 분기 전략을 사용하면 팀에서 변경 사항을 프로덕션에 적용하기 전에 철저히 테스트하고 프로세스를 관리하는 간단한 방법을 제공할 수 있습니다.

Git에서 원격 리포지토리 작업

Git의 주요 목표 중 하나는 전 세계 사람들과 코드를 쉽게 공유할 수 있도록 하는 것입니다. Git에 내장된 것은 원격 저장소의 개념입니다.

Git 리포지토리는 작업을 저장하고 시간이 지남에 따라 Git이 추적하는 전체 프로젝트 폴더입니다. 각 리포지토리는 Git clone 명령을 사용하여 복제할 수 있고 무제한으로 공유할 수 있으므로 Git을 매우 확장할 수 있습니다.

Git의 확장성을 높이는 또 다른 측면은 문서를 변경할 경우 해당 문서의 완전히 새로운 복사본을 저장할 필요가 없다는 것입니다. 변경 사항은 "델타"라고 하는 작은 정보 패킷으로 저장되며 개별적으로 수정된 파일 행과 변경 사항에 대한 약간의 데이터만 Git이 저장하거나 공유해야 하는 것입니다. Delta는 매우 가볍고 크기가 몇 바이트에 불과합니다. 예를 들어 100KB 문서에서 한 줄을 변경하면 델타는 20바이트 정도만 됩니다.

모든 것을 리포지토리의 모든 복사본에서 일관되게 유지하려면 어떤 컴퓨터에 있는 어떤 복사본이 프로젝트의 "진정한" 복사본인지 지정한 다음 커밋이 해당 복사본에 적용되는지 확인하기만 하면 됩니다.

이것은 다른 방식으로도 작동합니다. 다른 사람과 공동 작업할 때 변경 사항을 저장소의 로컬 복사본으로 가져와 프로젝트의 로컬 복사본이 최신 상태인지 확인할 수 있습니다.

원격 리포지토리에서 공동 작업을 매우 간단하고 관리하기 쉽게 만드는 회사가 많이 있습니다. GitHub, GitLab 및 BitBucket과 같은 플랫폼은 온라인 Git 리포지토리 호스팅 및 협업 도구를 제공합니다. 수백만 명의 개발자가 관리하는 수백만 개의 Git 리포지토리가 온라인에 있으며 Git은 얼마나 많은 사람들이 협력하는지에 관계없이 모든 단일 소스를 추적합니다.

Git에 저장하지 말아야 할 것

Git으로 하지 말아야 할 일에 대해 이야기해 봅시다. Git은 코드를 공유하고 시간이 지남에 따라 변경 사항을 추적하는 데 탁월하지만 모델에 적합하지 않은 일부 작업이 있습니다. 다행히 Git은 ".gitignore" 파일이라는 항목을 무시하도록 지시하는 편리한 방법을 제공합니다.

".gitiginore" 파일이 있는 경우 Git은 해당 항목을 전혀 감시해야 하는지 확인하기 위해 파일을 검사합니다. ".gitiginore" 안에 개별 파일 이름, 전체 디렉토리 또는 전체 유형의 파일을 나열할 수 있습니다. 예를 들어, 모든 .png 및 .jpg 파일과 전체 "wp-content/uploads" 폴더를 제외하려면 ".gitiginore" 파일에서 다음과 같이 작성하면 됩니다.

 *.png *.jpg wp-content/uploads

Git에서 미디어 파일을 제외하는 이유는 무엇입니까?

Git은 프로젝트의 스냅샷을 저장하고 "델타"만 전달합니다. 그러나 문제의 파일이 이미지, 비디오 또는 기타 이진 파일과 같은 데이터 "블롭"인 경우 파일을 변경할 때마다 완전히 새로운 데이터 덩어리가 생성됩니다. 그런 다음 Git은 이전 blob과 새 blob의 상태를 모두 기억해야 하므로 저장소에 불필요한 크기를 많이 추가합니다. 이것은 시간이 지남에 따라 쌓이고 Git의 가벼운 이점을 잃음에 따라 리포지토리는 곧 다루기 어려워집니다.

믿거 나 말거나 WordPress 코어 자체의 변경 사항을 추적하고 싶지 않을 수 있습니다. 여기에는 몇 가지 이유가 있습니다.

첫째, 모든 CMS에는 "핵심을 해킹하지 마십시오!"라는 오래된 속담이 있습니다. 추적해야 하는 WordPress의 핵심에서 변경하는 것이 없어야 합니다. 모든 업데이트는 WordPress 자체에서 가져와야 하며 이전 버전을 원하는 경우 설치할 때 쉽게 지정할 수 있습니다. 전체 WordPress 설치를 Git에 절대적으로 저장할 수 있지만 특정 상황에서는 그렇게 하는 것이 별로 가치가 없습니다. 사용자 정의 플러그인 및 하위 테마와 같이 조작 중인 코드의 변경 사항만 추적하고 싶을 것입니다. 이 주제에 대한 조언은 호스팅 제공업체에 문의하는 것이 좋습니다.

둘째, WordPress에 다시 기여할 계획이라면 실제로 SVN이라는 이전 버전 제어 시스템을 통해 유지 관리된다는 것을 알게 될 것입니다. 이 모델은 중앙 서버 인프라가 필요하고 Git에 비해 덜 인기가 있지만 WordPress는 Git보다 오래되었습니다. SVN 패치 시스템으로 작업하는 것은 약간 다르며 이에 대한 자세한 내용은 해당 문서를 참조해야 합니다.

결론

이제 Git이 무엇이며 웹사이트의 코드 작업에 어떻게 활용할 수 있는지 더 잘 이해하셨기를 바랍니다. Git은 컴퓨터 코드가 아니더라도 시간이 지남에 따라 변경하는 모든 파일에 사용할 수 있습니다.

Git은 대상 사용자를 IBM에서 빌린 오래된 용어인 "지식 근로자"라고 부릅니다. 바탕 화면의 메모부터 레시피, 책 전체에 이르기까지 모든 것에 대해 Git은 작업을 더 잘 정리하고 왜 각 변경을 했는지, 언제 변경했는지에 대한 확실한 흔적을 남길 수 있는 방법을 제공합니다.

시간을 거슬러 올라가 변경 사항을 볼 수 있는 능력과 분기 및 병합을 통해 무제한 병렬 우주에서 작업할 수 있는 기능이 결합되어 Git은 코드 작업을 하는 모든 사람에게 없어서는 안될 도구입니다. Git은 또한 팀이 코드 프로젝트에서 협업하는 주요 방법입니다.

Git은 무료이며 GitKraken과 같은 대부분의 Git GUI에는 무료 버전이 있습니다. Git을 사용하여 작업을 추적하지 말아야 할 이유가 없으므로 "Git"하십시오!