내가 직접 git 저장소에서 작업 할 때, 밀기 전에 끌어낼 이유가 없습니다.매번 push하기 전에 pull을 시도하는 git 명령이 있습니까?
다른 사람들과 함께 작업 할 때 끌어 오기 또는 체크 아웃을 시도한 다음 변경 내용을 병합하려고 시도하기 전에 끌어 오기를 수행하는 것이 좋습니다.
어느 쪽이든, 마스터와 함께 최신 상태가 될 때까지 정상적인 방법으로 밀어 넣으십시오. 그래서 매번 밀기 전에 당기는 습관이 좋습니다.
내가 당기는 시간의 90 %는 이미 최신이거나 빨리 감기 중 하나입니다.
실제로 pull을 자동으로 실행하는 git push과 같은 명령이 있고 실제 병합 충돌이있을 때만 밀어 넣기를 중지합니까?
별칭을 만들 수 있다고 가정하지만 먼저 기본 제공 명령이 있는지 확인하고 싶습니다.
내 커밋되지 않은 변경 사항을 숨기고 마스터로 전환하고, 원격에서 가져오고, 현재 분기를 마스터로 병합하고, 원격으로 푸시하고, 내 분기로 다시 전환하고 마스터에 대해 리베이스하는 "완료"별칭을 사용합니다.
테스트를 거치지 않은 코드를 끝내기 때문에 나쁜 작업 흐름 습관을 조장한다고 생각하는 것과 정확히 일치하는 것은 없습니다. 무언가가 깔끔하게 합병 되었기 때문에, 여전히 끔찍하게 부서 질 수 있습니다.
git push은 원격으로 최신 버전이 아닌 경우 이미 거부하려고합니다. 일반적으로 변경 사항을 가져 와서 검토하고 변경하지 않은 변경 사항을 다시 정리 한 다음 계속 진행합니다.
커밋이 너무 많아서 (일반적으로 모두 망치가 마스터 맨 위를 커밋하는 경우) 분기 기반 워크 플로로 전환하는 것이 좋습니다. 이는 기능의 변경 사항을 격리하고, 기록을 깨끗하게 유지하며, 단일 통합 단계를 제공합니다.
+1 테스트되지 않은 코드를 푸시 아웃하는 것을 가리 킵니다. –
내가 그런 잘못을 권장
을 추진하기 전에 풀을 수행하는 것이 좋습니다. 그냥 밀어. 푸싱하는 행위는 푸시 할 수 있는지 여부를 묻습니다. 푸시 할 수없는 이유가 있다면 푸시 할 수 없습니다. 다음 당신은 무엇을해야할지 걱정할 수 있습니다.
"매번 푸시하기 전에 확인하는 것이 좋습니다."- 기술적 인 이유가 없습니다. 무언가가 있다면 git는'push '를 거부 할 것이다. 단일 저장소에서> 20 명의 개발자가있는 환경에서 작업해도 explosely하기 전에 '가져 오기'하지 않습니다. – zerkms