▶ 제품설명
GitHub 란?
GitHub는 효율적인 작업을 위한 개발 플랫폼입니다. 오픈 소스에서 비즈니스에 이르기까지 수백만 명의 다른 개발자와 함께 코드를 호스팅 및 검토하고 프로젝트를 관리하며 소프트웨어를 구축 할 수 있습니다.
한마디로 “코드를 공유/공개 하는 서비스 + 프로그래머를 위한 SNS” 라고 할 수 있습니다.
Git은 버전 관리 시스템의 일종
어떤 타입의 문서든 모든 단계의 초안이나 업데이트 기록을 저장, 관리하는 파일시스템 및 중앙관리 저장소(Repository)
GitHub = Git을 사용하기 위한 Hub
- Git Repository 를 호스팅하는 서비스
- Web에서 GUI를 제공한다.
- 보안을 위한 접근제어를 제공한다.
- 협업을 위한 Wiki 및 작업도구 등을 제공한다.
▶ 제품기능
브랜치 생성 : 원하는 기능의 단계별 가지(Branch) 를 만듭니다.
프로젝트는 메인 아이디어와 부분적으로 이를 보충하고 수정 및 변경하는 의견과의 끊임 없는 상호작용으로 진행 됩니다. 아이디어의 일부는 즉시 실행에 옮길 수 있지만 기술적으로 제한 되는 부분도 존재 합니다. 따라서 작업자는 메인 디렉토리의 손해를 감수할 필요 없이 새로운 아이디어를 즉시 실행해볼 수 있는 새로운 워크 플로우를 필요로 합니다.
브랜치는 워크 플로우를 관리 합니다.
프로젝트에서 브랜치를 만드는 것은, 바로 새로운 아이디어를 시험해 볼 수 있는 환경을 조성하는 것입니다. 브랜치에서 변경 한 사항은 마스터 브랜치에 영향을 미치지 않으므로 자유롭게 실험하고 변경 사항을 적용 할 수 있습니다.
브랜치에 함께 작업하는 누군가가 검토를 완료할 때까지 마스터 브랜치에 병합되지 않으니 어떤 변경을 적용해도 문제가 없습니다.
커밋 추가: 커밋을 추가하여 진행 상황을 추적 하세요.
브랜치가 만들어지면 이제 개발을 시작해야합니다. 파일을 추가, 편집 또는 삭제할 때마다 커밋을 하고 브랜치에 추가합니다. 커밋을 통해 브랜치에서 작업 할 때 진행 상황을 추적 및 관리 할 수 있습니다.
커밋은 다른 사람이 수행 한 작업의 이유와 결과를 보여주는 투명한 작업 기록을 만듭니다. 각 커밋에는 관련 변경 기록을 알리는 메시지가 있으며, 이는 특정 변경이 이루어진 이유를 설명 합니다. 또한 각 커밋은 별도의 변경 단위로 간주됩니다. 이렇게 하면 버그가 발견되거나 다른 방향으로 나아 가기로 결정한 경우 변경 사항을 롤백 할 수 있습니다.
Pull Request: 병합 전에 Pull Request 하여 안전하게 개발하세요.
Pull Request는 커밋에 대한 토론 과정으로 볼 수 있습니다. GitHub는 Git 저장소와 긴밀하게 통합되어 있기 때문에 풀 리퀘스트를 수락하면 누구나 어떤 변경 내용이 병합될 지 사전에 알아볼 수 있습니다.
개발 프로세스 중 언제든지 Pull Request 요청을 열 수 있습니다. 코드가 거의 없거나 일부 화면 캡처 나 일반적인 아이디어를 공유하려는 경우, 진행이 어려워 도움이 필요할 때, 심지어 누군가에게 코드리뷰를 요청하고 싶을 때 사용할 수 있습니다. Pull Request 메시지에서 GitHub의 @hongildong 과 같이 멘션 시스템을 사용하여 특정 사람이나 팀 등 전 세계 누구에게나 피드백을 요청할 수 있습니다.
코드 리뷰: 함께 리뷰하고 오류를 최소화 하세요.
Pull Request가 열리면 변경 사항을 검토하는 사람이나 팀에 질문이나 의견 요청이 가능합니다.. 아마도 코딩 스타일이 프로젝트 가이드 라인과 일치하지 않을 수도 있고, 단위 테스트가 없을 수도 있고, 한편 모든 것이 잘 어울리고 순서대로 정렬되어 있을 수도 있습니다. Pull Request는 이러한 유형의 대화를 원활하게 진행할 수 있도록 설계되었습니다.
또한 커밋에 대한 토론과 피드백을 토대로 계속해서 브랜치로 푸시 할 수 있습니다. 어떤 사람이 뭔가를 누락하였거나, 코드에 버그가 있는 경우 다른 사람이 해당 버그를 수정하고 변경 사항을 적용 할 수 있습니다. GitHub는 새로운 커밋과 통합 Pull Request 보기에서 나타날 수 있는 추가 피드백을 보여줍니다.
배포: 테스트 후 배포하여 프로젝트 오류를 최소화 하세요.
GitHub를 사용하면 마스터에서 병합하기 전에 브랜치에서 배포하여 최종 테스트를 수행 할 수 있습니다.
끌어 오기 요청을 검토하고 특정 브랜치가 테스트를 통과하면 변경 내용을 배포하여 프로덕션 환경에서 이를 확인할 수 있습니다. 브랜치에서 문제가 발생하면 기존 마스터 브랜치를 프로덕션 환경에 재배포하여 롤백 할 수 있습니다.
병합: 최종 코드 및 브랜치를 병합하여 빠르게 제품을 출시하세요.
이제 변경 사항이 프로덕션 환경에서 확인되었으므로 코드를 마스터 브랜치에 병합해야 합니다.
일단 병합되면 Pull Request 기능으로 코드의 변경 기록은 보존됩니다. 그리고 검색이 가능하기 때문에 나중에 다른 개발자가 와도 그 결정을 내린 이유와 방법을 이해할 수 있습니다.
▶ 제품 에디션 비교