개시하다

개발팀은 Giit와 GiitHub을 이용하여 소프트웨어 개발을 진행한다.원활한 개발 추진을 목표로 정보 제출, 아이슈, 풀 리퀘스트 포맷을 결정하고 이모지 프리픽스1를 도입했다.
팀과 부서가 의식을 통일하기는 어렵다.
이런 상황에서 우리는 제출한 제목, 메모, 포스터가 모두 같은 투고라는 것을 보았다😱 왜!😱이런 심정으로 다음과 같은 글을 썼다.
이것은 결코 정확한 것이 아니다.하지만 하나의 생각의 본보기가 될 수도 있다.

우리는 제출에 대해 다음과 같은 제출 양식을 채택했다.
1행: 제출 대상2
두 번째 줄: 빈 줄
3줄 이후: 제출 이유에 대한 상세한 설명3

주제 제출

제출 주제는 디프를 볼 때 마음의 준비를 알리기 위해 업무 내용을 간단하게 적었다.例1: :shower: Remove blank lines빈 줄이 삭제되었습니다.이 때 diff는 빈 줄만 삭제해야 합니다.공행은 딱 봐도 공행이라 평도 가볍다.例2: :art: Change variable name변수 이름이 변경되었습니다.이 경우 diff는 반드시 주의해야 한다.그 변수가 나타난 곳을 모두 새로운 변수명으로 바꿨는지 확인하세요.어떤 경우 수정 전의 변수 이름으로 검색할 수도 있습니다.
이렇게 하면 제출 주제가 적당해 디프를 보여주기 전에 어떤 제출이 될지 예상할 수 있다.관객들이 마음의 준비를 할 수 있기 때문에 이완적으로 논평을 할 수 있다.또 초보자에게도 주의해야 할 사항을 전달할 수 있다.

편지를 내다

변경 사항에 대한 자세한 내용은 커밋된 메시지에 설명되어 있습니다.아무리 길어도 돼요.그 변경에 대한 이슈와 발언이 있다면 파마 링크를 미리 붙여두세요.나는 그것을 변경한 이유를 자세히 쓸 것이다.이때 1년 뒤에는 그 제출(메시지 제출과 diff)만 보고 무엇을 하고 싶은지 어떤 일을 했는지 아는 것이 중점이다.이렇게 하면 변경 의도를 모르고 본인에게 슬랙과 입으로 직접 질문하거나, 퇴사한 사람이 쓴 코드가 무엇인지 전혀 모르고 속수무책인 상황을 해소할 수 있다.사람은 언제 죽을지 모르니 매번 약속의 메시지를 잘 써야 한다.

제출 입도

사용하지 마세요git add ., 꼭 사용하세요git add -p.
프로그램 내용의 변경 사항을 제출하는 것과 무관합니다. 예를 들어 축소 수정이나 빈 줄 삭제 등은 다른 프로그램의 변경 사항과 함께 진행하지 마십시오.프로그램에 영향을 미치지 않는 부분을 강조합니다.시청자가 불쌍해요
emoji prefix 등의 조합은 제출된 입도를 고려하는 계기가 돼야 한다.

Pull Request

먼저 여러 개의 제출로 이루어진 배경과 이루어진 배경 등을 적으세요.Pull Request가 가장 높습니다.좋은 Pull Request를 보면 문제 해결 방법, 프로세스, 해답을 알 수 있습니다.가장 높다

패하다

커밋 메시지 커밋 후에도 변경할 수 있습니다.만약 당신이 편지를 잘못 보내거나 제출한 입도를 잘못 보냈다면, 우리는 일반적으로 다시 할 수 있습니다.우리는 정확한 정보를 커미션 안에 남겨 두자.
지령을 사용할 수 없는 것은 지식이 없어서 두려워하기 때문이다.어떻게 하는지 모르면 먼저 해 보세요.만약 여러 번 실패하면 성공할 것이다.번역오문이 적혀 있습니다. 구글이 잘 읽으면 답이 있습니다.주위 사람들과 상의하세요.만약 정말 실패한다면 관계자에게 사과하고 원상태로 회복할 방법을 생각해 보세요.

끝말

좋은 제출 정보와 좋은 제출의 입도를 반드시 고려해 주십시오.멤버 한 명 한 명이 잘 생각해봐야 하는데, 기트와 기릿허브 개발팀을 활용하는 계기가 될 것 같다.
알맞은 입도의 diff 제출과 정보 제출은 개발진의 보물입니다. 힘내세요.
happy emojis
제출 입도의 지표는 GiitHub의 가시성을 높이기 위해 제출 대상의 시작에 문자를 그린다↩
우편물의 첫 줄을 제출하다.git log --oneline 등↩
편지를 제출하는 것은 세 번째 줄 이후의 제출 대상과 빈 줄로 구분된 소식을 가리킨다.  ↩