GitHub Flow를 사용한 배경

나는 SIer에서 소규모 팀을 합쳤다.소스 저장소는 Git를 사용하지만 브랜치를 차단하지 않고 master에서만 실행됩니다.
도전하다
마스터만 사용하면 정상적으로 실행되지 않는 코드가 혼입될 때가 있습니다.
지원
따라서 새로운 기능 개발과 오류 복구를 할 때, 우리는 지점을 차단하고, 논평을 통해 코드만 마스터에 통합시켰다.합병 후 즉시 배치하다.

결과
마스터는 청결 상태를 유지한다.또 댓글을 통해 젊은 멤버를 키울 수도 있다.
미완의 일

라식 요청 → 좌석이 가까워서 구두로 대응한다

테스트 코드 쓰기 → 앞으로 원본 코드가 커지면 빠질 수 없지만 지금은 테스트 코드를 치지 않았습니다

배치 자동화 → 수동 혼합

품질과 비용이 효과에 대한 조치를 취할 필요가 있지만 테스트 코드는 쓰지 않는다고 생각합니다.

명령

자주 잊어버리기 때문에 언제 어떤 명령을 집행할지도 한 번 써야 한다.

새로운 기능을 개발하고 오류를 수정할 때

브랜치 개발지점 이름은 무엇을 해야 할지 알 수 있는 이름이다.다음 명령을 사용하여 브랜치를 닫고 브랜치로 이동합니다.

$ git checkout -b ブランチ名

정기push.한 번 쓴 후에 뷰어와 인사를 할 수 있다.

$ git push origin リモートブランチ名

다른 개발자나 뷰어pull시

우선 지점을 끊고 지점으로 이동한다.

$ git checkout -b ブランチ名

그 지점에서pull.

$ git pull origin リモードブランチ名

또한 이 상태에서 제출하고push를 하려면 로컬, 원격 두 개의 지점을 지정해야 합니다. 아래와 같습니다.

$ git push origin ブランチ名:リモートブランチ名

심사 통과 및 합병 시

마스터로 이동합니다.

$ git checkout master

병합

$ git merge ブランチ名

push master.

$ git push origin master

마지막

위의 조치는 GitHub Flow이지만 다음과 같은 효과가 있습니다.

master 청결 유지

평론을 통해 젊은 구성원을 양성한다

간단한 절차이기 때문에 기억하는 것이 적고 곧 채택할 수 있는 조치다.그럼에도 불구하고 개발 효율을 확대하는 동시에 품질을 유지하기 위해 다른 자동화도 추진해야 한다!내 생각엔