▲

git-pr - 새로운 git 협업 서비스

 (pr.pico.sh)
13P by xguru 2달전 | favorite | 댓글 1개
  • 가장 단순한 git 협업 도구를 만드는 것이 목표
  • 외부 협업자의 시간과 에너지를 희생하지 않으면서도, 자체 호스팅 git 서버 실행을 SSH 서버 실행만큼 간단하게
  • 메일링 리스트와 pull request 워크플로우를 결합
    • 패치 생성처럼 간단하면서도 pull request의 사용 편의성을 갖춘 협업 도구를 만들고자 함
  • 또 다른 코드 저장소를 만드는 게 아니라, 외부 기여자와 협업할 수 있는 매우 단순한 자체 호스팅 git 솔루션을 만들고자 함

필요한 것

  • 코드 소유자가 git 서버 실행을 위해 필요한 것:
    • 단일 golang 바이너리
  • 외부 기여자에게 필요한 것:
    • SSH 키 페어
    • SSH 클라이언트

현재의 문제점

  • 이메일은 git 저장소에 대한 변경 사항(패치 세트)을 보내고 받기 위한 분산 시스템으로는 훌륭하지만, 새 사용자를 메일링 리스트에 온보딩하고 이메일 클라이언트를 제대로 설정한 다음 코드 기여를 제출하는 것만으로도 많은 개발자가 포기하게 만듦
  • 이메일 프로토콜을 활용하여 협업하므로 기능 세트에 제한이 있음. 예를 들어 이메일 편집이 불가능하고, 모든 사람이 다른 클라이언트를 사용하며, 이러한 클라이언트는 일반 텍스트 이메일 및 패치 다운로드와 관련하여 서로 다른 제한 사항이 있음
  • Github pull request는 사용, 편집 및 관리가 쉽지만, 사용자가 코드 리뷰를 수행하려면 Github 웹사이트 내에 있어야 한다는 단점이 있음
  • 빠른 변경의 경우에는 좋지만, 웹 브라우저 내에서 코드를 읽기 시작하면 상당한 단점이 있음. 어느 시점에서는 로컬 개발 환경이나 IDE 등에서 코드를 검토하는 것이 더 타당함
  • IDE 내에서 PR을 검토할 수 있는 도구와 플러그인이 있지만, 사용 가능하게 만들려면 엄청난 노력이 필요함
  • 또한 pull request를 모방하는 자체 호스팅 솔루션은 이를 관리하기 위해 많은 인프라가 필요함. 데이터베이스, git에 연결된 웹 사이트, 관리자 관리, 서비스 등
  • 또 다른 큰 마찰 지점은 외부 사용자가 코드 변경 사항을 제출하기 전에 먼저 계정을 만들고 로그인해야 한다는 것. 이는 외부 기여자뿐만 아니라 인프라를 프로비저닝해야 하는 코드 소유자에게도 상당한 마찰을 더함
  • PR을 제출하기 전에 코드 저장소 내에서 저장소를 포크해야 하는 경우가 많음. 그런 다음 다시는 기여하지 않고 포크된 저장소를 영원히 유지함. 이것은 어리석어 보임

Patch Request (PR) 소개

  • 이메일 설정의 번거로움이나 이메일 프로토콜에 의해 부과되는 제한 없이 패치를 주고받을 수 있는 자체 호스팅 git "서버"를 만들고자 함
  • 또한 주요 워크플로가 로컬 개발 환경을 중심으로 이루어지기를 원함. Github는 브라우저에 IDE를 가져와 워크플로를 지원하고 있지만, 우리는 코드 리뷰를 로컬 개발 환경 내에서 최고 수준의 시민으로 만들어 그 아이디어를 뒤집고 싶음
  • Github의 pull request 워크플로와 이메일을 통한 패치 송수신의 중간쯤으로 봄
  • SSH 앱을 활용하여 기여자와 프로젝트 소유자 간의 대부분의 상호 작용을 처리하는 것이 기본 아이디어. 모든 것을 터미널 내에서 인체 공학적이고 완전한 기능으로 수행할 수 있음
  • 알림은 RSS로 이루어지고 모든 상태 변경은 정적 웹 자산 생성으로 이어져 단순한 파일 웹 서버를 사용하여 모두 호스팅할 수 있음

format-patch 워크플로

  • 여기서 기본적인 협업 도구는 format-patch
  • 코드 변경 사항을 제출하든 코드 변경 사항을 검토하든 모두 코드에서 발생
  • 기여자와 소유자 모두 새 커밋을 생성하고 서로 위에 패치를 생성하는 것
  • 이렇게 하면 리뷰어가 코드 블록의 한 줄에 "댓글"을 달 수 있는 웹 뷰어를 가질 필요가 없어짐. 필요 없음. 기여자의 패치를 적용하고, 댓글이나 코드 변경 사항을 작성하고, 새 패치를 생성하고, 패치를 "리뷰"로 git 서버로 보내면 됨
  • 이 흐름은 두 사용자가 일련의 변경 사항에 대해 협업하는 경우에도 정확히 동일하게 작동함
  • 동일한 코드 변경에 대해 여러 패치 세트를 보내는 문제도 해결됨. 모든 변경 및 협업이 이루어지는 단일 중앙 Patch Request가 있음
  • git note를 활용하여 리뷰/댓글을 활용하는 방법을 찾을 수 있겠지만, 솔직히 그 솔루션은 잔인하고 대부분의 git 사용자의 편안함 수준을 벗어나는 것처럼 느껴짐
  • 코드로 리뷰를 보내고 사용 중인 프로그래밍 언어로 코드에 주석을 작성하면 됨
  • 이러한 주석을 "처리"하고 후속 패치에서 제거하는 것은 기여자의 일
  • 모든 주석을 처리하기 위한 강제 기능: 코드에 처리되지 않은 주석이 있으면 패치가 병합되지 않음. 무시할 수 없으며 그렇지 않으면 잘못 업스트림될 것

Patch Request의 작동 방식

  • Patch Request (PR)는 git 저장소에 대한 변경 사항을 제출, 검토 및 수락하는 가장 간단한 방법. 작동 방식은 다음과 같음:
    • 외부 기여자가 저장소 클론(git-clone)
    • 외부 기여자가 코드 변경(git-add & git-commit)
    • 외부 기여자가 패치 생성(git-format-patch)
    • 외부 기여자가 SSH 서버에 PR 제출
    • 소유자가 새 PR에 대한 RSS 알림 수신
    • 소유자가 SSH 서버에서 로컬로 패치 적용(git-am)
    • 소유자가 코드에 제안 사항 작성(git-add & git-commit)
    • 소유자가 패치를 SSH 서버로 파이프하여 리뷰 제출(git-format-patch)
    • 외부 기여자가 PR 리뷰에 대한 RSS 알림 수신
    • 외부 기여자가 패치 재적용(git-am)
    • 외부 기여자가 코드의 주석을 검토하고 제거
    • 외부 기여자가 또 다른 패치 제출(git-format-patch)
    • 소유자가 로컬로 패치 적용(git-am)
    • 소유자가 PR을 승인으로 표시하고 코드를 main에 푸시(git-push)
▲
xguru 2달전  [-]

Pico.sh - 모든 것을 SSH를 이용해서 웹서비스를 관리하는 오픈소스 모음 에 새로 추가 된 것이네요.
기존에는 다음과 같은 것들이 포함되어 있습니다.

  • pgs.sh: 사이트 배포를 위해 SSH를 사용하는 스태틱 사이트 호스팅 플랫폼
  • tuns.sh: SSH로 로컬 호스트와 연결하는 https/wss/tcp 터널
  • imgs.sh: 인증에 SSH를 사용하는 Docker 이미지 레지스트리
  • prose.sh: 콘텐츠 관리를 위해 SSH를 사용하는 블로그 플랫폼
  • pastes.sh: rsync, scp 및 sftp를 사용하여 코드 스니펫을 업로드
  • feeds.sh: SSH를 사용하는 RSS 이메일 알림 서비스
답변달기