의 Shah Vali

으로 개발자,우리가 많은 선택 사 병합 및 리베이스. 으로 모든 참 우리는 인터넷에서 모두”사용하지 않는 용,그것을 일으킬 수 있는 심각한 문제입니다.”여기서 merge 와 rebase 가 무엇인지,왜 사용해야하는지(그리고 사용해서는 안되는지),어떻게해야하는지 설명 할 것입니다.

Git Merge 와 Git Rebase 는 동일한 목적을 수행합니다. 이들은 여러 분기의 변경 사항을 하나로 통합하도록 설계되었습니다., 하지만 최종 목표는 동일,그 두 가지 방법을 달성하는 다른 방법으로 그것,그리고 그것은 도움이의 차이를 알고로 당신은 더 나은 소프트웨어 개발자입니다.

이 질문은 Git 커뮤니티를 분할했습니다. 어떤 사람들은 당신이 항상 리베이스해야하고 다른 사람들은 당신이 항상 병합해야한다고 믿습니다. 각 측면에는 몇 가지 설득력있는 이점이 있습니다.

Git Merge

Merging 은 버전 제어 시스템을 사용하는 개발자에게 일반적인 관행입니다. 여 가지가 만들에 대한 테스트,버그 수정,또는 다른 이유는,합병이 커밋의 변경 다른 위치에 있습니다., 좀 더 구체적으로 말하면 병합은 소스 분기의 내용을 가져 와서 대상 분기와 통합합니다. 이 프로세스에서는 대상 분기 만 변경됩니다. 소스 분기 기록은 동일하게 유지됩니다.,da2a4595a”>

병합 Master->기능 지

프로

  • 간단하고 익숙
  • 보존 기록과 순서
  • 유지 컨텍스트의점

단점

  • Commit 역사가 될 수 있는 오염에 의해 많은 병합 커밋
  • 사용하여 디버깅git bisect이 될 수 있는 더 열심히

그것을 어떻게

마스터 분기를 병합 기능으로의 분기를 사용하는checkout및merge 명령입니다.,

$ git checkout feature$ git merge master(or)$ git merge master feature

이 만들어지는 새로운”병합 commit 에서”기능을 지점 보유하고 있는 역사의 두 가지입니다.

Git Rebase

Rebase 는 한 분기에서 다른 분기로 변경 사항을 통합하는 또 다른 방법입니다. 리베이스는 모든 변경 사항을 단일”패치로 압축합니다.”그런 다음 패치를 대상 지점에 통합합니다.

병합과 달리 rebasing 은 완료된 작업을 한 지점에서 다른 지점으로 전송하기 때문에 기록을 평평하게 만듭니다. 그 과정에서 원치 않는 역사가 제거됩니다.,

개상은 어떻게 변화를 전달해야에서 최고의 계층 구조 아래쪽으로, 고 병합은 어떻게 그 위쪽으로는

리베이스 기능을 지점으로 마스터

프로

  • 을 간소화하 잠재적으로 복잡한 역사
  • 조작에 하나의 커밋하기 쉽(예:, 으로 복귀 그들)
  • 피 병합 commit”노이즈에서”바쁜 repos 으로 바쁜 분기
  • 청 중간 커밋을 만들어 하나의 커밋 하는 데 도움이 될 수 있 개발 운영 팀을 위한

단점

  • 부수 기능을 한 줌의 커밋을 숨길 수 있습황
  • 리베 공용 장소에 위험할 수 있으로 일할 때 팀
  • 그것은 더 많은 작업:를 사용하여 리베이스를 유지하는 기능을 지점 업데이트 항상
  • 리베이스는 원격 지점에 필요 당신을 강제로 밀어 넣습니다., 사람들이 직면 한 가장 큰 문제는 강제 푸시이지만 git push 기본값을 설정하지 않았다는 것입니다. 이 결과를 업데이트하는 모든 지점이 동일한 이름을 갖는 로컬 및 원격으로,그리고 그에게는 두려운 처리합니다.

경우 리베이 잘못 실수로 재작성한 역사,그것은 이어질 수 있는 심각한 문제,그래서 당신은 확실히 알고 당신이 무엇을 하고 있다!

수행 방법

다음 명령을 사용하여 기능 분기를 마스터 분기로 리베이스.,

$ git checkout feature$ git rebase master

이렇게하면 전체 기능 분기가 마스터 분기 맨 위로 이동합니다. 원래(기능)분기의 각 커밋에 대해 새로운 커밋을 작성하여 프로젝트 기록을 다시 작성하여이 작업을 수행합니다.

대화식 Rebasing

이를 통해 커밋을 새 분기로 이동할 때 변경할 수 있습니다. 이는 분기의 커밋 기록을 완벽하게 제어 할 수 있으므로 자동화 된 리베이스보다 강력합니다. 일반적으로 이것은 기능 분기를 마스터에 병합하기 전에 지저분한 기록을 정리하는 데 사용됩니다.,

$ git checkout feature$ git rebase -i master

이동하려는 모든 커밋을 나열하여 편집기를 엽니 다.

pick 22d6d7c Commit message#1pick 44e8a9b Commit message#2pick 79f1d2h Commit message#3

이것은 rebase 가 수행 된 후 분기가 어떻게 보이는지 정확하게 정의합니다. 엔티티를 다시 주문하면 히스토리를 원하는대로 보이게 할 수 있습니다. 할 수 있습니다 예를 들어,같은 명령을 사용하여fixup,squash,edit등이에,장소의pick.

는 한 사용하기

이렇게 무엇이 최고입니까?, 전문가들은 무엇을 추천합니까?모든 팀이 다르기 때문에 하나 또는 다른 것을 일반화하고 결정하기가 어렵습니다. 그러나 우리는 어딘가에서 시작해야합니다.

팀은 Git rebase 대 merge 정책을 설정할 때 몇 가지 질문을 고려해야합니다. 밝혀진 바와 같이 하나의 워크 플로 전략이 다른 워크 플로 전략보다 낫지 않기 때문입니다. 그것은 당신의 팀에 달려 있습니다.

조직 전체의 rebasing 및 Git 역량 수준을 고려하십시오. 병합의 추적 성 및 내역과 비교하여 리베이싱의 단순성을 중요시하는 정도를 결정하십시오.,

마지막으로,결정에서 병합 및 리베이 고려되어야에서의 컨텍스트 분명한 분기 전략(참조하는 이 기사에 대한 자세한 내용을 이해하는 분기의 전략). 성공적인 분기 전략은 팀의 조직을 중심으로 설계되었습니다.

무엇을 추천합니까?

팀이 성장함에 따라 always merge 정책으로 개발 변경 사항을 관리하거나 추적하기가 어려워집니다. 깨끗하고 이해할 수있는 커밋 내역을 가지려면 Rebase 를 사용하는 것이 합리적이고 효과적입니다.,

다음과 같은 상황과 지침을 고려하여 Rebase 에서 가장 잘 얻을 수 있습니다.

  • 로컬로 개발 중입니다. 이 시점에서 역사를 깔끔하게 유지하기 위해 병합보다 리베이스를 선호해야합니다. 는 경우에 당신은 당신의 개인적인 포크의 저장소 및와 공유하지 않는 다른 개발자,당신은 안전하는 리베이도 한 후 밀어를 사용합니다.
  • 코드를 검토 할 준비가되었습니다:끌어 오기 요청을 만들었습니다. 다른 사람들은 귀하의 작업을 검토하고 있으며 잠재적으로 지역 검토를 위해 포크로 가져오고 있습니다., 이 시점에서 작업을 리베이스해서는 안됩니다. ‘재 작업’커밋을 만들고 기능 분기를 업데이트해야합니다. 이는 끌어 오기 요청의 추적 성을 돕고 우발적 인 이력 파손을 방지합니다.
  • 검토가 완료되고 대상 지점에 통합 될 준비가되었습니다. 축하합니다! 당신은 당신의 기능 분기를 삭제하려고합니다. 는 다른 개발자가 될 수 없 가 합병에서 이러한 변경 이 시점에서,이것은 당신의 기회를 삭제 귀하의 역사입니다., 이 시점에서,당신은 다시 작성할 수 있습니다 역사와 배 원 커밋하고 그 성가신’pr 재’그리고’병합’커밋으로의 초점을 맞추가한다. 이러한 커밋에 대한 명시 적 병합을 만드는 것은 선택 사항이지만 가치가 있습니다. 기능이 마스터로 졸업 할 때 기록합니다.

결론

이 설명이 Git merge 및 Git rebase 에 대한 통찰력을 제공했기를 바랍니다. 병합 대 리베이스 전략은 항상 논쟁의 여지가 있습니다. 그러나 아마도이 기사는 당신의 의심을 없애고 당신이 당신의 팀을 위해 일하는 접근법을 채택 할 수있게 해줄 것입니다.