깃허브의 흐름은 배포가 정기적으로 이루어지는 팀이나 프로젝트를 지원하는 간단한 브렌치(분기된 코드) 기반 작업 흐름 입니다. 이 가이드는 깃허브 흐름이 어떻게 작동하고 왜 그렇게 되는지 설명합니다.
브렌치(Branch) 생성하기
프로젝트를 진행할 때는 여러가지 기능이나 아이디어들이 작업 중일 겁니다. 그 중 일부는 완성본에 포함될 수도 있고 다른 일부는 포함될 준비가 되지 않았을 수도 있습니다. 브렌치는 이러한 작업의 흐름을 관리하는 것을 돕기 위해서 있습니다.
프로젝트에서 브렌치를 만들면 새로운 아이디어를 시험해 볼 수있는 환경을 만들어진 것입니다. 브렌치에서 변경 한 사항은 마스터 지사에 영향을 미치지 않으므로 자유롭게 실험하고 변경 사항을 적용 할 수 있습니다. 브렌치는 함께 작업하는 누군가가 검토하기 전에는 메인 브렌치에 병합되지 않을 것이라는 점을 알고 있기에 안전합니다.
- 조언 한마디
브렌치는 Git의 핵심 개념이며 전체 깃허브 흐름은 이를 기반으로 합니다. 딱 한가지 규칙이 있다면, 마스터 브렌치의 모든 항목은 항상 배포가 가능하다는 점입니다.
이런 점 때문에 새로운 기능을 만들때나 기능을 수정할때 새 브렌치(분기코드)를 마스터에서 복사하여 생성한다는 점이 매우 중요합니다. 다른 사람이 현재 내가 작업중인 것을 볼수도 있기 때문에, 브렌치 이름을 봤을때 작업을 이해할 수 있으면 좋습니다. (예를들면, 리팩터 인증, 사용자 콘텐츠 캐시 키, 레티나-아바타 만들기)
커밋 추가하기
여러분이 브렌치를 만들었다면, 이제 뭔가 변경을 해볼 순서 입니다. 여러분이 파일에 뭔가를 추가,변경,삭제할 때마다, 커밋(commit)을 만드는 것이고 그것들을 여러분의 브렌치에 추가 할 수 있습니다. 커밋을 추가하는 이런 과정은 보통 feature라고 하는 여러분의 브렌치에서 작업 할 때 진행 상황을 추적합니다.
커밋은 다른 사람들이 여러분이 한 일의 내용과 그 이유를 이해할수 있도록 투명한 기록을 남기는 것입니다. 각 커밋에는 관련된 변경 메시지가 있으며, 이는 특정 변경이 이루어진 이유를 설명하는 글입니다. 또한 각각의 커밋은 개별적인 변경 단위로 간주됩니다. 이런점들은 버그가 발견되거나 다른 방향으로 가기로 한 경우 변경 사항들을 되돌릴(rollback;롤백) 수 있습니다.
- 조언 한마디
커밋 메세지는 특히 중요합니다. 특히 Git은 변경사항들이 서버에 합쳐질 때, 변경 사항을 추적하고 커밋으로 표시하기 때문에 중요합니다. 명확한 커밋 메시지를 작성하였다면, 다른 사람들이 커밋을 쉽게 이해하고 커밋에 대한 피드백을 제공 할 수 있습니다.
당겨짐 요청(Pull Request) 생성하기
당겨짐 요청을 생성한다는 것은 여러분의 커밋에 대해서 토론을 시작하는 것을 의미합니다. 커밋들은 기본적인 Git 저장소와 긴밀하게 통합되어 있기 때문에 검토자들이 여러분의 당겨짐 요청을 받아들이면 누구라도 어떤 변경 사항이 통합될지 볼 수 있습니다.
여러분은 개발 과정 중에 언제든지 당겨짐 요청(Pull Request)을 생성할 수 있습니다. 즉 코드가 거의 없지만, 어떤 스크린 샷이나 좋은 아이디어를 공유하고 싶은 경우, 하다가 막혀서 다른 사람의 도움이나 조언이 필요한 경우, 또는 다른 누군가가 여러분의 작업을 검토해 주기를 바라는 경우등에 당겨짐 요청(Pull Request)을 생성할 수 있습니다. 당겨짐 요청 메세지에서 @멘션(@mention) 기능을 활용하면, 지구 반대편에 있는 특정 사람이나 팀에게도 피드백을 요청 할 수 있습니다.
- 조언 한마디
당겨짐 요청은 오픈 소스 프로젝트에 기여하고 공유 저장소에 대한 변경을 관리하는 데 유용합니다. 분기와 병합(Fork & Pull) 모델을 사용하는 경우, 당겨짐 요청은 프로젝트 관리자에게 여러분이 반영하고 싶은 변경사항들을 알리는 역할을 합니다. 공유 저장소 모델을 사용하는 경우, 당겨짐 요청은 제안된 변경 사항에 대한 코드 검토와 토론을 시작하는데 사용이 됩니다. 물론 변경사항이 마스터 분기에 병합하기 전에 말이죠.
여러분의 코드를 검토하고 토론하기
당겨짐 요청이 생성되면, 여러분의 제안한 변경 사항을 검토하는 사람(혹은 팀)은 질문이나 의견이 있을 수 있습니다. 아마도 코딩 스타일이 프로젝트 지침과 일치 하지 않을 수도 있고, 단위 테스트가 없거나, 아니면 정말 잘했다고 하거나 장점들을 나열 할지도 모릅니다. 당겨짐 요청은 이런 유형의 대화를 장려하도록 설계되었습니다.
또한 커밋에 대한 토론과 피드백을 토대로 계속해서 여러분의 브렌치에 추가(push)할 수 있습니다. 누군가 당신이 뭔가를 놓쳤다고 하거나 코드에 버그가있는 경우 여러분의 브렌치에서 수정하고 변경 사항을 적용 할 수 있습니다. 깃허브는 "통합 당겨짐 요청화면"에서 새로운 커밋과 추가 피드백을 보여줍니다.
- 조언 한마디
당겨짐 요청 댓글은 Markdown에 작성되고, 이모티콘이나 이미지를 넣거나 미리 작성된 간단한 텍스트 블록이나 간단한 서식을 사용할 수 있습니다.
배포하기
일단 당기기 요청이 검토가 되고, 브렌치가 테스트를 통과하면, 여러분은 여러분의 변경사항들을 배포하여 실운영(제품) 환경에서 확인해볼 수 있습니다. 여러분의 브렌치에서 문제가 발생하면 기존 마스터 브렌치를 실 운영(제품)에 다시 배포하여 롤백(되돌림) 할 수 있습니다.
통합하기
현재 변경 사항이 운영(제품) 환경에서 확인되었으므로 코드를 마스터 분기에 병합해야합니다.
병합되면, 당기기 요청은 코드의 변경 기록들을 보존합니다. 기록들은 검색 가능하기 때문에, 언제 어디서나 결정을 내린 이유와 방법을 이해할 수 있습니다.
- 조언 한마디
특정 키워드를 당겨짐 요청에 있는 텍스트와 연결해 봄으로써 여러분은 발생한 이슈와 연관된 코드를 찾을 수도 있습니다. 당겨짐 요청이 병합되면 관련 문제(issue)도 닫힙니다. 예를 들어 Closes #32 라고 입력하면, 저장소에 있는 32번 문제(이슈)가 종료됩니다. 더 자세한 내용은 도움말을 확인해 보시기 바랍니다.
from. https://guides.github.com/introduction/flow/
도움이 되셨나요?^^
