[Gitn] Cherry-pick, Rebase, Pull request

Cherry-pick

특정한 커밋으로 생긴 변화만을 대상 브랜치에 병합하는 작업

master 브랜치와 other 브랜치가 있는 상황에서, other 브랜치의 other1 커밋을 가져오고 싶다면

# git checkout master
# git cherry-pick commit-id

*conflict 원인과 해결

파일의 같은 부분이 동시에 수정되었을 때 (master의 마지막 커밋과 other의 해당 커밋이 둘다 같은 부분을 수정했을 때)

merge시와 똑같이 conflict 부분을 해결하고나서, 파일을 add하고 나면(머지툴을 사용한다면 파일을 수정저장하고나면 add가 완료된다.)

아래처럼 마저 진행을 하면 된다.

# git cherry-pick --continue

 

 

 

Rebase

base(병합할 브랜치들의 공통의 조상)로부터 갈라져나온 브랜치를 가져와서 전체를 하나의 플로우로 만드는 작업

-commit들의 관계를 수정하는 작업. 플로우가 깔끔하게 유지되는 장점이 있다.

master 브랜치와 other 브랜치가 있는 상황에서, other 브랜치 뒤에 base 이후의 master 브랜치의 작업들을 가져다 붙이고 싶다면

# git rebase other

*rebase는 remote에 push하기 전까지만 하는 게 좋다. rebase 이후의 커밋과 브랜치 상태에서의 커밋이 엉킬 수 있기 때문,

*rebase와 merge의 결과는 (똑같이 브랜치를 병합한 것이기 때문에) 근본적으로 같아야한다.

 

 

 

[강의출처] opentutorials.org/course/3843/24444

---

pull request

독립적으로 진행되던 브랜치의 작업을 (master 등의) 다른 브랜치에 병합해달라고 요청하는 기능

 

많은 프로젝트에서 master 브랜치는 즉시 배포 및 실행이 가능한, 문제 없는 상태로 유지되고 있다.

따라서 master 브랜치에서 직접 작업하는 대신에

추가 작업은 새로운 브랜치에서 진행해서 해당 작업에만 집중할 수 있고, 부담없이 실험적인 시도를 할 수 있도록 한다.

 

브랜치에서 작업이 완료되어 master 브랜치와 병합이 필요해지면, pull request를 보낸다.

리뷰어들과 참여자들이 토론을 하고 문제가 없다고 판단되면 최종적으로 merge pull request를 한다.

리뷰과정에서 코드를 제안할 수도 있고, 제안사항을 바로 커밋할 수도 있는 등 유용한 기능이 많아서 코드 리뷰에 좋다.

 

이후 merge 방법에는

Merge pull request(이력을 그대로 두고 브랜치를 병합하는 방법), squash and merge(한쪽 브랜치의 커밋을 하나로 묶어서 마스터와 병합하는 방법), rebase and merge(베이스를 옮겨서 이력을 하나의 플로우로 만드는 방법, 읽기 쉬움) 등이 있다.