git 분기 관리동력 노드 자바 대학 정리

가 지 는 바로 공상 과학 영화 속 의 평행 우주 이다.컴퓨터 앞에서 Git 을 열심히 공부 하고 있 을 때 다른 하 나 는 다른 평행 우주 에서 SVN 을 열심히 공부 하고 있다.
만약 두 평행 우주 가 서로 간섭 하지 않 는 다 면,그것 은 현재 의 너 에 게 도 아무런 영향 이 없다.그러나 어느 시점 에 두 평행 우주 가 합 쳐 졌 습 니 다.결국 Git 도 배 웠 고 SVN 도 배 웠 습 니 다!

가 지 는 실제 에서 무슨 소 용이 있 습 니까?만약 당신 이 새로운 기능 을 개발 하려 고 한다 면 2 주일 이 걸 려 야 완성 할 수 있 습 니 다.첫 주 에 50%의 코드 를 썼 습 니 다.만약 에 바로 제출 하면 코드 가 아직 다 쓰 지 않 았 기 때문에 불완전한 코드 라 이브 러 리 는 다른 사람 이 일 을 할 수 없 게 될 것 입 니 다.코드 를 모두 쓰 고 다시 제출 하면 매일 진 도 를 잃 을 위험 이 크다.
지금 가지 가 생 겼 으 니 두려워 할 필요 가 없다.당신 은 자신 만 의 가 지 를 만 들 었 습 니 다.다른 사람 이 볼 수 없 을 때 까지 원래 의 가지 에서 정상적으로 일 하고 있 습 니 다.당신 은 자신의 가지 에서 일 하고 제출 하고 싶 으 면 제출 합 니 다.개발 이 끝 난 후에 다시 한 번 원래 의 가지 에 합병 하면 안전 할 뿐만 아니 라 다른 사람의 업무 에 도 영향 을 주지 않 습 니 다.
다른 버 전 관리 시스템,예 를 들 어 SVN 등 은 모두 분기 관리 가 있 지만 사용 한 후에 이런 버 전 관리 시스템 의 생 성과 전환 분기 가 달팽이 보다 더 느 려 서 참 을 수 없 었 다.그 결과 분기 기능 이 장식 이 되 어 모두 가 사용 하지 않 았 다.
하지만 Git 의 가 지 는 남 다 릅 니 다.가 지 를 만 들 거나 전환 하거나 삭제 하 더 라 도 Git 은 1 초 안에 완성 할 수 있 습 니 다!버 전 라 이브 러 리 가 파일 이 든 만 개의 파일 이 든
분기 생 성 및 병합
제출 할 때마다 Git 은 타임 라인 으로 연결 합 니 다.이 타임 라인 은 하나의 갈래 입 니 다.지금까지 하나의 타임 라인 만 있 습 니 다.Git 에서 이 가 지 는 메 인 분기,즉 master 분기 라 고 합 니 다.HEAD 엄 밀 히 말 하면 제출 을 가리 키 는 것 이 아니 라 master 을 가리 키 는 것 이 고 master 이 야 말로 제출 을 가리 키 는 것 이기 때문에 HEAD 이 가리 키 는 것 은 현재 지점 이다.
처음에 master 가 지 는 하나의 선 이 었 습 니 다.Git 은 master 으로 최신 제출 을 가리 키 고 HEAD 으로 master 을 가리 키 면 현재 분기 와 현재 분기 의 제출 점 을 확인 할 수 있 습 니 다.

제출 할 때마다 master 가 지 는 앞으로 한 걸음 이동 합 니 다.그러면 서 계속 제출 하면 서 master 가 지 는 점점 길 어 집 니 다.
우리 가 새로운 가 지 를 만 들 었 을 때,예 를 들 어 dev 을 만 들 었 을 때 Git 은 dev 이라는 지침 을 새로 만 들 었 습 니 다.master 과 같은 제출 을 가리 키 고 HEAD 을 dev 으로 가리 키 면 현재 가 지 는 dev 에 있 음 을 나타 냅 니 다.

보 세 요.Git 에서 가 지 를 만 드 는 것 은 매우 빠 릅 니 다.dev 지침 을 추가 하 는 것 을 제외 하고 HEAD 의 방향 을 바 꾸 는 것 은 작업 지역 의 파일 에 아무런 변화 가 없 기 때 문 입 니 다!
그러나 지금부터 작업 구역 에 대한 수정 과 제출 은 dev 가지 입 니 다.예 를 들 어 새로 제출 한 후에 dev 포인터 가 한 걸음 앞으로 이동 하고 master 지침 은 변 하지 않 습 니 다.

만약 우리 가 dev 에서 의 일 을 완성 한다 면 dev 을 master 에 합병 할 수 있다.Git 은 어떻게 합 쳐 요?가장 간단 한 방법 은 바로 master 을 dev 의 현재 제출 을 가리 키 면 합병 이 완 료 됩 니 다.

그래서 Git 합병 도 빨 라 요!지침 을 고치 면 작업 구역 의 내용 도 변 하지 않 는 다!
가 지 를 합 친 후 dev 가 지 를 삭제 할 수도 있다.dev 가 지 를 삭제 하 는 것 은 dev 지침 을 삭제 하 는 것 이다.삭제 한 후에 우 리 는 master 가 지 를 남 겼 다.

정말 신기 하 다.일부 제출 이 분기 로 이 루어 진 것 을 알 수 있 겠 니?
실전 을 시작 하 겠 습 니 다.
우선,우 리 는 dev 가 지 를 만 든 다음 에 dev 가지 로 전환 합 니 다.

$ git checkout -b dev
Switched to a new branch 'dev'

git checkout 명령 에 -b 파 라미 터 를 더 하면 다음 과 같은 두 명령 에 해당 합 니 다.

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

그리고 git branch 명령 으로 현재 지점 보기:

$ git branch
* dev
 master

git branch 명령 은 모든 가 지 를 표시 합 니 다.현재 가 지 는 앞 에 * 번 을 표시 합 니 다.
그 다음 에 우 리 는 dev 분기 에 정상적으로 제출 할 수 있 습 니 다.예 를 들 어 readme.txt 를 수정 하고 한 줄 을 더 할 수 있 습 니 다.

Creating a new branch is quick.

그리고 제출:

$ git add readme.txt 
$ git commit -m "branch test"
[dev fec145a] branch test
 1 file changed, 1 insertion(+)

현재 dev 분기 의 작업 이 완성 되면 우 리 는 master 분기 로 전환 할 수 있 습 니 다.

$ git checkout master
Switched to branch 'master'

master 분기 로 전환 한 후 readme.txt 파일 을 다시 보 세 요.방금 추 가 된 내용 이 보이 지 않 습 니 다!그 제출 은 dev 분기 에 있 기 때문에 master 분기 의 현재 제출 점 은 변 하지 않 았 습 니 다.

현재 우 리 는 dev 분기 의 업무 성 과 를 master 분기 에 합병 했다.

$ git merge dev
Updating d17efd8..fec145a
Fast-forward
 readme.txt |  1 +
 1 file changed, 1 insertion(+)

git merge 명령 은 지정 한 지점 을 현재 지점 으로 통합 하 는 데 사 용 됩 니 다.합병 후 readme.txt 의 내용 을 보면 dev 분기 의 최신 제출 과 똑 같 습 니 다.
위의 Fast-forward 정 보 를 알 고 Git 은 이번 합병 은'빠 른 진행 모드'라 고 알려 주 었 다.즉,master 을 dev 의 현재 제출 을 가리 키 기 때문에 합병 속도 가 매우 빠르다.
물론 매번 합병 할 때마다 Fast-forward 이 되 는 것 도 아니 고 우 리 는 나중에 다른 방식 의 합병 을 이야기 할 것 이다.
합병 이 완료 되면 dev 가 지 를 안심 하고 삭제 할 수 있 습 니 다.

$ git branch -d dev
Deleted branch dev (was fec145a).

삭제 후 branch 을 보면 master 분기 만 남 았 습 니 다.

$ git branch
* master

가 지 를 만 들 고,통합 하고,삭제 하 는 것 이 매우 빠 르 기 때문에 Git 은 가 지 를 사용 하여 특정한 작업 을 완성 하도록 권장 합 니 다.통합 한 후에 가 지 를 삭제 합 니 다.이것 은 master 분기 에서 직접 작업 하 는 것 과 효과 가 같 지만 과정 이 더욱 안전 합 니 다.
작은 매듭
Git 은 가 지 를 많이 사용 하도록 권장 합 니 다.
분기 보기:git branch창설 지점:git branch <name>분기 전환:git checkout <name>창설+분기 전환:git checkout -b <name>현재 지점 으로 통합:git merge <name>분기 삭제:git branch -d <name>이상 이 바로 본 고의 모든 내용 입 니 다.여러분 의 학습 에 도움 이 되 고 저 희 를 많이 응원 해 주 셨 으 면 좋 겠 습 니 다.