각 개발자마다 원격 지사를 두는 것이 좋은 방법입니까?

프로젝트의 각 개발자마다 원격 지사를 두는 것이 좋은 방법으로 간주됩니까?

우리는 다음 분기와 함께 Git을 사용하고 있습니다.

• 석사
• 해제
• 나타나게 하다

각 개발자가 자신의 브랜치를 보유한 경우 코드를 브랜치에 푸시하고 다른 개발자는 이러한 변경 사항을 자체 브랜치에 병합 할 수 있습니다.

아니! 각 개발자마다 원격 지점 네임 스페이스 를 사용 하는 것이 좋습니다 .

하나의 브랜치만으로는 충분하지 않으므로 개발자는이를 되감거나 많은 도움이되지 않습니다. 오히려 개발자가 원하는대로 원하는 것을 푸시 할 수 있다고 말하고 싶습니다/ . 다른 사람을 위해 미리보기 버전을 게시하여 다른 사람이 테스트하거나 다른 사람이 통합 할 수있는 버전을 제공하는 데 사용할 수 있습니다.

분기를 통합 자에게 제공하거나 태스크 기반 이름을 사용할 수도 있습니다. 작업 기반 이름은 일반적으로 통합자를 추적하기가 쉽지만 개발자가 이름에 대해 더 많이 생각하게하고 사람들이 생각을 좋아하지 않게합니다. 실제로 어느 쪽이 더 잘 작동하는지 모르겠습니다. 심지어 특정 팀에 따라 달라질 수 있습니다.

브랜치 자체를 생성하고 파괴하고 원하는 것을 명확하게 문서화 할 수있는 일종의 github 스타일 인프라가 없다면 각 개발자에게 중앙 서버의 브랜치를 제공하지 않을 것입니다. 일부 개발자는 하나 이상의 지점이 필요하고 일부는 전혀 필요하지 않지만 모든 사람이 정리하고 관리 오버 헤드를 혼란스럽게 만들고 있습니다.

대신 유기농 공유 git의 종류가 뛰어납니다. 자신의 컴퓨터에서 완전 복제본을 만들고 다른 사용자가 가져올 수있는 읽기 전용 SMB 공유 폴더를 만드는 것은 매우 쉽습니다. 사실, 몇몇 개발자가 아직이 작업을 수행하지 않으면 정말 놀랄 것입니다.

개발 팀과 작업의 구성 방식에 따라 다릅니다. 제 생각에는 다음과 같은 경우 지정한 모델이 가장 효과적입니다.

1. 각 개발자는 스스로 독립적 인 작업을 수행합니다.
2. 모든 개발자는 동일한 작업에 기여하고 있습니다.

이 기능이 제대로 작동하지 않는 곳은 개발중인 동시 기능 프로젝트가 있고 각 프로젝트에 여러 개발자가있는 경우입니다.

모든 개발자가 동일한 파일을 만질 수있는 다른 작업을 수행하는 경우 각 개발자에게 고유 한 분기를 제공하는 것이 도움이 될 수 있습니다. 서로의 발끝을 밟는 것을 막을 수는 있지만, 갈등을 관리 할 때는 모든 사람이 자주 합병하고 책임을 져야합니다. 이것은 내 사무실에서 수행되는 것이며 편집 한 파일의 절반을 수동으로 병합해야하는 드문 날과는 별개로 잘 작동합니다.

동일한 기능을 사용하는 여러 개발자가있는 경우 개발자보다는 개발중인 기능을 기반으로 분기를 작성하는 것이 좋습니다.

Git으로 작업하는 경우 Pull Requests를 사용해보십시오.

요약하면 먼저 마스터 분기를 현재 작업 분기에 병합합니다. 모든 병합 충돌은 로컬 지점에 있습니다. 마스터 브랜치가 끊어지지 않기 때문에 좋습니다. 당신이 정말로 망치면, 당신은 되돌릴 수있는 지역 커밋을 가지고 있습니다.

병합을 마치면 팀의 다른 사람에게 지점을 검토하고 마스터 지점으로 병합하도록 요청합니다. 자신을 병합하지 마십시오! 아무도 몰래 들어 와서 다른 풀 요청을 한 경우에는 성공적으로 병합됩니다. 모든 사람이 풀 요청을 알고 있으므로 어쨌든 여러 사람이 동시에 마스터로 합류해서는 안됩니다.

이 프로세스에 익숙해지면 가능한 한 자주 병합을 시도해야합니다. 가난한 사람의 지속적인 통합입니다. 갈등 사이의 시간이 짧을수록 좋습니다. 두 사람이 노력을 복제하고 팀을 구성 할 수있는시기를 식별 할 수 있습니다. 요구 사항을 완료 할 때마다 몇 곳에서 합쳐질 수있는 곳이 있습니다. 적어도 일주일에 한 번은 병합하는 것이 좋습니다. 그렇지 않으면 작업을 더 잘 수행해야합니다.

나는 일반적으로 작업마다 하나의 지점을 만듭니다. Git은 로컬 커밋과 푸시를 구별하기 때문에 좋습니다. 이것은 모든 복잡성없이 각자의 지점을 가진 각 개인의 이점을 제공합니다.