우리는 git에서 무엇을 잘못하고 있습니까?

Question

git을 사용하여 Django 프로젝트를 작성하는 3 명이 있습니다.

나는 다른 2보다 많은 경험을 가지고 있으므로 "마스터"에 들어가기 전에 모든 변화가 나를 기다리고 있습니다.

우리는 모두 창을 돌리고 있으며, 디스크 기반 공유가 작동하는 곳이 아니기 때문에 우리는 모두 리눅스 박스의 개별 계정에 별도의 "원본"저장소를 가지고 있습니다. 이는 우리가 변경 사항을 서로 공유하고 리포지토리의 "오프 사이트 (offsite)"백업으로 사용할 수있는 방법입니다.

다른 2 명 중 하나가 지점을 만들고 BugA라고 부르며 수정합니다. 그런 다음 작업 컴퓨터에서 리눅스 시스템으로 이동하여 변경 사항을 검토하고이를 내 계정의 "마스터"로 통합 할 수 있습니다 (이는 프로덕션으로 이동하는 코드 사본으로 간주됩니다).

일단 BugA를 완료하면 BugB가 새로운 분기로 시작됩니다. 나는 그들의 작업을 검토하면서 몇 가지 문제 (초과 코드, 주석 누락 등)를 찾습니다. 따라서 코드를 변경하고 테스트하고 마스터하도록합니다.

그런 다음 BugB에 대한 수정 사항을 보내면 모든 변경 사항이 적용됩니다. 이러한 충돌은 내가 저지른 코드 라인에있다.

그들은 나와 합병하려고 할 때 자신의 끝에서 충돌을보고합니다.

이 글을 쓰는 동안 무엇이 잘못되었을 지 이해하기 시작했습니다. 자신의 코드를 마스터에 병합하여 편집 및 커밋합니다. 내 레포에서 내 지점으로 변경하고 병합을 위해 다시 밀어 넣은 다음 내 마스터에게 병합해야합니다.

내가 잘 모르는 부분은 무엇을 해야하는지입니다. 일단 그들이 내 레포에서 지회와 합병되면, 그들은 내 주인과 합병해야합니까? 1 대신 2 병합? 때문에 우리는 두 번 병합 등 .... 정말 어떻게 두 번 작업해야

가 있다는 밀어을 의미 리눅스 박스에 외부 호스팅 REPO이 방법의

?

Answer 1

나는 당신의 질문을 이해, 당신은 모든 일이 벌어지고 세 원격의 repos ("기원")이 있습니다

• 당신의 repo (생산 코드가) 사용자 1의 repo_mark
• REPO를 사용자 2 repo_user2

그리고 시나리오의 repo_user1

의 repo는 다음과 같습니다

• USER1 당신이 git fetch repo_user1을하고 변화를 가져 오기 및 병합, 그 다음 git push origin BugA:BugA
• 와 repo_user1 (자신의 원점)에 대한 변경 사항을 밀어 버그 수정 분기 (BugA)를 생성하고
• 다음 몇 가지 수정을한다 의 master에 (당신이해야 할 일을했을 일부 변경 포함) 분기 BugA 당신의origin (글로벌 마스터의 repo로 간주되는)

작업을 일관되게 수행하려면 세 개의 repos에서 작업 할 필요가 없습니다. 하나만을 사용하십시오. 지침은 만 repo_mark/master으로 푸시 할 수 있지만 동료가 해당 repo의 Bugfix 분기로 푸시 할 수 있습니다.

따라서 user1은 BugA 분기를 원점 (존재하지 않음)으로 푸시하지 않고 repo_mark/BugA으로 푸시합니다. 당신이 (의 repo로 간주됩니다) repo_mark/master에 BugA의 변화를 넣어되면

, 당신은 (즉 않는 git fetch originorigin는 repo_mark되는 경우) 자신의 작업 사본을 업데이트하기 위해 두 동료에게

다음

git checkout master 
git rebase origin/master 

이제 세 분 모두 동일한 master 분기를 공유합니다. 그리고 –     – fetch ed가 지금 repo_mark의 전체 백업을 가지고있는 모든 사용자에게 백업을 언급했습니다.

이

은

git push origin :BugA 

에 자식을 말함으로써 repo_mark에 BugA을 삭제할 수있는 권한 시간이 될 것입니다 및 user1에 대한 자신의 지역 BugA 분기를 삭제합니다. BugB의 작품은 한편에서 시작한 경우 업데이트하는 그에게 말했다 후

는 BugB 작업을 사용자가

git checkout BugB 
git rebase master 

않습니다. 어떤 갈등이 생길 수도 있지만 그렇게 할 필요는 없습니다.

충돌이 해결되면 그는 BugB에서 계속 작업하고 repo_mark/BugB으로 작업을 푸시합니다.

---

편집 : git -- locking master branch for some users?- 답변이 어떻게 당신의 동료 master을 고정하는 방법을 보여줍니다.

---

편집 2 : 물론, 당신은 자신의 작품이 백업 동료에 대한 다른 두 REPOS을 keept 수 : 이들의 repos에 그들이 push을 자신의 일이 당신에게 전달 될 준비가 될 때까지 다음 push에 repo_mark. 그러나이 경우, 귀하는 귀하의 Repo를 귀하의 것과 동기화하여 유지할 책임이 있으며 귀하는 귀하의 Repo를 귀하와 연결하여 유지해야합니다.

Answer 2

충돌 상황을 볼 수있는 유일한 방법은 "코드 변경"을 통해 실제로 커밋을 수정하는 것입니다. 즉, 새로운 SHA1을 사용하여 커밋을 만들고 그 대신에이를 확인하는 것입니다. 당신의 역사를 "깨끗하게"유지하려는 경우 (제 의견으로는 과대 평가), 그러한 갈등을 해결할 수있는 곳은 없습니다. 그러나 병합 작업을 줄이는 것이 더 중요하다면 커밋을 변경하는 대신 수정 내용이 포함 된 커밋을 새로 작성하려고합니다.

커밋을 수정 한 방법이 아니라면 워크 플로에 다른 것이 있다는 의미입니다. 나에게 알려 줘서 내가 무엇을 생각해 낼 수 있는지 알아 보겠다.