git 버전 제어 소프트웨어에 대한 이전 자습서에서 git 사용을위한 필수 기본 명령을 배웠습니다. Github.com과 함께 작업하여 리포지토리를 설정하고 웹 사이트에 프로젝트 코드를 푸시하는 방법도 있습니다.
이제 GitHub (및 git)를 원래의 방식대로 실제로 작업 할 차례입니다. 사용 : 프로젝트를 한쪽으로 안전하게 변경하고 올바른 것으로 판명되면 원래 프로젝트로 다시 병합합니다. 또는 적어도 재앙은 아닙니다.
지금 쯤이면 git이 프로젝트의 각 버전을 커밋 한 시점의 코드 스냅 샷으로 저장한다는 것을 이해합니다. 기본적으로 프로젝트가 진행됨에 따라 프로젝트 버전의 타임 라인을 생성하여 재해가 발생했을 때 이전 버전으로 롤백 할 수 있습니다.
git과 GitHub가이 타임 라인을 관리하는 방식, 특히 더 많은 경우 한 사람이 프로젝트에서 작업하고 변경하는 것보다 분기를 사용하는 것입니다. 분기는 본질적으로 고유 한 이름을 가진 고유 한 코드 변경 세트입니다. 각 저장소에는 하나 이상의 분기가있을 수 있습니다. 주 분기 — 모든 변경 사항이 결국 다시 병합되고 마스터라고하는 분기입니다. 이것은 프로젝트의 공식 작업 버전이며 github.com/yourname/projectname의 프로젝트 저장소를 방문 할 때 표시되는 버전입니다.
마스터를 건드리지 마십시오. 다른 사람들도 함께 작업하는 동안 그룹 프로젝트의 마스터 브랜치를 변경하면 즉석 변경 사항이 파급되어 다른 모든 사람에게 영향을 미치고 매우 빠르게 병합 충돌, 울음, 의복 찢김, 메뚜기의 전염병. 그렇게 심각합니다.
왜 스승은 엉망이되지 않는 것이 그렇게 중요한가요? 한마디로, 마스터 브랜치는 배포 가능합니다. 세계에 출시 할 준비가 된 프로덕션 코드입니다. 마스터 브랜치는 안정적이어야하며 테스트되지 않았거나 빌드를 깨뜨리는 것은 절대로 마스터에 푸시하지 않는 오픈 소스 소프트웨어의 사회적 계약입니다. GitHub가 작동하는 전체 이유는 항상 마스터에서 작업하는 것이 안전하기 때문입니다.
브랜치 아웃
대신 모든 사람이 마스터에서 만든 브랜치를 사용하여 실험, 편집, 추가 및 변경합니다. , 승인되고 작동하는 것으로 확인되면 결국 해당 분기를 마스터로 다시 롤링하기 전에. 그런 다음 Master는 모든 새로운 항목을 포함하도록 업데이트됩니다.
프로젝트에서 새로운 작업을 시작하거나 기존 항목을 변경하려면 안정된 마스터 분기에서 분기를 만듭니다. 이전 자습서 인 good ol’studious_octo_carnival을 위해 만든 샘플 프로젝트로 계속 작업하겠습니다. 이제 컴퓨터에서 버전을 열고 디렉토리로 이동하십시오.
1 단계 : 인벤토리 작성
새 브랜치를 만들기 전에 다른 기존 브랜치를 확인하고 싶습니다. . 우리는 마스터에 대해 알고 있지만 우리의 프로젝트 협력자가 그 장난 꾸러기 원숭이가 무엇인지 누가 압니까? 따라서 터미널에 “git branch -a”를 입력하여 기존 브랜치를 모두 볼 수 있습니다. 그러면 git에게이 프로젝트의 모든 브랜치 (로컬 작업 공간에없는 브랜치 포함)를보고 싶다고 알립니다.
그러면 아래 코드 예제에서 볼 수있는 출력이 반환됩니다. 모양은 OS 및 터미널 응용 프로그램에 따라 다소 다를 수 있지만 정보는 궁극적으로 동일합니다. 출력의 첫 번째 줄에서 “master”옆에있는 별표는 현재 그 지점에 있습니다. 두 번째 줄은 이름이 지정된 원격 오리진에 마스터라고도하는 단일 분기가 있음을 알려줍니다. (리모컨은이 프로젝트의 GitHub 저장소입니다.)
2 단계 : 새 브랜치 생성
이제 나뭇 가지를 보는 방법을 알았으니 나뭇 가지를 만들어 보겠습니다! 우리는 원래 프로젝트 인 마스터 브랜치를 가지고 있다는 것을 명심하십시오. 이제 프로젝트의 새 버전 인 브랜치를 만들어 컴퓨터에서 로컬로 작업하고 변경할 것입니다. 프로젝트의 원래 버전 인 마스터는 GitHub에서 안전하게 유지됩니다. 새 브랜치에서 작업하는 동안 수행 할 작업을 상기시키기 위해 설명이 포함 된 이름을 지정합니다. 이 경우 간단한 “Hello World”항목이 될 것이므로 hello_octo라고 부르겠습니다.
이 새 분기를 만들려면 “git checkout -b branchNameHere”를 입력합니다 (이 경우에는 “git checkout -b hello_octo”).
아무도 “hello_octo”라는 브랜치를 만들지 않았다고 가정하면 git은 “Switched to a new branch ‘hello_octo’를 반환합니다.” (해당 이름의 브랜치가 이미 존재하는 경우, git은 대신 “치명적 : ‘hello_octo’라는 브랜치가 이미 존재합니다.”라고 알려줍니다. 별다른 일이 아닙니다. 새 이름 변형으로 git checkout -b를 다시 수행하면됩니다.) / p>
또한 git checkout 명령을 사용하여 두 분기간에 앞뒤로 전환 할 수 있습니다. 해당 분기로 전환하려면 “git checkout branchName”을 입력하십시오.따라서 “git checkout master”는 마스터로 이동하고 “git checkout hello_octo”는 hello_octo 브랜치로 돌아갑니다.
“git checkout hello_kitty”와 같이 존재하지 않는 브랜치로 전환하려고하면 git은 해당 브랜치가 진행되지 않음을 알려줍니다.
git은 현재 어떤 분기에 있는지 어떻게 알 수 있습니까? Git은 항상 사용자가하는 일을 감시하고 HEAD라는 특수 포인터를 유지합니다. 나침반의 바늘이 항상 북쪽을 가리키는 것처럼 HEAD는 항상 현재 사용중인 로컬 브랜치입니다.
(git 명령 “git branch branchNameHere”를 사용하여 브랜치를 생성 한 다음 git checkout으로 전환 할 수도 있습니다. 그러나 “git checkout -b branchNameHere”의 “-b”는 모두 브랜치를 생성하고 전환합니다. 새로운 브랜치로 변경하는 것을 기억하지 못했기 때문에 얼마나 많은 git 코더가 오류 메시지와 좌절감을 생성하는지 말할 수 없습니다. 내가 만든 후 티. 따라서 우리는 git checkout -b, mmmkay?)를 고수하고 있습니다.
작업 브랜치 변경
이제 여러 브랜치 (변경할 작업 브랜치)가 있습니다. 우리의 마스터 브랜치는 무사히 안전하게 남아 있습니다. 우리는 일할 수 있습니다. 이 시나리오에서는 “hello_octo”분기를 사용하여 변경 사항을 만들고 테스트 한 다음이를 GitHub의 마스터 분기로 다시 푸시 할 것입니다.
마스터가 아닌 작업 브랜치, 좋은 오래된 git 브랜치 -a를 사용합니다.
3 단계. “hello_octo_world”라는 새 빈 파일을 만듭니다.
(이 빈 파일은 데모 용이므로 파일 확장자 이름 / 유형이 없어도 걱정할 필요가 없습니다.)
새로운 것이므로 맞습니다. 이제이 파일은 브랜치에만 있습니다. “ls”명령을 사용하여 확인하십시오.
그러나 우리는 작업 브랜치 인 hello_octo에 있습니다. 우리는이 새로운 것을 만들었습니다. 마스터는 hello_octo에 대해 아무것도 알지 못합니다. 왜냐하면 작업 브랜치에서 우리가 여기에서 만들고있는 임의의 변경 사항으로부터 안전하게 격리되어 있기 때문입니다.
4 단계 : 새 파일을 스테이징하고 작업 브랜치에 커밋합니다.
이제 시간입니다. 작업 브랜치에서 새 파일을 준비 (추가)하고 커밋합니다. (잘 들리나요?) 이렇게하면이 새 엔티티를 작업 브랜치에 연결하여 결국 마스터로 이동할 준비가됩니다.이 파일은 이제 hello_octo 브랜치에 있습니다. 위에서 살펴본 것처럼 현재 마스터 브랜치에 존재하지 않습니다.
이 시점에서 방금 지점에 대한 변경 사항의 스냅 샷입니다. 실제 프로젝트에서는 더 많은 변경 사항과 작업이있을 수 있습니다. 수행 할. 이제이 작업을 수행하여 논리적 지점에서 커밋을 수행합니다. GitHub에서 커밋은 연속 저장을 나타냅니다. 각 커밋에는 관련 커밋 메시지가 있습니다.이 메시지는 구체적으로 수행 한 작업과 이유를 설명하는 설명입니다. 커밋 메시지는 변경 내역을 캡처하므로 향후 다른 프로젝트 참여자뿐만 아니라 사용자가 수행 한 작업과 이유를 이해할 수 있습니다.
지점 간 코드 병합
일단 마침내 모든 변경과 추가가 완료되고 모든 것이 작동합니다 *. 이제 병합 할 때입니다. 흥미로운 부분은 마스터 브랜치로 다시 전환 한 후에 나타납니다. ( “git checkout master”로합니다.) “Hello_octo_world”가 누락 된 것처럼 보이지만 현재는 우리 작업에 존재합니다. 우리는 마스터 브랜치에 있습니다. git의 브랜치 이해의 핵심이므로 다시 보여 드리겠습니다.
지금 :이 실습에서 , “hello_octo_world”는 개발 브랜치에서 모든 테스트를 통과하고 프로덕션에 들어갈 준비가 된 모든 파일의 변경 (또는 완전히 새로운 파일 추가)을 나타냅니다. 브랜치간에 코드를 이동하는 프로세스 (종종 개발에서 production)을 병합이라고합니다.
매우 중요합니다. 병합 할 때 병합하려는 브랜치에 있어야합니다. 기본적으로 git에게 “새로운 것이 보이 시나요? 지금 여기로 가져와도됩니다.”
5 단계 : 작업 브랜치 변경 사항 병합
이 경우에는 작업 브랜치에서 병합하려고합니다. 여기서 “hello_octo_world” 파일이 존재하면 마스터 브랜치에 있어야합니다.
마스터 브랜치에서 병합 명령을 실행하면됩니다. 가장 좋은 방법은 “를 입력하는 것입니다. git merge –no-ff”— 추가 “–no-ff”는 git에게 병합 전에 모든 커밋 메시지를 유지하고 싶다는 것을 알려줍니다. 이렇게하면 향후 변경 사항을 더 쉽게 추적 할 수 있습니다.
GitHub로 돌아 가기
이제 마지막으로해야 할 일은 GitHub에 여기 우리의 지역 개발 환경에서 마스터하십시오.
즉, git push를 할 시간입니다. 맞았습니다!
git 출력은 개발 브랜치에서 로컬 환경의 마스터 브랜치로의 병합을 확인합니다. 이제 원격 서버에 복사되었습니다 : “master → master.”
그게 끝났습니다! 마스터와는 별개로 작업 브랜치를 성공적으로 만들었습니다. 변경 한 다음 변경 사항을 스테이징하고 커밋 한 다음 병합했습니다. 로컬 작업 환경에서 마스터로 돌아갑니다. 마지막으로 모든 프로젝트를 GitHub로 푸시하여 모든 버전의 프로젝트가 어디서나 동일합니다!
최종 참고 사항
일부 정리 이제 순서대로입니다 : hello_octo 브랜치를 성공적으로 병합 했으므로 더 이상 필요하지 않습니다. 병합 된 브랜치를 삭제하려면 “git branch -d branchName”을 입력하면됩니다.
걱정하지 마세요. 아직 병합되지 않은 브랜치를 실수로 삭제하려고하면 git에서 오류가 발생합니다.
그래서! 지금까지 우리는 매우 단순화 된 샘플 프로젝트를 사용했습니다.이 시점에서 가장 중요한 것은 git 워크 플로우를 이해하고 동화하는 것입니다. 실제 세계에서는 병합에 이보다 더 많은 것이 있습니다. 예를 들어 병합에 충돌이있어 오류 메시지가 표시되면 어떻게됩니까? 걱정 마세요, 새로운 git-ster, 우리는 거기에 도달 할 것입니다.
당신의 숙제 : 예제 프로젝트에서 더 많은 새로운 파일을 만들고 ( “터치”) 변경하고, 스테이징하고, 커밋하고, 마지막으로 병합하는 연습을하십시오. HEAD가 가리키는 위치, 즉 현재 브랜치가 무엇인지 이해하도록주의하십시오. 작업 브랜치에만 변경 사항을 커밋하십시오.
왜냐하면 기억하십시오 :하지 마십시오. .