Git과 기타 프로그래밍 전문 용어는 번역 없이 사용되는 경우가 가장 많기 때문에 번역하지 않기로 결정했습니다. 나는 순서를 위해 이 기사의 용어를 "디코딩"과 함께 간략하게 번역하여 여기에 제공할 것입니다.
포크 - "포크". 기본적으로 프로젝트를 기반으로 무언가를 개선하기 위해 프로젝트를 직접 복사합니다.
풀 요청 - 변경 요청입니다. 검토를 위해 변경 사항을 저장소로 보내기(즉, 이 코드는 저장소 소유자나 직장 동료가 확인한 후에만 기본 프로젝트에 추가됩니다)
Pull – GitHub에서 프로젝트를 "풀"(예: 컴퓨터의 IDE로)
푸시 – 로컬 머신에서 GitHub로 프로젝트를 "푸시"합니다.
#1 GitHub.com에서 코드 편집하기
모두가 이미 알고 있다고 생각하는 것부터 시작하겠습니다(비록 개인적으로 일주일 전에는 그것에 대해 전혀 몰랐지만). GitHub의 모든 저장소에서 텍스트 파일을 볼 때 오른쪽 상단에 작은 연필이 표시됩니다. 해당 파일을 클릭하시면 편집이 가능합니다. 완료되면 파일 변경 제안을 클릭하면 GitHub가 포크 및 풀 요청을 생성합니다. 놀랍지 않나요? 그는 포크를 직접 만듭니다! 코드를 포크하여 자신에게 업로드할 필요가 없으며 로컬에서 변경한 다음 끌어오기 요청을 통해 GitHub로 다시 보낼 필요가 없습니다. 최소한의 편집이 필요한 경우 매우 편리합니다.
실제 Pull Request는 아니지만
#2 이미지 삽입
문제 설명은 텍스트 설명에만 국한되지 않습니다. 클립보드에서 이미지를 직접 붙여넣을 수 있다는 것을 알고 계셨나요? 붙여넣으면 해당 내용이 클라우드에 업로드되고 마크업으로 변환되어 이미지를 표시하는 것을 볼 수 있습니다. 우아한!
#3 코드 형식
코드 블록을 작성해야 하는 경우 백틱 세 개로 시작하면 GitHub가 작성 중인 프로그래밍 언어를 추측하려고 시도합니다. 그러나 Vue, Typescript 또는 JSX와 같은 프로그래밍 언어로 코드 조각을 게시하는 경우 구문 강조가 올바르도록 언어를 명시적으로 지정할 수 있습니다. 첫 번째 줄에 ``jsx가 있습니다.
...코드 조각이 올바르게 표시되는지 확인합니다.
(이것은 Gist에도 적용됩니다. Gist에 .jsf 확장자를 지정하면 JSF 구문이 강조 표시됩니다.) 다음은 지원되는 모든 구문 목록입니다 .
#4 풀 리퀘스트에서 "마법의 단어"를 사용하여 문제 해결
문제 #234를 수정하는 Pull Request를 생성했다고 가정해 보겠습니다. 요청 설명(또는 변경 요청 설명의 어느 곳에나)에 "문제 #234 수정"이라는 텍스트를 삽입할 수 있습니다. 그런 다음 Pull Request를 병합하면 문제가 "자동으로" 종료됩니다. 멋지지 않나요? 이에 대한 자세한 내용은 설명서를 참조하세요 .
#5 댓글 링크
특정 댓글에 대한 링크를 만들어야 하는데 방법을 몰랐던 적이 있나요? 비밀을 알려드릴테니 그런 시절은 오래 전에 지나갔습니다. 댓글에 대한 링크를 만들려면 제목 옆에 있는 날짜/시간을 클릭하기만 하면 됩니다.
보세요, 개아론이 이제 사진을 가지고 있어요!
#6 코드 링크
따라서 특정 코드 줄에 대한 링크를 만들고 싶습니다. 이 경우 다음을 시도해 보십시오. 열려 있는 파일에서 원하는 코드 옆에 있는 줄 번호를 클릭하십시오. 와, 알겠어? URL이 변경되어 이제 줄 번호가 표시됩니다! Shift 키를 누른 채 다른 줄 번호를 클릭하면 짜잔! – URL이 다시 변경되고 행 범위가 강조 표시됩니다. 이제 이 URL은 이 파일과 이 행 범위를 가리킵니다. 하지만 잠깐만요. 이는 현재 스레드를 가리킵니다. 파일이 변경되면 어떻게 되나요? 이 경우 현재 상태의 파일에 대한 영구 링크가 필요할 수 있습니다. 저는 매우 게을러서 위의 모든 내용을 스크린샷으로 찍었습니다.
그건 그렇고, URL에 대해서...
#7 GitHub URL을 명령줄로 사용
UI를 사용하여 GitHub를 탐색하는 것은 매우 편리하게 구성되어 있습니다. 하지만 특정 위치로 이동하려면 URL에 직접 입력하는 것이 더 빠른 경우도 있습니다. 예를 들어, 작업 중인 브랜치로 이동하여 마스터와 비교하는 방법을 확인하려면 저장소 이름 뒤에 /compare/branchname을 입력하면 됩니다. 그러면 해당 브랜치에 대한 diff 페이지로 이동됩니다.
하지만 이는 마스터 브랜치와의 차이점이지만 이전에 통합 브랜치로 작업한 경우 URL에 /compare/integration-branch...my-branch를 입력할 수 있습니다.
단축키 애호가의 경우: CTRL+L 또는 CMD+L을 누르면 커서가 URL 표시줄로 이동됩니다(적어도 Chrome 및 Firefox 브라우저에서는). 이는 브라우저 자동 완성 기능과 결합되어 분기 간 탐색이 훨씬 쉬워집니다. 전문가 팁: 화살표를 사용하여 Chrome의 자동 완성 추천 항목을 탐색하고, SHIFT+DELETE를 눌러 기록에서 항목을 제거합니다(예: 분기 병합 후). (SHIFT + DELETE와 같이 단축키에 공백을 넣으면 읽기가 더 쉬울지 모르겠습니다. 하지만 기술적으로 "+"는 단축키에 포함되지 않으므로 이 옵션은 마음에 들지 않습니다. 이런 일 때문에 난 밤에 잠을 못 자요, 론다.)
#8 문제 목록 만들기
문제 설명에 확인란을 추가하시겠습니까?
그리고 목록에서 문제를 볼 때 "5점 중 2점"과 같은 멋진 막대가 나타나길 원하시나요?
괜찮아요! 다음 구문을 사용하여 대화형 확인란을 만들 수 있습니다.
[ ] 화면 너비(정수)
[x] 서비스 워커 지원
[x] 가져오기 지원
[ ] CSS 가변상자 지원
[ ] 맞춤 요소
구문: 공백, 하이픈, 공백, 여는 대괄호, 공백(또는 x), 닫는 대괄호, 공백 및 일부 단어. 그 후에는 실제로 이 버튼을 선택/선택 취소할 수 있습니다! 어떤 이유에서인지 이것은 나에게 일종의 기술적 마법처럼 보입니다. 체크박스를 선택하시면 됩니다! 그리고 동시에 원본 텍스트도 변경됩니다! 그들이 다음에 무엇을 생각해 낼지 생각하는 것은 무섭습니다. 아, 그리고 이 문제가 프로젝트 패널에 있으면 진행 상황도 거기에 표시됩니다.
"프로젝트 패널"이 무슨 뜻인지 이해하지 못한다면 아래를 읽어보세요. 이 페이지에서는 불과 몇 센티미터 더 낮습니다.
#9 GitHub의 프로젝트 패널
대규모 프로젝트의 경우 저는 항상 Jira를 사용해 왔습니다. 그리고 개인 프로젝트에는 항상 Trello를 사용했습니다. 저는 이 두 도구를 모두 정말 좋아합니다. 몇 주 전에 GitHub가 저장소의 프로젝트 탭에서 자체 옵션을 제공한다는 사실을 알았을 때 저는 Trello에서 이미 작업 중인 작업 세트를 복제하는 것이 합리적이라고 생각했습니다.
여기에는 재미있는 것이 없습니다. 그리고 이제 GitHub 프로젝트에서도 같은 일이 발생합니다.
점차적으로 눈은 낮은 대비 이미지에 익숙해질 것입니다.
속도를 위해 위의 모든 내용을 메모로 추가했습니다. 이는 "실제" GitHub 문제가 아니라는 의미입니다. 그러나 GitHub의 문제 관리 기능은 나머지 저장소와의 통합에 있습니다. 따라서 저장소의 기존 문제를 대시보드에 추가하는 것이 더 나을 것입니다. 오른쪽 상단에 있는 카드 추가를 클릭 하고 추가하고 싶은 항목을 찾으세요. 여기에서 특수 검색 구문이 유용하게 사용됩니다 . 예를 들어 is:pr is:open을 입력하면 열려 있는 Pull Request를 패널로 드래그할 수 있고, 오류를 수정해야 하는 경우 label:bug를 드래그할 수 있습니다 .
기존 메모를 이슈로 변환할 수도 있습니다.
그리고 마지막으로 기존 문제 양식에서 오른쪽 패널의 프로젝트에 추가합니다.
해당 프로젝트 패널의 분류 목록으로 이동하므로 어느 열에 넣을지 선택할 수 있습니다.
"작업"에 대한 설명이 이 작업을 구현하는 코드와 동일한 저장소에 있으면 매우 편리합니다. 이는 지금부터 몇 년 후에 Jira/Trello/다른 곳에서 모든 것을 추적할 필요 없이 코드 줄에 대해 git 비난을 실행 하고 해당 줄로 이어진 문제 전체를 파악할 수 있다는 것을 의미합니다 .
결함
지난 3주 동안 저는 Jira 대신 GitHub(Kanban 스타일과 같은 소규모 프로젝트)에서 모든 작업을 실험해 보았는데 정말 마음에 들었습니다. 하지만 개발 속도 등을 제대로 평가하고 계산해야 하는 스크럼 프로젝트에서는 이것을 상상할 수 없습니다. 좋은 소식은 GitHub 프로젝트에는 "특수 기능"이 너무 적어서 다른 시스템으로 전환하는 데 많은 시간이 걸리지 않는다는 것입니다. 그러니 한번 시도해보고 얼마나 마음에 드는지 확인해 보세요. 이게 얼마나 중요한지는 모르겠지만 ZenHub 에 대해서 듣고 10분전에 처음 오픈했습니다. 이는 본질적으로 문제를 평가하고 "서사시" 및 종속성을 생성할 수 있는 GitHub의 확장입니다. 개발 속도와 소모에 대한 그래프가 있습니다. 정말 놀라운 일인 것 같습니다. 추가 자료: 프로젝트에 대한 GitHub 문서.
#10 그위키
Wikipedia와 같은 구조화되지 않은 페이지 세트의 경우 GitHub Wiki(이제부터는 Gwiki라고 부르겠습니다)가 좋습니다. 예를 들어 문서와 같이 구조화된 페이지 집합의 경우 그다지 많지 않습니다. "이 페이지가 저 페이지의 하위 페이지입니다"라고 표시할 방법이 없으며 "다음 섹션" 및 "이전 섹션" 버튼과 같은 편리한 기능도 없습니다. Hansel과 Gretel은 여기서도 확실히 길을 잃을 것입니다. 왜냐하면 여기에도 "탐색 부스러기"(특수 디버깅 연산자 - 대략적인 번역)가 없기 때문입니다. (저자 주: 이 이야기를 읽어 보셨나요 ? 그저 비인간적일 뿐입니다. 두 명의 젊은 깡패가 배고픈 불쌍한 노부인을 죽이고 그녀를 자신의 오븐 에서 산 채로 불태워 버립니다. 그리고 물론 아무도 이해하지 못할 완전한 혼란을 남기고 있습니다. 그래서 그런 것 같아요. 요즘 젊은이들은 존나 예민해요. 요즘 아이들에게 잠자리에 들기 전에 읽어주는 이야기는 잔인하지 않아요!) 계속해서, Gwiki를 실제로 사용해보기 위해 NodeJS에서 몇 페이지를 wiki 페이지로 입력한 다음 커스텀을 만들었습니다. 사이트의 실제 구조를 시뮬레이션하는 사이드바입니다. 이 사이드바는 항상 표시되지만 현재 페이지는 강조 표시되지 않습니다. 링크는 수동으로 유지 관리해야 하지만 전반적으로 모든 것이 잘 작동합니다. 원하는 경우 다음을 살펴볼 수 있습니다 .
이것은 GitBook( Redux 문서 에서 사용됨 )이나 맞춤형 웹사이트와는 거의 경쟁할 수 없습니다. 그러나 이것은 이미 80%에 해당하며 모든 것이 저장소에 있습니다. 나는 단지 이것의 팬이다. 단일 README.md 파일이 너무 많아 사용자 매뉴얼이나 더 자세한 문서를 위한 여러 페이지가 필요한 경우 Gwiki를 사용하는 것이 합리적입니다. 구조/탐색 기능이 부족하여 불편하다면 다른 것으로 이동하세요.
#11 GitHub 페이지
GitHub 페이지를 사용하여 정적 웹사이트를 호스팅할 수 있다는 것을 이미 알고 계실 것입니다. 그리고 만약 당신이 몰랐다면 이제 알게 될 것입니다. 하지만 이 섹션에서는 Jekyll을 사용하여 웹사이트를 만드는 좀 더 구체적인 주제를 다루고 있습니다 . 가장 간단한 형태로 GitHub Pages + Jekyll은 멋진 테마를 사용하여 README.md 파일을 렌더링할 수 있습니다. 예를 들어 about-github 의 추가 정보 페이지를 살펴보세요 .
이 GitHub 사이트의 설정 탭을 클릭하면 GitHub 페이지를 활성화하고 Jekyll 테마를 선택하세요...
그런 다음 주로 쉽게 편집할 수 있는 마크업 파일을 기반으로 전체 정적 사이트를 생성하여 기본적으로 GitHub를 CMS로 전환할 수 있습니다. 실제로 사용해본 적은 없지만 React를 사용하여 Bootstrap 프레임워크를 사용하여 웹사이트를 구축하는 방법이므로 별 문제는 없습니다. Ruby는 로컬 컴퓨터에서 실행되어야 한다는 점에 주목합니다(여기서 Windows 사용자는 이해하는 듯한 시선을 교환하고 다른 방향으로 갈 것입니다. macOS 사용자는 다음과 같이 말할 것입니다. "문제가 무엇입니까? 어디로 가시나요? Ruby는 범용 플랫폼입니다! GEMS도 있습니다." 패키지 관리 시스템!”) (GitHub 페이지에서는 "공격적이거나 위협적인 콘텐츠나 행동"이 허용되지 않으므로 거기에 자신의 버전의 헨젤과 그레텔 스토리를 게시할 수 없다는 점도 참고할 가치가 있습니다.)
내 의견
GitHub Pages + Jekyll 조합(이 기사의 경우)을 더 많이 살펴볼수록 전체 아이디어가 이상하다는 생각이 들었습니다. "최소한의 노력으로 나만의 웹사이트를 만든다"는 아이디어는 훌륭합니다. 하지만 이 작업을 수행하려면 여전히 로컬 컴퓨터에 현재 버전이 필요합니다. 그리고 너무 "간단한" 명령줄 명령이 너무 많습니다. 나는 시작하기 섹션 의 7페이지를 훑어보았는데 그 내용 중 가장 단순한 것은 나뿐 이라는 느낌이 들었습니다 . 그리고 메인 페이지의 간단한 구문이나 간단한 "Liquid 언어 기반 템플릿 메커니즘"의 기본도 파악하지 못했습니다. 차라리 웹사이트를 직접 작성하고 싶어요! 솔직히 말해서 Facebook이 React를 사용하여 도움말 시스템 페이지를 구축하고 매일 정적 HTML 파일로 사전 렌더링 할 수 있는데 이것을 React 문서에 사용하고 있다는 사실에 조금 놀랐습니다 . 그들이 해야 할 일은 마치 CMS에서 오는 것처럼 기존 마크업 파일을 수신하는 방법을 찾는 것뿐입니다. 만약 그러하다면...
#12 GitHub를 CMS로 사용하기
일부 텍스트가 포함된 웹사이트가 있지만 해당 텍스트를 HTML 마크업으로 저장하고 싶지 않다고 가정해 보겠습니다. 대신, 우리는 개발자가 아닌 사용자가 쉽게 편집할 수 있는 곳에 텍스트 덩어리를 저장하고 싶습니다. 일부 버전 관리 옵션을 사용하는 것이 좋습니다. 아마도 일종의 동료 검토 프로세스가 있을 수도 있습니다. 제가 제안하는 것은 다음과 같습니다. 저장소에 저장된 마크업 파일을 사용하여 텍스트를 저장하십시오. 그리고 이러한 텍스트 조각을 검색하여 페이지에 표시하는 클라이언트 측 구성 요소를 사용합니다. 저는 React의 팬이므로 여기에 마크다운 파일의 경로가 주어지면 파일을 추출하고 구문 분석한 후 HTML로 렌더링하는 적절한 <Markdown> 구성 요소의 예가 있습니다.
classMarkdownextendsReact.Component{constructor(props){super(props);// Конечно, вам нужно заменить это на свой URLthis.baseUrl ='https://raw.githubusercontent.com/davidgilbertson/about-github/master/text-snippets';this.state ={
markdown:'',};}componentDidMount(){fetch(`${this.baseUrl}/${this.props.url}`).then(response => response.text()).then((markdown)=>{this.setState({markdown});});}render(){return(<div dangerouslySetInnerHTML={{__html:marked(this.state.markdown)}}/>);}}
constPage=()=>(<div className="page"><div className="about-us"><Markdown url="about-us.md"/></div><div className="disclaimer"><p>A very important disclaimer:</p><Markdown url="disclaimers/home-page-disclaimer.md"/></div></div>);
이제 GitHub는 호스팅하려는 텍스트에 대한 CMS 역할을 합니다. 위의 예에서는 구성 요소가 브라우저에 로드된 후에만 마크업을 검색합니다. 정적 사이트가 필요한 경우 서버에서 렌더링해야 합니다. 좋은 소식! 원하는 캐싱 전략을 사용하여 서버의 모든 마크업 파일을 검색하는 것을 막을 수 있는 방법은 없습니다. 이 경로를 선택하기로 결정했다면 GitHub API를 사용하여 디렉터리에 있는 모든 마크업 파일 목록을 얻는 것이 좋습니다. 보너스 - GitHub 유틸리티! 저는 꽤 오랫동안 Octotree Chrome 확장 프로그램을 사용해 왔으며 추천해 드립니다. 예약 없이는 아니지만 그래도 추천합니다. 탐색 중인 저장소의 트리 보기가 포함된 패널이 왼쪽에 표시됩니다.
그리고 이 비디오를 통해 나는 octobox 에 대해 배웠는데 , 이는 지금까지 나에게도 매우 좋은 유틸리티인 것 같습니다. 이것은 GitHub 문제에 대한 받은 편지함입니다. 그것이 당신이 그에 대해 알아야 할 전부입니다. 색상 얘기가 나와서 말인데, 위의 스크린샷은 모두 겁먹지 않도록 밝은 테마로 촬영했습니다. 하지만 내가 다른 모든 것에서 어두운 색상을 선호한다면 왜 치명적인 창백한 GitHub를 참아야 할까요?
엄밀히 말하면 여기서는 완전히 적절하지는 않지만 Bitbucket을 언급하지 않을 수 없습니다. 2년 전 저는 프로젝트를 시작하고 최고의 Git 호스팅을 선택하는 데 반나절을 보냈습니다. 따라서 Bitbucket은 상당한 차이로 승리했습니다. 그들의 코드 검토 파이프라인은 경쟁사보다 훨씬 앞서 있습니다(GitHub에 검토자라는 개념이 생기기 훨씬 전이었습니다). 이후 GitHub에서도 리뷰를 얻었습니다. 불행하게도 저는 작년에 Bitbucket을 사용할 기회가 없었습니다. 아마도 그들이 뭔가를 다시 추진했을 것입니다. 그래서 git 호스팅 서비스를 선택하시는 분들도 Bitbucket에 주목하시길 권해드립니다.
결론
그게 다야! 이전에 여러분에게 알려지지 않았던 적어도 세 가지 사실을 알려드릴 수 있었으면 좋겠습니다. 그리고 여러분도 제 글을 읽으면서 즐거운 시간을 보내셨기를 바랍니다.
GO TO FULL VERSION