Pull Request 드라이브로 소설 개발
감사의 말
며칠 전에 나는 이런 보도를 썼다.
다행히 많은 반응을 얻었다.
이로써 감사를 드립니다.
요점
Pull Request 드라이브로 소설 개발
!
여기서는 억지로 간단명료한 표현을 우선으로 해야 한다.
소설을 써서 지아이허브에 올리는 과정에서 가끔'이런 표현이 낫지 않겠느냐'는 생각이 들기도 한다.
기릿허브는 과거 데이터를 수시로 방문해 글을 되찾을 수 있기 때문에 대규모 변경과 수정이 수월하게 이뤄질 수 있다.
그러나 빈도가 높은 파일을 업데이트할수록 되찾으려는 특정 시점을 찾아내는 시간이 많아진다.
제출 소식을 기재했더라도 다른 시점에서 같은 부분을 수정했을 가능성도 있다.
지령선 사용에 저항하지 않는다면 이런 검색 방법도 있다.
VScode를 사용한다면 이런 보도도 참고할 수 있다.
기릿허브에 남은 공약 이력은 머지않아 편안함을 방해하는 부하가 될 것이다.
이를 피하기 위해 Pull Request 드라이브의 집필을 제안했습니다.
Pull Request 는
분산버전관리시스템(VCCS)의 기능 중 하나는 코드 등을 추가·수정할 때 다른 개발자에게 호스트에 대한 반영을 의뢰하는 기능이다.본인 이외의 사람이 심사한 뒤 변경을 반영하는 절차를 쉽게 수행할 수 있다.
(통합 요청은 IT 용어 사전 e-Words 2021년 2월 7일 업데이트)
중요한 것은 과거 어느 순간의 원고와 방금 수정된 원고의 구조를 비교할 수 있다는 것이다.
비교 후 수정된 원고를 플러스로 하여 쉽게 제출(합병)할 수 있는 기능도 갖추고 있다.
Pull Request 사용 방법
이 갈라진 나뭇가지를 각각 분지라고 부른다.
적당히 수정하다
수정용 지점에 기록을 제출하다.
수정용 분기에 기록된 제출은 일람표로 표시되고 최종 문서의 변경 위치 등도 간단하게 확인할 수 있다.
적당히 수정하여 수정에 제출하고 지점으로 미루다.
수정 분기를 제출할 때마다 Pull Request가 자동으로 업데이트됩니다.
(Pull Request 릴리즈 이후에는 원래 분기를 커밋해도 자동으로 반영되지 않음)
"Merge pull request"에서 병합하여 수정된 원고가 분기에 저장됩니다.
필요에 따라 수정용 분기를 삭제하거나 계속 사용합니다.
이 일대의 사상은 천차만별이기 때문에 여기서 언급하지 않는다.
GiitHub Flow로 검색하면 머리가 아프니까 검색해 보세요.
Pull Request
상기 절차에서 Pull Request를 사용하면 이력서 제출이 분할되고 정리되며 검색성이 향상됩니다.
제출 이력을 직접 확인하는 게 아니라 당시 작성한 풀 리퀘스트부터 찾아보면 된다.
Pull Request는 리뷰를 게시하는 기능도 갖추고 있어 이를 사용하면 쉽게 이해하고 정리할 수 있다.
나의 경우 원고에 대한 자신의 토로와 고민을 적당히 투고했다.
Pull Request의 장점은 제출 기록의 분할에 국한되지 않습니다.
어느 시점부터 시작된 제출 이력이 쌓이면 최근 행보를 볼 수 있다.
원고 수정 속도가 떨어지더라도 논평에 기재된 방안 수준의 수정은 진전될 수 있다.
평론을 통해 떠오르는 설정과 복선은 줄거리 이전에 잊어버린 비극을 피할 수 있다.
각 파일에 대해 Pull Request를 작성하거나 수정할 내용을 기준으로 만들 수 있습니다.
Issue 같은 과제가 아니더라도 Pull Request 의견이라면 쉽게 쓸 수 있습니다.
적당히 작성하고 원고를 적당히 수정하며 정보를 적당히 넣고 적당히 합병한다.
통합 후 Pull Request 자체도 열람할 수 있으므로 필요한 정보를 적절히 얻을 수 있습니다.
교정 장소로서의 Pull Request
앞의 보도에서 textlint를 소개하였다.
VScode를 사용하면 vscode-textlint로 자동으로 빨간색을 넣으면 됩니다.
그러나 브라우저와 원래의 메모장 (notepad.exe) 등 textlint가 개입할 수 없는 환경이 많다.
그 환경에서도 그에 상응하는 자동화 교정이 가능한 것은 GiitHub Actions와 Reviewdog이다.
!
브라우저에 입력한 문자열에 대해서도 textlint의 Chrome 확장 기능이 적용되지만 이번에는 생략합니다.
리뷰독을 키우다
Reviewdog란 textlint를 포함한 각종 lint 도구(linter)가 토해낸 결과를 Pull Request에 평론하는 똑똑한 개다.
Reviewdog를 창고로 사육함으로써 브라우저와 textlint가 대응하는 편집기에서 편집해도 textlint의 은혜를 받을 수 있습니다.
가져오기 단계
.\github\workflow\reviewdog.yml제작, 아래 내용 붙여넣기name: reviewdog
on: [pull_request]
jobs:
textlint:
name: runner / textlint
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
submodules: true
- name: textlint-github-pr-review
uses: tsuyoshicho/action-textlint@v3
with:
github_token: ${{ secrets.github_token }}
reporter: github-pr-review
level: warning
textlint_flags: "episodes/**"
기본 지점을 제출하고 밀어냄 (보통 마스터나main)
이렇게 가져오면 완성됩니다.
표시된 경우 Commit suggestion에서 수정된 파일을 직접 제출할 수 있습니다.
자동 수정에 대응하는 내용이 없으면 다시 댓글로 기고하기 때문에 다른 사람이 말한 대로 수정하면 된다.
참고로 가져오기가 완료된 후 작성된 Pull Request에서 교정을 시작합니다.
나는 이렇게 해서 30분 정도를 낭비했다.
Reviewdog 덕분에 출장지에서 원고를 계속 수정하여 글씨 쓰는 규칙이 엉망진창이 되는 것을 방지했습니다.
그나저나 아이패드에 기릿허브를 이용하면 사파리에서 기릿허브에 접속해 사용하거나 2천엔을 조금 받는 것을 전제로 다음 앱을 이용할 수 있다.
총결산
Pull Request 드라이브에서 소설을 집필할 때 정보를 더욱 쉽게 집약할 수 있고 편집기와 다른 교정 플랫폼을 준비할 수 있다.
특히 뒷부분에 쓴 Reviewdog를 가져오면 VScode를 설치할 수 없는 환경에서도 쉽게 집필할 수 있습니다.
인터넷을 연결하고 문자를 입력할 수 있는 환경이라면 어디서나 소설을 쓸 수 있다.
이렇게 되면 각 소설 투고 사이트가 GiitHub Actions의 deproy에 대응할 수 있다면 나는 말하지 않겠다.
위와 같은 것도 있지만 아직 움직일지 안 움직일지 확실하지 않다.
후술을 대신하다
실제로 기릿과 기릿허브를 활용한 집필 소설의 주제는 소재가 있다.
아래에 열거한 것은 독서 원숭이의 보도이다.
이 보도에서 우리는 소설을 소스 코드로 삼아 매번 정보를 기록하기 위해 평론과 평론을 사용하는 시도를 소개했다.
나도 이런 수법으로 공을 들였지만 정보의 일람성이 부족한 점이 있었다.
다른 한편, 정보를 원고와 밀접하게 기록할 수 있다는 장점은 버리기 어렵다.
이걸 유지하면서 일람성을 확보하려고 노력한 결과 지티허브가 안정됐다.
이외에도 깃허브액션스는 아이슈를 정리해 집단 집필을 할 때 원고 리뷰를 자동으로 의뢰하는 등 본업 개발자들이 가득 쓴 기사들이다.
소설을 쓰는 용도 특유의 특색을 볼 수 있다면, 나는 다시 글을 쓸 계획이다.
Reference
이 문제에 관하여(Pull Request 드라이브로 소설 개발), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://zenn.dev/haoblackj/articles/manuscript_compare_by_pr텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
좋은 웹페이지 즐겨찾기
