이동식 저장소

모듈을 여러 개 작성하다 보면 ``build.gradle`` 파일이 복잡해지곤 한다. 같은 라이브러리를 여러 번 작성하다 보면 오타가 날 수도 있고, 버전 관리가 힘들어지기도 한다. 당장 위의 ``:database`` 모듈에서도 junit 라이브러리를 하나만 사용함에도 불구하고 bom으로 선언하는 오류가 있다. Gradle의 기능을 사용하면 버전 관리를 쉽게 할 수 있다. 이름하여 Version Catalog! Version Catalog 카탈로그는 상품 목록 등을 한 곳에 모아놓아 보기 쉽게 정리한 것이다. 단어 그대로 Version Catalog는 앱에서 사용하는 라이브러리를 모아놓은 파일이다. 라이브러리를 사용하고 싶다면 catalog에서 선택하기만 하면 된다. 버전 관리는 catalog에서 알아서..

모든 unit test를 실행하는 커맨드는 다음과 같다. gradlew test Android test를 실행하는 커맨드는 다음과 같다. gradlew connectedAndroidTest 놀랍게도 ``connectedAndroidTest``의 앞 글자만 따서 실행할 수도 있다. gradlew cAT

Gradle 빌드를 실행하는 방법에는 여러 가지가 있지만, 공식 문서에서 추천하는 방법은 Gradle Wrapper(이하 wrapper)를 통해 실행하는 것이다. Wrapper는 특정 버전의 Gradle을 실행하는 스크립트로, 시스템에 해당 버전의 Gradle이 없다면 자동으로 설치해 준다. 따라서 개발자가 사용할 버전을 정의하기만 하면 wrapper가 해당 버전을 설치하고, 실행하게 된다. Wrapper가 꼭 필요한가? 시스템에 프로젝트가 하나만 있다면 상관없겠지만, 여러 프로젝트에서 모두 다른 버전의 Gradle을 사용한다면 어떨까? 귀찮게도 프로젝트마다 일일이 Gradle을 설치해야 한다. 버전을 바꾸고 싶다면 역시 수동으로 설치해야 한다. 이런 귀찮은 일을 wrapper가 대신 해주는 것이다. 사..

지금까지의 글을 통해 우리는 브랜치를 만들고, 만든 브랜치를 master로 병합할 수도 있게 되었습니다. 그런데 충돌을 해결했다고 무작정 master로 병합하는 것이 적절할까요? 예를 들어 신입 A가 master에 코드를 병합하기 전에 선임 B의 검토를 거쳐야 하는 상황이 있을 수 있습니다. 이런 경우에는 A가 (설령 권한이 있다고 해도) 직접 master로 병합하는 대신, 코드를 검토해 달라는 요청을 B에게 보낼 필요가 있습니다. Git의 pull request 기능을 이용하여 보다 더 수월하게 협업해 봅시다. Pull request 만들기 우선 pull request를 보낼 커밋을 만들어야 합니다. 제 브랜치 branch-mwy에서 테스트 커밋을 하나 올리고 push해 보겠습니다. 아직 이 커밋은 m..

이전 글에서 브랜치에 대해 살펴봤습니다. 브랜치란 프로젝트의 버전을 나누어 서로 독립적으로 개발할 수 있도록 하는 개념입니다. 그런데 아무리 코드를 나눠서 작성했다고 한들, 결국 하나로 코드를 모아야 완전한 결과물을 만들 수 있습니다. Merge(병합)을 이용하여 코드를 합쳐 봅시다. 병합이란? 병합은 두 버전의 합집합을 구하는 것과 같습니다. 예를 들어 제가 브랜치 b1에서 수정한 코드 A.java와 다른 조원께서 브랜치 b2에서 수정한 코드 B.java를 master 브랜치로 모으는 것이죠. 이런 경우에는 전혀 어렵지 않게 병합할 수 있습니다. A.java와 B.java를 master로 당겨 오기만 하면 됩니다. 위의 예시에서 b1과 b2가 합쳐진 결과는 master에 반영됩니다. 병합한 결과를 제3..