Offcanvas

���������������������������������������������

깃허브, ‘코드 검색’ 개선한다··· 기술 프리뷰 발표

깃허브가 자사 코드 공유 사이트의 코드 검색 기능과 파이썬을 위한 코드 탐색 기능을 개선하기 위한 기술 프리뷰를 발표했다.  회사에 따르면 개선된 기능 중에는 러스트(Rust)로 구축된 새로운 코드 검색 엔진이 있다. 기술 프리뷰의 검색 인덱스는 가장 인기 있는 퍼블릭 리포지토리 500만 개 이상을 포함한다. 액세스 권한이 있다면 프라이빗 리포지토리에서도 검색할 수 있다.    이 밖에 기술 프리뷰에 포함된 기능은 다음과 같다.  • 스마트 랭킹과 코드에 최적화된 인덱스 • 부분 문자열 일치 및 특수문자를 지원하는 정확한 문자열 검색  • 검색 상자의 자동 완성 제안  • org:code 또는 repo:code 한정자로 검색 범위 지정  • language:code 및 path:code 등의 필터를 통한 결과 정제  • 디렉토리 트리 등의 추가 기능을 통한 빠른 베어링  검색 구문은 이곳에서 확인할 수 있다. 관심 있는 개발자는 기술 프리뷰에 등록해 피드백을 제공할 수 있다. 기술 프리뷰가 활성화되면 깃허브에서도 사용해 볼 수 있을 것이라고 회사 측은 전했다. 처음에는 별도의 새 코드 검색용 인터페이스가 제공된다. 깃허브에서 피드백을 반영하고, 이를 폭넓게 채택할 준비가 되면 깃허브닷컴 환경에 통합할 계획이다.  한편 파이썬을 위한 ‘정확한’ 코드 탐색 기능은 새로운 스택 그래프 프레임워크를 기반으로 한다고 깃허브는 밝혔다. 스택 그래프를 사용하면 파이썬 이름 바인딩 규칙의 자세한 정보를 인코딩할 수 있다. 이를 통해 리포지토리 추가 구성없이 각 참조가 참조하는 특정 정의를 결정할 수 있다고 회사 측은 설명했다.  지금까지 깃허브 코드 탐색은 ‘퍼지(fuzzy)’ 또는 검색 기반이었다. 참조를 클릭하면 해당 이름의 리포지토리에 있는 모든 정의가 표시됐다. 이로 인해 일반적인 이름의 정의 및 참조를 볼 때 많은 노이즈가 발생할 수 있었다. ...

깃허브 코드 공유 코드 검색 코드 탐색 파이썬 개발자 리포지토리

2021.12.10

깃허브가 자사 코드 공유 사이트의 코드 검색 기능과 파이썬을 위한 코드 탐색 기능을 개선하기 위한 기술 프리뷰를 발표했다.  회사에 따르면 개선된 기능 중에는 러스트(Rust)로 구축된 새로운 코드 검색 엔진이 있다. 기술 프리뷰의 검색 인덱스는 가장 인기 있는 퍼블릭 리포지토리 500만 개 이상을 포함한다. 액세스 권한이 있다면 프라이빗 리포지토리에서도 검색할 수 있다.    이 밖에 기술 프리뷰에 포함된 기능은 다음과 같다.  • 스마트 랭킹과 코드에 최적화된 인덱스 • 부분 문자열 일치 및 특수문자를 지원하는 정확한 문자열 검색  • 검색 상자의 자동 완성 제안  • org:code 또는 repo:code 한정자로 검색 범위 지정  • language:code 및 path:code 등의 필터를 통한 결과 정제  • 디렉토리 트리 등의 추가 기능을 통한 빠른 베어링  검색 구문은 이곳에서 확인할 수 있다. 관심 있는 개발자는 기술 프리뷰에 등록해 피드백을 제공할 수 있다. 기술 프리뷰가 활성화되면 깃허브에서도 사용해 볼 수 있을 것이라고 회사 측은 전했다. 처음에는 별도의 새 코드 검색용 인터페이스가 제공된다. 깃허브에서 피드백을 반영하고, 이를 폭넓게 채택할 준비가 되면 깃허브닷컴 환경에 통합할 계획이다.  한편 파이썬을 위한 ‘정확한’ 코드 탐색 기능은 새로운 스택 그래프 프레임워크를 기반으로 한다고 깃허브는 밝혔다. 스택 그래프를 사용하면 파이썬 이름 바인딩 규칙의 자세한 정보를 인코딩할 수 있다. 이를 통해 리포지토리 추가 구성없이 각 참조가 참조하는 특정 정의를 결정할 수 있다고 회사 측은 설명했다.  지금까지 깃허브 코드 탐색은 ‘퍼지(fuzzy)’ 또는 검색 기반이었다. 참조를 클릭하면 해당 이름의 리포지토리에 있는 모든 정의가 표시됐다. 이로 인해 일반적인 이름의 정의 및 참조를 볼 때 많은 노이즈가 발생할 수 있었다. ...

2021.12.10

'폴리리포주의자'가 모노리포를 반대하는 3가지 이유

모노리포(monorepo)와 폴리리포(polyrepo)가 무엇이냐는 질문에 답하려면 먼저 일반적인 애플리케이션을 구성하는 모듈을 살펴보아야 한다. 하나의 애플리케이션에는 여러 가지 구성요소가 있다. 즉, 몇 가지 모바일 클라이언트 앱, 웹 애플리케이션 프론트엔드, 하나 이상의 백엔드 서비스, 데이터베이스 및 데이터 관리 계층, (보고 및 관리와 같은)전문 서비스 등이다.  각 구성 요소에 연결된 소스 코드도 있다. 구성 요소를 담당하는 모든 개발자가 액세스하는 소스 코드는 코드 리포지토리에 저장된다. 코드 리포지토리와 저장소 관리 방법은 매우 다양하다. 리포지토리 대다수는 깃(Git)이라고 알려진 오픈소스 시스템에 기반한다.   각 구성 요소에는 코드 리포지토리가 있다. 자, 여기서 문제가 생긴다. 애플리케이션의 모든 구성 요소에 대한 모든 코드를 회사 전체나 애플리케이션 전체의 코드 리포지토리에 저장해야 하는가? 아니면 각 구성 요소마다 고유한 개별 코드 리포지토리가 있어야 하는가? 최근까지 애플리케이션 각 구성 요소에는 일반적으로 고유한 리포지토리가 있었다. 이 모델은 여러 개의 독립적인 코드 리포지토리를 가진 애플리케이션과 관련이 있으므로 폴리리포라고 한다.  그러나 최근 몇 년 동안, 특히 구글을 비롯한 일부 업체는 모든 애플리케이션 구성 요소의 모든 코드를 하나의 큰 리포지토리에 집어넣는 쪽에 찬성했다. 이러한 코드 관리 모델을 모노리포라고 한다.  폴리리포와 모노리포 방법론은 각기 장단점이 있으며, 분석 기사도 많았다. 과연 둘 중 어떤 방식을 사용해야 하는 것일까? 개인적으로는 전통적인 폴리리포 모델이 훨씬 우수하다고 생각한다. 모노리포 모델은 잘못된 습관이나 건전하지 않은 프로세스를 조장하고, 개발 조직의 확장 가능성과 애플리케이션 자체의 복잡성 등으로 애플리케이션 확장이 실질적으로 더 어려워진다. 이 주장을 뒷받침하는 3가지 이유를 면밀히 살펴보자.   이유 #1 : 모노리포는 단일 팀 소...

모노리포 폴리리포 리포지토리

2021.11.11

모노리포(monorepo)와 폴리리포(polyrepo)가 무엇이냐는 질문에 답하려면 먼저 일반적인 애플리케이션을 구성하는 모듈을 살펴보아야 한다. 하나의 애플리케이션에는 여러 가지 구성요소가 있다. 즉, 몇 가지 모바일 클라이언트 앱, 웹 애플리케이션 프론트엔드, 하나 이상의 백엔드 서비스, 데이터베이스 및 데이터 관리 계층, (보고 및 관리와 같은)전문 서비스 등이다.  각 구성 요소에 연결된 소스 코드도 있다. 구성 요소를 담당하는 모든 개발자가 액세스하는 소스 코드는 코드 리포지토리에 저장된다. 코드 리포지토리와 저장소 관리 방법은 매우 다양하다. 리포지토리 대다수는 깃(Git)이라고 알려진 오픈소스 시스템에 기반한다.   각 구성 요소에는 코드 리포지토리가 있다. 자, 여기서 문제가 생긴다. 애플리케이션의 모든 구성 요소에 대한 모든 코드를 회사 전체나 애플리케이션 전체의 코드 리포지토리에 저장해야 하는가? 아니면 각 구성 요소마다 고유한 개별 코드 리포지토리가 있어야 하는가? 최근까지 애플리케이션 각 구성 요소에는 일반적으로 고유한 리포지토리가 있었다. 이 모델은 여러 개의 독립적인 코드 리포지토리를 가진 애플리케이션과 관련이 있으므로 폴리리포라고 한다.  그러나 최근 몇 년 동안, 특히 구글을 비롯한 일부 업체는 모든 애플리케이션 구성 요소의 모든 코드를 하나의 큰 리포지토리에 집어넣는 쪽에 찬성했다. 이러한 코드 관리 모델을 모노리포라고 한다.  폴리리포와 모노리포 방법론은 각기 장단점이 있으며, 분석 기사도 많았다. 과연 둘 중 어떤 방식을 사용해야 하는 것일까? 개인적으로는 전통적인 폴리리포 모델이 훨씬 우수하다고 생각한다. 모노리포 모델은 잘못된 습관이나 건전하지 않은 프로세스를 조장하고, 개발 조직의 확장 가능성과 애플리케이션 자체의 복잡성 등으로 애플리케이션 확장이 실질적으로 더 어려워진다. 이 주장을 뒷받침하는 3가지 이유를 면밀히 살펴보자.   이유 #1 : 모노리포는 단일 팀 소...

2021.11.11

깃허브, ‘코드 리뷰 제한’ 기능 추가

깃허브의 새로운 관리 기능은 ‘드라이브-바이(drive-by)’ 풀 리퀘스트 승인 및 ‘스팸성(spammy)’ 변경 요청을 처리하도록 설계됐다.  지난 11월 1일(현지 시각) 깃허브가 깃(Git) 기반 버전 관리 시스템 및 코드 공유 사이트 사용자를 위해 코드 리뷰 제한을 추가하고 모바일 알림을 개선했다.  회사에 따르면 코드 리뷰 제한의 목적은 ‘드라이브-바이’ 풀 리퀘스트 승인과 스팸성 변경 요청 문제를 해결하는 것이다. 메인테이너는 이제 풀 리퀘스트에 대해 변경을 승인하고 요청할 수 있는 사용자를 제한할 수 있다.  즉, 리포지토리 수준에서 읽기 이상의 액세스 권한을 명시적으로 부여받은 사용자로 승인 및 변경 요청을 제한할 수 있다. 사용자 또는 조직 계정과 연결된 모든 리포지토리에서 코드 리뷰 제한을 활성화할 수도 있다.  리포지토리 코드 리뷰 제한을 활성화하려면 해당 리포지토리의 설정 페이지로 이동하여 왼쪽 메뉴에서 조정 설정(Moderation Settings)을 선택한다. 그다음 ‘코드 리뷰 제한(Code review limits)’을 누른 후 ‘읽기 이상의 권한이 명시적으로 부여된 사용자로 제한(Limit to users explicitly granted read or higher access)’ 상자를 체크한다.    또한 깃허브 모바일 앱에서 스팸성 이슈와 풀 리퀘스트를 처리하기 어렵다는 문제를 해결하기 위해 모바일 알림이 개선됐다. 이제 모바일 알림에 스팸 이슈 또는 풀 리퀘스트 팝업이 표시되면 쉽게 해당 이슈를 닫고, 개발자의 스마트폰에서 바로 조직의 사용자를 블록할 수 있다.    이 2가지 기능은 깃허브가 올해부터 제공하기 시작한, 오픈소스 커뮤니티의 ‘삶의 질 향상’에 초점을 맞춘 기능 중 하나다. 이를 지원하는 다른 기능은 아래와 같다.  • 문제 양식(Issue forms): 필수 필드를 포함한 양식 필드로 문제 템플릿을 생성해 문제...

깃허브 코드 공유 코드 리뷰 풀 리퀘스트 버전 관리 리포지토리 개발자 오픈소스 메인테이너

2021.11.04

깃허브의 새로운 관리 기능은 ‘드라이브-바이(drive-by)’ 풀 리퀘스트 승인 및 ‘스팸성(spammy)’ 변경 요청을 처리하도록 설계됐다.  지난 11월 1일(현지 시각) 깃허브가 깃(Git) 기반 버전 관리 시스템 및 코드 공유 사이트 사용자를 위해 코드 리뷰 제한을 추가하고 모바일 알림을 개선했다.  회사에 따르면 코드 리뷰 제한의 목적은 ‘드라이브-바이’ 풀 리퀘스트 승인과 스팸성 변경 요청 문제를 해결하는 것이다. 메인테이너는 이제 풀 리퀘스트에 대해 변경을 승인하고 요청할 수 있는 사용자를 제한할 수 있다.  즉, 리포지토리 수준에서 읽기 이상의 액세스 권한을 명시적으로 부여받은 사용자로 승인 및 변경 요청을 제한할 수 있다. 사용자 또는 조직 계정과 연결된 모든 리포지토리에서 코드 리뷰 제한을 활성화할 수도 있다.  리포지토리 코드 리뷰 제한을 활성화하려면 해당 리포지토리의 설정 페이지로 이동하여 왼쪽 메뉴에서 조정 설정(Moderation Settings)을 선택한다. 그다음 ‘코드 리뷰 제한(Code review limits)’을 누른 후 ‘읽기 이상의 권한이 명시적으로 부여된 사용자로 제한(Limit to users explicitly granted read or higher access)’ 상자를 체크한다.    또한 깃허브 모바일 앱에서 스팸성 이슈와 풀 리퀘스트를 처리하기 어렵다는 문제를 해결하기 위해 모바일 알림이 개선됐다. 이제 모바일 알림에 스팸 이슈 또는 풀 리퀘스트 팝업이 표시되면 쉽게 해당 이슈를 닫고, 개발자의 스마트폰에서 바로 조직의 사용자를 블록할 수 있다.    이 2가지 기능은 깃허브가 올해부터 제공하기 시작한, 오픈소스 커뮤니티의 ‘삶의 질 향상’에 초점을 맞춘 기능 중 하나다. 이를 지원하는 다른 기능은 아래와 같다.  • 문제 양식(Issue forms): 필수 필드를 포함한 양식 필드로 문제 템플릿을 생성해 문제...

2021.11.04

‘기트허브 CLI’ 버전 1.0 출시 

기트허브 CLI(GitHub CLI)를 사용하면 윈도우, 리눅스, 맥OS의 터미널에서 기트허브 워크플로우를 실행할 수 있다.  명령줄 도구 기트허브 CLI의 버전 1.0이 릴리즈됐다. 이 도구는 이슈에서 릴리즈에 이르기까지 터미널에서 기트허브 워크플로우를 실행할 수 있도록 해 컨텍스트 전환(context switching)을 줄이는 데 도움을 준다.    기트허브 CLI는 지난 2월 베타버전이 공개됐다. 이어서 9월 17일 출시된 기트허브 CLI 버전 1.0은 기트허브 API를 호출해 작업을 스크립팅하고 모든 명령에 사용자 지정 별칭을 설정할 수 있다.  기트허브닷컴(GitHub.com) 또는 기트허브 엔터프라이즈 서버 버전 2.20(GitHub Enterprise Server 2.20) 이상에서 호스팅되는 리포지토리를 통해 사용할 수 있다. 엔터프라이즈 서버 액세스는 베타 버전을 발표한 이후 가장 많이 요청된 기능이었다. 또한 CLI는 SSH(secure shell)와 개발자가 선호하는 편집기를 사용하도록 구성할 수도 있다. 이 밖의 다른 기능들은 다음과 같다.  • 리포지토리 생성 및 보기  • 라벨(labels)과 이슈 담당자(assignees) 추가, 닫기 및 다시 열기 • 더 많은 이슈를 풀 리퀘스트에 추가  • 이슈 및 플 리퀘스트에 메타데이터 추가 • diff 보기, 풀 리퀘스트 검토 및 병합 • gh alias set을 사용해 모든 명령에 별칭 생성 기트허브 CLI는 윈도우, 리눅스, 맥OS에서 작동한다. 자세한 사용 지침은 공식 블로그를 통해 확인할 수 있다. ciokr@idg.co.kr

기트허브 CLI 명령줄 인터페이스 윈도우 리눅스 맥OS 터미널 기트허브 워크플로우 이슈 릴리즈 컨텍스트 전환 리포지토리 SSH 풀 리퀘스트

2020.09.22

기트허브 CLI(GitHub CLI)를 사용하면 윈도우, 리눅스, 맥OS의 터미널에서 기트허브 워크플로우를 실행할 수 있다.  명령줄 도구 기트허브 CLI의 버전 1.0이 릴리즈됐다. 이 도구는 이슈에서 릴리즈에 이르기까지 터미널에서 기트허브 워크플로우를 실행할 수 있도록 해 컨텍스트 전환(context switching)을 줄이는 데 도움을 준다.    기트허브 CLI는 지난 2월 베타버전이 공개됐다. 이어서 9월 17일 출시된 기트허브 CLI 버전 1.0은 기트허브 API를 호출해 작업을 스크립팅하고 모든 명령에 사용자 지정 별칭을 설정할 수 있다.  기트허브닷컴(GitHub.com) 또는 기트허브 엔터프라이즈 서버 버전 2.20(GitHub Enterprise Server 2.20) 이상에서 호스팅되는 리포지토리를 통해 사용할 수 있다. 엔터프라이즈 서버 액세스는 베타 버전을 발표한 이후 가장 많이 요청된 기능이었다. 또한 CLI는 SSH(secure shell)와 개발자가 선호하는 편집기를 사용하도록 구성할 수도 있다. 이 밖의 다른 기능들은 다음과 같다.  • 리포지토리 생성 및 보기  • 라벨(labels)과 이슈 담당자(assignees) 추가, 닫기 및 다시 열기 • 더 많은 이슈를 풀 리퀘스트에 추가  • 이슈 및 플 리퀘스트에 메타데이터 추가 • diff 보기, 풀 리퀘스트 검토 및 병합 • gh alias set을 사용해 모든 명령에 별칭 생성 기트허브 CLI는 윈도우, 리눅스, 맥OS에서 작동한다. 자세한 사용 지침은 공식 블로그를 통해 확인할 수 있다. ciokr@idg.co.kr

2020.09.22

MS 비주얼 스튜디오 코드스페이스, 기트허브로 통합

마이크로소프트가 개발자 환경을 간소화하기 위해 ‘비주얼 스튜디오 코드스페이스(Visual Studio Codespaces)’를 ‘기트허브 코드스페이스(GitHub Codespaces)’로 통합한다고 밝혔다.    마이크로소프트 ‘비주얼 스튜디오 코드스페이스(이하 VS 코드스페이스)’가 기트허브에서 호스팅된 비주얼 스튜디오 코드(Visual Studio Code) 환경을 제공하는 ‘기트허브 코드스페이스’에 통합된다. VS 코드스페이스는 마이크로소프트 애저에서 클라우드로 호스팅된 개발 환경을 제공하는 온라인 코드편집기다. 현 애저 기반 서비스는 2021년 2월 종료된다.  마이크로소프트는 프리뷰 단계를 통해 리포지토리에서 코드스페이스로의 전환이 워크플로우에서 가장 문제가 되는 부분이라는 점, 그리고 대부분의 사용자가 통합된 네이티브 원클릭 환경을 선호한다는 사실을 발견했기 때문에 해당 서비스를 통합하게 됐다고 설명했다. 따라서 약 5,000만 명가량의 개발자가 활동하는 기트허브와 협력하는 것이 합리적이라 판단했다고 마이크로소프트 측은 전했다.  기트허브 코드스페이스는 아직 제한된 퍼블릭 베타 상태다(이곳에서 등록해 사용해볼 수 있다). 개발자가 포털이나 VS 코드 에디터를 통해 기트허브 코드스페이스를 연결하면 베타에 기트허브 계정을 추가하라는 메시지가 나타난다. 비주얼 스튜디오 코드스페이스 사용자는 기트허브 계정을 요청하는 이메일을 받게 된다.  기트허브 코드스페이스는 기트허브 리포지토리에 최적화된 환경을 제공하지만 몇 가지 추가 구성 단계를 통해 다른 곳에서 호스팅된 기트 리포지토리(예: 애저(Azure) 또는 비트버켓(Bitbucket))를 계속 사용할 수 있다. 비주얼 스튜디오 2019의 윈도우 기반 코드스페이스 지원 비공개 프리뷰도 기트허브로 이동한다. 마이크로소프트는 이번 통합과 관련한 FAQ를 공개했다. 향후 일정은 다음과 같다.  • 2020년 9월 4일: 현 사용자는 기트허브 비공개 베...

마이크로소프트 개발자 기트허브 비주얼 스튜디오 코드스페이스 기트허브 코드스페이스 클라우드 애저 개발 환경 코드편집기 워크플로우 리포지토리 비트버켓

2020.09.14

마이크로소프트가 개발자 환경을 간소화하기 위해 ‘비주얼 스튜디오 코드스페이스(Visual Studio Codespaces)’를 ‘기트허브 코드스페이스(GitHub Codespaces)’로 통합한다고 밝혔다.    마이크로소프트 ‘비주얼 스튜디오 코드스페이스(이하 VS 코드스페이스)’가 기트허브에서 호스팅된 비주얼 스튜디오 코드(Visual Studio Code) 환경을 제공하는 ‘기트허브 코드스페이스’에 통합된다. VS 코드스페이스는 마이크로소프트 애저에서 클라우드로 호스팅된 개발 환경을 제공하는 온라인 코드편집기다. 현 애저 기반 서비스는 2021년 2월 종료된다.  마이크로소프트는 프리뷰 단계를 통해 리포지토리에서 코드스페이스로의 전환이 워크플로우에서 가장 문제가 되는 부분이라는 점, 그리고 대부분의 사용자가 통합된 네이티브 원클릭 환경을 선호한다는 사실을 발견했기 때문에 해당 서비스를 통합하게 됐다고 설명했다. 따라서 약 5,000만 명가량의 개발자가 활동하는 기트허브와 협력하는 것이 합리적이라 판단했다고 마이크로소프트 측은 전했다.  기트허브 코드스페이스는 아직 제한된 퍼블릭 베타 상태다(이곳에서 등록해 사용해볼 수 있다). 개발자가 포털이나 VS 코드 에디터를 통해 기트허브 코드스페이스를 연결하면 베타에 기트허브 계정을 추가하라는 메시지가 나타난다. 비주얼 스튜디오 코드스페이스 사용자는 기트허브 계정을 요청하는 이메일을 받게 된다.  기트허브 코드스페이스는 기트허브 리포지토리에 최적화된 환경을 제공하지만 몇 가지 추가 구성 단계를 통해 다른 곳에서 호스팅된 기트 리포지토리(예: 애저(Azure) 또는 비트버켓(Bitbucket))를 계속 사용할 수 있다. 비주얼 스튜디오 2019의 윈도우 기반 코드스페이스 지원 비공개 프리뷰도 기트허브로 이동한다. 마이크로소프트는 이번 통합과 관련한 FAQ를 공개했다. 향후 일정은 다음과 같다.  • 2020년 9월 4일: 현 사용자는 기트허브 비공개 베...

2020.09.14

'뜻밖의 선물'같은 팁··· '깃(Git)' 고급 명령어 5가지

더 깔끔한 커밋, 더 스마트한 디버깅, 더 세련된 리포지토리를 위해 한 단계 업그레이드된 깃 기술들을 마스터하라.  오늘날 개발자 대부분은 소프트웨어 워크플로우의 핵심인 버전 관리 시스템 깃(Git)을 배웠을 가능성이 크다. 그리고 기본 개념과 명령어도 당연히 알고 있을 것이다. 이를테면 리포지토리(repositories) 작동 방식, 브랜치(branch)를 만들고 변경사항을 커밋(commit)하는 방법, 변경사항을 머지(merge)하고 풀 리퀘스트(pull request)하는 방법 등이다. 기본을 잘 알고 있다면 이제 수준을 조금 높여야 할 때다. 워크플로우에서 깃의 더욱 강력한 기능들을 활용할 수 있도록 말이다.    1. git rebase로 커밋 히스토리 단순화하기 한 프로젝트에 2개의 브랜치(예: 개발 브랜치와 마스터 브랜치)가 있고, 두 브랜치를 결합해야 하는 변경사항이 있다고 가정해보자. 이때 git merge 명령어는 이들을 통합하는 간단한 방법이다.  merge는 한 브랜치의 개발 히스토리를 다른 브랜치의 머지 커밋으로 추가한다. 이를 통해 두 히스토리를 온전히 보존할 순 있지만 전체 프로젝트 히스토리를 파악하기 어려울 수 있다. 더 단순하고 깔끔한 결과를 원한다면 git rebase가 도움이 된다.  git rebase 명령어도 2개의 브랜치를 머지하지만 약간 다르게 진행된다. git rebase는 한 브랜치가 생성된 지점부터 다른 브랜치가 통합될 수 있도록 커밋 히스토리를 다시 쓴다. 즉 덜 복잡하고 선형적인 커밋 히스토리를 만들 수 있는 것이다. 하지만 이 과정에서 다른 브랜치 및 머지 프로세스와 관련해 유용할 수도 있는 세부정보가 제거된다는 점을 유의해야 한다.  따라서 rebase는 공용(public) 브랜치와 머지하기 전에 하나의 깔끔한 커밋 히스토리로 통합하려는 여러 비공개(private) 브랜치가 있을 경우 특히 유용하다. 이를 통해 프로젝트의 커밋 히스토리와 관련...

개발자 커밋 디버깅 리포지토리 브랜치 머지 풀 리퀘스트 깃 리베이스 스쿼시 버그 코드 체리픽 서브모듈

2020.06.12

더 깔끔한 커밋, 더 스마트한 디버깅, 더 세련된 리포지토리를 위해 한 단계 업그레이드된 깃 기술들을 마스터하라.  오늘날 개발자 대부분은 소프트웨어 워크플로우의 핵심인 버전 관리 시스템 깃(Git)을 배웠을 가능성이 크다. 그리고 기본 개념과 명령어도 당연히 알고 있을 것이다. 이를테면 리포지토리(repositories) 작동 방식, 브랜치(branch)를 만들고 변경사항을 커밋(commit)하는 방법, 변경사항을 머지(merge)하고 풀 리퀘스트(pull request)하는 방법 등이다. 기본을 잘 알고 있다면 이제 수준을 조금 높여야 할 때다. 워크플로우에서 깃의 더욱 강력한 기능들을 활용할 수 있도록 말이다.    1. git rebase로 커밋 히스토리 단순화하기 한 프로젝트에 2개의 브랜치(예: 개발 브랜치와 마스터 브랜치)가 있고, 두 브랜치를 결합해야 하는 변경사항이 있다고 가정해보자. 이때 git merge 명령어는 이들을 통합하는 간단한 방법이다.  merge는 한 브랜치의 개발 히스토리를 다른 브랜치의 머지 커밋으로 추가한다. 이를 통해 두 히스토리를 온전히 보존할 순 있지만 전체 프로젝트 히스토리를 파악하기 어려울 수 있다. 더 단순하고 깔끔한 결과를 원한다면 git rebase가 도움이 된다.  git rebase 명령어도 2개의 브랜치를 머지하지만 약간 다르게 진행된다. git rebase는 한 브랜치가 생성된 지점부터 다른 브랜치가 통합될 수 있도록 커밋 히스토리를 다시 쓴다. 즉 덜 복잡하고 선형적인 커밋 히스토리를 만들 수 있는 것이다. 하지만 이 과정에서 다른 브랜치 및 머지 프로세스와 관련해 유용할 수도 있는 세부정보가 제거된다는 점을 유의해야 한다.  따라서 rebase는 공용(public) 브랜치와 머지하기 전에 하나의 깔끔한 커밋 히스토리로 통합하려는 여러 비공개(private) 브랜치가 있을 경우 특히 유용하다. 이를 통해 프로젝트의 커밋 히스토리와 관련...

2020.06.12

'오픈소스를 지탱하는 힘은 클라우드 업체' AWS까지 코드 기여에 적극적

누군가는 사악한 클라우드 업체들이 연약한 오픈소스 커뮤니티에서 단물만 빨아먹고 기여는 거의 하지 않아서 오픈소스가 고사할 위기에 처했다고 말한다. 뿌리가 꽤 깊은 이 이야기에 영향을 받은 몇몇 예언가들은 오픈소스의 지속 가능성이 곧 끝을 맞이한다고 주장한다. 그러나 데이터를 통해 본 상황은 이 예언과는 전혀 다르다. 두 건의 독립적인 깃허브(GitHub) 데이터 및 CNCF 데이터 분석에 따르면 오픈소스 프로젝트의 가장 큰 기여자는 다름아닌 퍼블릭 클라우드 서비스 업체들이다. 이들 업체의 비즈니스는 소프트웨어 판매가 아닌 운용이며, 바로 그 이유로 앞으로 오랜 기간 오픈소스 파괴가 아닌 번성을 이끌 가장 적합한 위치에 있다.   나무가 아닌 숲의 오픈소스화 잘 살펴보면 꽤 오래 전부터, 특히 마이크로소프트와 구글은 가장 크고 공개적인 오픈소스 프로젝트 기여자 역할을 해왔다. 개발자에게 다가가고자 하는 지배적인 플랫폼 기업에 오픈소스는 선택이 아닌 필수다. 마이크로소프트는 애저에서 다양한 오픈소스 프로젝트의 실행을 개방하거나 지원하는 방법으로 오픈소스에 입성했고, 구글은 한걸음 더 나아가 쿠버네티스, 텐서플로우와 같은 강력한 코드를 아예 오픈소스화했다. 오픈소스에 거의 기여하지 않기로 유명했던 클라우드 선두업체인 아마존 웹 서비스도 더 이상 오픈소스 커뮤니티를 옆에서 구경만 하고 있을 수는 없는 상황이다. 사실 AWS는 사람들이 생각하는 것보다는 오픈소스 분야에서 많은 활동을 해왔지만, 2018년부터 오픈소스 참여를 대대적으로 확대했다. 620만 개의 깃허브 프로필과 각각의 기여 내역을 다룬 어도비 개발자 필 마즈의 분석을 보면 이러한 업계의 움직임이 명확하게 드러난다. 물론 이 분석은 비정밀 과학이고 아파치 프로젝트와 같은 굵직한 코드 저장소도 빠졌다. 그러나 GitHub.com 사용자-기업 관계에 대한 마즈의 분석은 많은 신호를 담고 있으며, 그 신호는 “클라우드가 오픈소스를 이끌고 있다”는 사실을 보여준다. 아래 표...

클라우드 커뮤니티 깃허브 기트허브 리포지토리 저장소 코드기여

2019.02.28

누군가는 사악한 클라우드 업체들이 연약한 오픈소스 커뮤니티에서 단물만 빨아먹고 기여는 거의 하지 않아서 오픈소스가 고사할 위기에 처했다고 말한다. 뿌리가 꽤 깊은 이 이야기에 영향을 받은 몇몇 예언가들은 오픈소스의 지속 가능성이 곧 끝을 맞이한다고 주장한다. 그러나 데이터를 통해 본 상황은 이 예언과는 전혀 다르다. 두 건의 독립적인 깃허브(GitHub) 데이터 및 CNCF 데이터 분석에 따르면 오픈소스 프로젝트의 가장 큰 기여자는 다름아닌 퍼블릭 클라우드 서비스 업체들이다. 이들 업체의 비즈니스는 소프트웨어 판매가 아닌 운용이며, 바로 그 이유로 앞으로 오랜 기간 오픈소스 파괴가 아닌 번성을 이끌 가장 적합한 위치에 있다.   나무가 아닌 숲의 오픈소스화 잘 살펴보면 꽤 오래 전부터, 특히 마이크로소프트와 구글은 가장 크고 공개적인 오픈소스 프로젝트 기여자 역할을 해왔다. 개발자에게 다가가고자 하는 지배적인 플랫폼 기업에 오픈소스는 선택이 아닌 필수다. 마이크로소프트는 애저에서 다양한 오픈소스 프로젝트의 실행을 개방하거나 지원하는 방법으로 오픈소스에 입성했고, 구글은 한걸음 더 나아가 쿠버네티스, 텐서플로우와 같은 강력한 코드를 아예 오픈소스화했다. 오픈소스에 거의 기여하지 않기로 유명했던 클라우드 선두업체인 아마존 웹 서비스도 더 이상 오픈소스 커뮤니티를 옆에서 구경만 하고 있을 수는 없는 상황이다. 사실 AWS는 사람들이 생각하는 것보다는 오픈소스 분야에서 많은 활동을 해왔지만, 2018년부터 오픈소스 참여를 대대적으로 확대했다. 620만 개의 깃허브 프로필과 각각의 기여 내역을 다룬 어도비 개발자 필 마즈의 분석을 보면 이러한 업계의 움직임이 명확하게 드러난다. 물론 이 분석은 비정밀 과학이고 아파치 프로젝트와 같은 굵직한 코드 저장소도 빠졌다. 그러나 GitHub.com 사용자-기업 관계에 대한 마즈의 분석은 많은 신호를 담고 있으며, 그 신호는 “클라우드가 오픈소스를 이끌고 있다”는 사실을 보여준다. 아래 표...

2019.02.28

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.5.0.5