초보자들이 이해하기 쉬운 PR을 즐겁게 만들 수 있도록.

6740 단어 Git pullrequest GitHub 당김 요청 초보자

목표

최근 PR(라식 요청)을 사용하는 팀에 연결된 신인.
특히'홍보를 처음 하는 사람'이나'홍보를 잘 못하는 사람'을 대상으로 한다.

먼저

나는 지난달에 팀에 가입한 신인이다.
팀 개발이 처음이라 그런지 요즘 홍보를 보내는 것 자체가 즐겁다.
PR의 가장 큰 목적은 코드의 질을 유지하는 것이다. 그러나 신인에게는 매번 설치할 때마다 선배가 코드 단위(강제)로 평론을 하기 때문에 공부를 위해 매우 좋은 구조이다.
말은 그렇고 선배도 신이 아니기 때문에 어떤 선전도 의도를 이해할 수 없다.
좋은 피드백을 얻기 위해서는 이해하기 쉬운 PR을 제시하는 것이 중요하다.
머릿속은 알겠지만 귀찮으면 고정하기 어려워서 즐겁게 계속하는 게 중요하다고 생각해요.
아직 시험 중이지만.
쉽게 이해할 수 있는 홍보를 위해서 굉장히 중요한 것 같아요.
즐겁게 실천하기 위해 노력하는 일
에서 설명한 대로 해당 매개변수의 값을 수정합니다.

tl;dr

.제출편

세분화 제출

git log 자신의 진전에 젖다

그림 문자를 제출해 보세요

제출 메시지에 What 및 How 쓰기

예언 제출 메시지

PR편

제3자도 알 수 있는 홍보

PR 메시지에 참조를 추가합니다

PR 정보에 연구한 내용을 적는다

PR 정보에 이미지나 표를 사용합니다

WIP(작업 진행 중) PR 향상

끝날 때

참고 자료

승낙편

약속을 깨뜨리다

자신의 저장점을 만드는 의미에서도 상세하게 제출하고 싶지만 제출하는 습관이 없으면 어렵다.
어떤 디테일이 좋을지 아직 파악이 안 됐지만'이게 무슨 변경이야'라는 변경을 한 줄 쓸 수 있다면 제출할 수 있을 것 같아요.
진행된 제출은fixup 제출과rebase 등으로 정리할 수 있기 때문에 세세한 부분은 나중에 정리하는 데 문제가 없다.
물론 나중에 분할 제출도 어느 정도 할 수 있지만 좀 귀찮아서 너무 꼼꼼했으면 좋겠어요.
나는git제출일지를 깨끗하게 하고 싶다.fixup과 squash. - 필기도 하고.
근데 처음부터 약속은 귀찮은 일이었어.
따라서 습관을 기르기 위해서는 즐겁게 노력하는 것이 중요하다.

git log로 자신의 진전에 몰입하다

일이 끝나면 오늘 자란 일지를 확인하면 만족감에 젖는다.
다음날 출근할 때 어제 한 약속을 바라보는 것도 이채롭다.
나는 조망용 부명령을 해서 조망했다.

편리한 "git-하위 명령" 만들기

그림 문자를 제출해 보세요.

담담한 약속이 그림에 들어가면 부유해 보일 것 같아서 기쁩니다.
행두에 제출 유형을 나타내는 그림 문자를 더하면 읽을 수 있는 동시에 정서도 높아진다.
GitHub의 약속 메시지에 그림 문자를 추가하여 개발 효율성 향상

제출 메시지에 What 및 How

5W1H까지는 아니지만 제출에'어떻게 변경되었는지'를 적어야 한다고 생각합니다.
PR을 리뷰할 때 제출된 정보에서 차분하게 리뷰를 합니다.
그 약속의 개요를 한눈에 알 수 있는 것이 중요하다.
Git 커밋 메시지 쓰기 방법

메시지 제출 예언

'이렇게 변경한다'는 생각으로 코드를 쓰기 시작하면 메시지 제출에 시달리지 않을 것이다.
나도 모르게 손찌검을 하고 싶어서 잘 모르고 쓰기 시작했어요. 100줄이 넘는 쓰레기 약속이 폭발적으로 탄생한 일이 종종 있었어요.
대부분의 이런 약속은 나중에 재구성될 것이기 때문에 앞이 보이지 않을 때 한 번 생각하고 다시 쓴다.

선전편

제3자도 이해할 수 있는 PR

모두가 평론을 하기 위해서는 당연히 알아야 하지만, 나는 정보를 더욱 충실하게 하는 것도 좋다고 생각한다.
홍보가 몇 달 뒤 자신, 새로 연결된 미래 동료 등 제3자가 변경 사항을 이해하는 데 가장 좋은 문서이기 때문이다.
'어떻게'는 제출 메시지에 써야 될 것 같아요.
나는 왜 이렇게 변경했는지 왜 다른 방법을 취하지 않는지 깨닫지 못하면 방심하기 쉽다고 생각한다.
'왜'의 위아래 문장이 현재 구성원들에게 충분히 공유되기 때문에 필수적이지 않은 경우도 많다.
하지만 나는 쓰면 가치가 더 높은 문서가 될 것이라고 생각한다.
홍보 정보와 코드의 주석 출력 등에도'왜'를 남겨야 한다.
제 3자는 말할 것도 없고
또 의도를 알면 선배가 대안을 제시하기 쉽다.

선전 편지에 인용을 붙이다

Issue를 바탕으로 하거나 이전의 홍보의 후속으로 제작된 홍보는 반드시 인용원을 기재한다.
GitHub는 #1234처럼 간단하게 링크를 붙일 수 있기 때문에 PR 정보의 머리에

ref #1234

이렇게 실려 있습니다.
GitHub에서 링크

홍보 편지에 토론한 일을 쓰다

구현 기능에 대해 선택할 수 있는 방법이 있으면 기재하십시오.토론과 토론이 많을수록 실시하는 이유는 이해하기 쉽다.
또 다음 홍보에 설치 예정 기능이 있다면 그걸 적어도 확인 재작업을 줄일 수 있다.
GitHub "완벽한 플릭을 쓰는 법을 가르쳐줄게". - 아미티카.

홍보 메시지에 그림과 표를 사용하다

복잡한 설치일수록 문장만으로는 전달하기 어렵다.
반대로 이미지와 표에 의존하면 설명이 수월해진다.
DB 마이그레이션의 경우 열을 단어로 나열하는 것보다 테이블을 쉽게 볼 수 있고, 앞부분의 경우 압축이 있으면 설명이 거의 필요 없다.
이동과 반응이 있는 프론트 데스크톱이라면 GIF를 붙이는 것도 좋다.
Mac 화면을 녹화하고 GIF 이미지로 빠르게 변환

제품의 선전을 높이다

나는 아직 끝나지 않은 단계에서 홍보를 높이는 것이 좋은 습관이라고 생각한다.
반드시 성과를 내야 한다!이렇게 생각하면 제작홍보의 심리적 장애는 높아지지만 업무 도중에 상담소로 활용하면 간단하게 홍보할 수 있다.
만약 선택한 방법이 좋지 않으면 중도에 수정할 수 있기 때문에 재작업을 줄일 수 있다.
만약 어려움이 있다면 홍보상에서 토론할 수 있다. 왜냐하면 그 토론은 아직 남아 있기 때문이다.에서 기술한 장면은 다음과 같은 절차를 이용하여 명세표를 작성하여 개념 디자인에서 체량의 부피를 분석하도록 한다.
이른바 보연상이 모두 가능하고 순조롭지 않을 때 추천하기 때문이다.
초보자를 위한 WIP 워크플로우 & 보기 시 주의사항