이동식 저장소

지금까지의 글을 통해 우리는 브랜치를 만들고, 만든 브랜치를 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..

저는 Github를 2년 남짓 사용하면서 협업을 해 본 적이 없습니다. 오픈 소스의 성지에서 독방 작업만을 한 셈이죠.. Github을 마치 원격 코드 저장소로만 사용했습니다. 그러다가 어떤 조별과제 때문에 Github의 협업 기능을 본격적으로 이용해야 하는 상황이 되었습니다. 이제 단순히 master에 커밋하고 푸시만 하는 수준으로는 안 된다는 생각이 들어, 본격적으로 협업 기능을 사용해 보려 합니다. 이 글은 Github를 처음 사용하는 초보 개발자를 위한 글이기도 하지만, 동시에 저와 우리 조원들을 위한 글이기도 합니다. 물론 저도 초보 개발자입니다. 브랜치란 무엇인가? 마이크로소프드의 Windows 10도 Github에서 개발되고 있다고 합니다. 수백, 수천 명의 개발자가 동시에 코드를 수정하고 ..