특히 오픈 소스 소프트웨어 개발에서 효과적인 협업은 효과적인 조직에서 시작됩니다. 놓치는 것이 없도록 하기 위해 "한 문제, 하나의 풀 리퀘스트"라는 일반적인 규칙이 좋은 경험 법칙입니다.
"문서의 모든 깨진 링크 수정"과 같은 큰 범위의 문제를 여는 대신 오픈 소스 프로젝트는 몇 가지 더 작고 관리하기 쉬운 문제로 기여자를 끌어들이는 데 더 많은 행운을 가져다 줄 것입니다.
앞의 예에서 섹션 또는 페이지별로 끊어진 링크의 범위를 지정할 수 있습니다. 이를 통해 한 사람이 더 크고 지루한 기여 노력을 하기를 기다리지 않고 더 많은 기여자가 참여하여 작은 시간을 할애할 수 있습니다.
범위가 작은 문제는 프로젝트 유지 관리자가 작업이 완료된 위치와 완료되지 않은 위치를 확인하는 데 도움이 됩니다. 이렇게 하면 문제의 일부가 누락되고 완료된 것으로 간주되어 나중에 버그나 보안 취약성이 발생할 가능성이 줄어듭니다.
그게 다 좋고 좋습니다. 하지만 이미 광범위한 범위의 문제를 여러 개 열었고 일부 PR이 이미 제출되거나 병합되었으며 현재 작업이 어디서 시작되거나 중단되었는지 알 수 없다면 어떻게 될까요?
프로젝트 상태를 다시 제어할 수 있도록 정리하는 데 약간의 시간이 걸릴 것입니다. 고맙게도 지저분한 저장소를 스캔, 정렬 및 이해하는 데 도움이 되는 여러 명령줄 도구가 있습니다. 제가 사용하는 몇 가지를 소개합니다.
vim을 사용한 대화형 검색 및 바꾸기
Vim에서 파일을 연 다음 대화식으로 검색하고 다음과 같이 바꿀 수 있습니다.
:%s/\<word\>/newword/gc
% 현재 파일 s의 모든 라인을 찾도록 나타냅니다. 대체, \<word\> 전체 단어와 일치하고 g 왜냐하면 "global"은 모든 경우에 해당하기 때문입니다. c 마지막에 각 변경 사항을 확인하고 확인할 수 있습니다. c 없이 자동으로 훨씬 빠르게 실행할 수 있습니다. , 하지만 패턴 일치 오류를 범하면 문제가 복잡해질 위험이 있습니다.
노드 모듈로 Markdown 파일에서 죽은 링크 찾기
markdown-link-check 노드 모듈에는 훌륭한 CLI 친구가 있습니다.
나는 이것을 너무 자주 사용하여 Bash 별칭 기능으로 바꿨습니다. 동일한 작업을 수행하려면 .bashrc에 이것을 추가하세요. :
# Markdown link check in a folder, recursive
function mlc () {
find $1 -name \*.md -exec markdown-link-check -p {} \;
}
그런 다음 mlc <filename>으로 실행하십시오. .
find를 사용하여 git 저장소가 있거나 없는 하위 디렉토리 나열
git 저장소, 즉 .git가 있는 모든 하위 디렉토리를 인쇄합니다. 그들에서:
find . -maxdepth 1 -type d -exec test -e '{}/.git' ';' -printf "is git repo: %p\n"
git 저장소가 아닌 모든 하위 디렉토리를 인쇄하려면 !로 테스트를 무효화하십시오. :
find . -maxdepth 1 -type d -exec test '!' -e '{}/.git' ';' -printf "not git repo: %p\n"
xargs를 사용하여 목록에서 여러 git 저장소 가져오기
처음에는 Bash 스크립트를 사용하여 랩톱을 자동으로 다시 생성할 때 이 기능을 사용했지만 클라우드 인스턴스 또는 Dockerfile로 작업할 때 매우 편리합니다.
주어진 파일, repos.txt 각 줄에 저장소의 SSH 링크(및 SSH 키 설정)를 사용하여 다음을 실행합니다.
xargs -n1 git clone < repos.txt
많은 리포지토리를 가져오고 푸시하려는 경우 이전에 Bash 단일 라이너를 사용하여 리포지토리를 관리하는 방법에 대해 썼습니다.
jot를 사용하여 번호별로 문제 나열
저는 OWASP Web Security Testing Guide 리포지토리의 공동 작성자이자 유지 관리자입니다. 여기서 최근 한 가지 큰 문제(예, "Fix all broken links in the documentation"였습니다. 어떻게 추측하셨나요?)를 해결했습니다. 몇 가지 더 작고 관리하기 쉬운 문제까지. 전체 37개의 더 작고 관리하기 쉬운 문제입니다.
원래 문제가 된 모든 문제를 열거하고 싶었지만 37개의 문제 번호(#275에서 #312)를 입력하는 아이디어는 매우 지루하고 시간이 많이 걸리는 것처럼 보였습니다. 그래서 자연스러운 프로그래머 방식으로 모든 숫자를 입력하는 데 사용한 것과 같은 시간을 소비하고 대신 자동화하는 방법을 만들었습니다.
jot 유틸리티(apt install athena-jot )는 숫자를 인쇄할 때 큰 도움이 되는 작은 도구입니다. 원하는 수와 시작 및 중지 위치를 말씀하시면 됩니다.
# jot [ reps [ begin [ end ] ] ]
jot 37 275 312
이렇게 하면 275에서 312까지의 각 숫자가 새 줄에 인쇄됩니다. GitHub 및 다른 많은 플랫폼이 자동으로 인식하고 링크로 전환하는 문제 번호 표기법으로 만들려면 출력을 awk로 파이프할 수 있습니다. .
jot 37 275 312 | awk '{printf "#"$0", "}'
#275, #276, #277, #278, #279, #280, #281, #282, #283, #284, #285, #286, #287, #288, #289, #290, #291, #292, #293, #295, #296, #297, #298, #299, #300, #301, #302, #303, #304, #305, #306, #307, #308, #309, #310, #311, #312
jot를 사용할 수도 있습니다. 주로 개발 또는 테스트 목적으로 무작위 또는 중복 데이터를 생성합니다.
CLI 기반 오픈 소스 조직
잘 조직된 오픈 소스 저장소는 잘 관리된 오픈 소스 프로젝트입니다. 편리한 참조를 위해 이 게시물을 저장하고 새로 발견한 CLI 초능력을 영원히 사용하십시오! ?