GitHub를 사용하여 리포지토리 기록을 검색하고 구성하는 방법
여기서는 필터, 블레임 및 교차 링크를 사용하여 리포지토리 기록을 검색하고 구성하는 방법을 설명합니다.
대형 프로젝트에 방금 참여한 개발자라고 상상해 보세요. 누군가가 웹 앱의 사이드바 관련 버그를 보고했고 이를 수정할 사람으로 여러분이 지정되었습니다. 보고서를 여러 번 읽어 문제를 이해했기 때문에 이제 수정 작업을 어떻게 시작할지 결정해야 합니다.
새로운 팀 멤버인 여러분은 아직 코드베이스가 익숙하지 않습니다. 또한 계획 토론, 코드 검토 또는 구현을 시작하는 데 필요한 컨텍스트를 제공하는 다른 항목에 포함되지 않았습니다. 가장 적합한 픽스를 결정하려면 먼저 배경 지식을 확보해야 합니다.
GitHub 검색
사이드바 수정을 시작할 단서를 제공하는 이벤트를 경험하진 못했지만, 이러한 이벤트 다수를 프로젝트의 기록에서 확인할 수 있습니다. 프로젝트의 리포지토리에서 "사이드바"를 검색하면 시작 지점을 확보할 수 있습니다.
GitHub에서는 두 가지 검색 방법을 사용할 수 있습니다. 하나는 페이지 상단에서의 전역 검색이며 다른 하나는 특정 리포지토리 탭에서 사용할 수 잇는 범위 지정 검색입니다. 동일한 구문과 함수를 같은 방식으로 지원하지만 몇 가지 중요한 차이점이 있습니다.
전역 검색
전역 검색을 사용하면 완전한 검색 구문을 사용하여 GitHub 전체를 검색할 수 있습니다.
검색 결과는 포괄적이며 코드부터 문제, Marketplace(심지어 사용자)에 이르는 모든 항목을 포함합니다. 다양한 결과 유형 및 리포지토리에서 주요 용어에 대한 언급을 찾는 가장 좋은 방법입니다.
참고 항목
필터 절 is:pr은 문제/끌어오기 요청 저장소에서 반환된 문제를 필터링합니다. is:pr 같은 일부 필터 절은 특정 검색 공급자에서만 지원 되며 다른 공급자에서는 무시됩니다. 예를 들어 코드 검색 공급자는 이 절을 지원하지 않으므로 절을 무시하고 동일한 코드 결과를 반환합니다.
이 시나리오에서는 현재 리포지토리로 범위를 지정한 전역 검색을 사용하여 "사이드바" 라는 용어를 언급하는 코드와 커밋을 찾는 것이 좋습니다. 문제와 끌어오기 요청에 대한 일치를 얻을 수도 있지만 전역 검색 결과 보기에서 추가로 필터링하기는 쉽지 않습니다.
복잡한 전역 검색을 만들려면 고급 검색을 사용해 보세요.
컨텍스트 검색
컨텍스트 검색은 문제나 끌어오기 요청 같은 특정 탭에서 사용할 수 있습니다. 이러한 검색은 현재 리포지토리로 범위가 지정되며 관련 형식의 결과만 반환됩니다. 이 범위 지정의 이점은 사용자 인터페이스가 작성자, 레이블, 프로젝트 등과 같은 알려진 형식별 필터를 노출할 수 있다는 것입니다.
컨텍스트 검색은 현재 리포지토리에서 무언가를 찾을 때 선호하는 방법입니다. 이 시나리오에서는 필터 드롭다운을 사용하여 쉽게 구체화할 수 있는 "사이드바"멘션 검색 결과를 찾는 좋은 방법입니다.
검색 필터 사용
완전한 검색 구문을 이용한 검색은 거의 무한대에 가까운 방식으로 사용할 수 있습니다. 그러나 대부분의 검색은 몇 가지 일반적인 필터를 사용합니다. 컨텍스트 검색 드롭다운에서 제공되기도 하지만 직접 입력하는 쪽이 더 편리할 수도 있습니다.
다음은 대표적인 필터 쿼리 예제입니다.
| 쿼리 | 설명 |
|---|---|
is:open is:issue assignee:@me |
현재 사용자에게 할당된 미해결 문제(@me) |
is:closed is:pr author:contoso |
@contoso에서 생성한 종결된 끌어오기 요청 |
is:pr sidebar in:comments |
설명에서 "사이드바"를 언급하는 끌어오기 요청 |
is:open is:issue label:bug -linked:pr |
연결된 끌어오기 요청이 없는 버그로 레이블 지정된 미해결 문제 |
검색 구문 이해에 관한 자세한 정보
Git 블레임이란 무엇일까요?
이름은 불길하지만 git blame은 파일의 커밋 기록을 표시하는 명령입니다. 누가 무엇을 언제 변경했는지 쉽게 확인할 수 있습니다. 또한 파일에서 작업을 수행한 사람을 추적하여 입력한 내용이나 참여를 확인하는 일도 훨씬 더 쉬워집니다.
참고
일부 Git 시스템 별칭은 판단에 영향을 주지 않도록 git blame의 별칭으로 git praise를 사용합니다.
GitHub에서의 블레임
GitHub는 더욱 강력한 사용자 인터페이스를 사용하여 기본 git blame 기능을 확장합니다.
이 시나리오에서는 몇 가지 방법으로 이 보기에 액세스할 수 있습니다. 전역 검색에서 일부 사이드바 코드를 찾아서 마지막으로 작업한 사용자를 확인하기 위해 비난 옵션을 선택했거나, 끌어오기 요청을 발견하고 버그 설명과 관련된 마지막 커밋으로 다시 추적했을 수 있습니다. 하지만 여기서는 블레임 보기를 사용하면 당면한 작업의 실무 전문가를 쉽게 찾을 수 있습니다.
교차 링크 문제, 커밋 등
GitHub가 공동 소프트웨어 프로젝트에 유용한 또 하나의 이유는 정보의 개별적인 부분을 연결하는 기능입니다. 이 기능이 자동으로 실행될 때도 있는데, 대표적인 경우는 분기의 연속 커밋에서 끌어오기 요청을 만들 때입니다. 그 외의 경우에는 인터페이스에서 드롭다운 메뉴를 사용하여 끌어오기 요청이나 프로젝트를 문제에 수동으로 연결할 수 있습니다.
자동 링크된 참조
GitHub는 프로젝트 전역에서 다양한 항목을 더 쉽게 교차 링크할 수 있도록 단축 구문을 제공합니다. 예를 들어 Duplicate of #8 같은 설명을 남기면 GitHub는 #8이 문제임을 인식하고 적절한 링크를 생성합니다.
GitHub는 사용자가 자신의 ID 처음 7자 이상을 붙여넣은 커밋을 링크하는 기능도 제공합니다.
이 시나리오에서는 컨텍스트에서 나갈 것을 미리 생각하는 사람이 있을 때 보강을 수행할 수 있어 이러한 링크가 대단히 유용함을 확인할 수 있습니다. 예를 들어 사이드바의 현재 상태에는 JavaScript 종속성과 관련된 몇 가지 알려진 문제가 있을 수 있습니다. "사이드바"를 명시적으로 멘션 않은 다른 문제에서 해당 종속성 문제가 논의되었다면 찾기가 어려울 것입니다. 하지만 토론에서 누군가가 문제를 링크하겠다고 미리 생각했다면 상당한 시간을 아낄 수 있습니다. 다음에 문제와 끌어오기 요청을 문서화할 때는 이점을 명심하세요.
자동 링크된 참조 및 URL에 대해 자세히 알아보세요.
@mention을 이용한 사용자 반복
문제와 커밋 링크는 물론 다른 사람을 토론에 연결하는 일도 도움이 됩니다. 이 작업을 수행하는 가장 쉬운 방법은 @mention을 사용하는 것입니다. 이 유형의 언급은 언급된 사용자에게 알림을 보내 토론에 참여하게 합니다. 오래 전에 종결된 문제와 관련된 사용자를 식별할 때도 유용합니다.
