Github 협업, 이것만은 알자

깃허브는 코드의 저장 및 버전관리, 그리고 협업 등 개발에 있어 필요한 효율적이고 다양한 기능을 제공하는 코드 웹 호스팅 플랫폼입니다.대부분의 필수 기능들이 무료이기 때문에 많은 개발자 및 기업들이 채택하여 프로젝트를 관리하기 위해 이용하고 있습니다.깃허브 내에서는 많

Organization 은 깃허브에서 제공하는 협업을 위한 그룹 기능입니다.해당 기능을 통해 여러 사람들과 그룹을 형성하여 효과적으로 프로젝트를 관리할 수 있습니다.Repository는 하나의 프로젝트를 관리하는 저장소 단위입니다.굳이 Organization을 만들지

Repository란 프로젝트의 파일과 코드를 업로드해두고 관리할 수 있는 실질적인 프로젝트 저장소입니다.이제 방금 생성한 Organization에 Repository를 만들어보겠습니다.

브랜치는 본질적으로 독립적인 개발 라인입니다. 새 기능이나 버그 수정 작업을 할 때마다기존 브랜치에서 각기 다른 브랜치를 분기하여 다른 작업과 분리할 수 있습니다.또한 별도의 브랜치를 하나의 브랜치로 병합(Merge)할 수 있습니다.브랜치마다 이름을 붙일 수 있으며,

이슈(Issue)란 프로젝트에서 작업해야할 단위라고 할 수 있습니다.개발해야하는 기능 발생, 수정해야할 사항 버그 발생, 리팩터링 해야하는 코드 발생 등 프로젝트에서 발생되는 작업들을 이슈로 생성하여 관리합니다.이슈를 생성하여 관리하면, 이슈에 대한 커밋 내역들을 하나

드디어 Code Review를 할 차례입니다!위에서 말씀드렸다시피, 코드 리뷰는 정말 중요한 과정입니다.코드 리뷰를 통해 운영 중에 발생해서는 안 될 큰 버그를 막을 수도 있으며,계속해서 보고 있던 자신의 코드이기 때문에 감각이 흐려져 미처 발견하지 못한 작은 실수들을

Merge 어라 머지를 하러 왔는데 종류가 3가지나 있네요..! 무슨 말일까요? 🤔 Create a merge commit 이 옵션을 선택하면 GitHub는 PR branch와 base branch의 변경 내용을 하나의 새로운 병합 커밋으로 합칩니다. 이 병합

지금까지 배운 내용들을 보면서 혹시 이런 생각이 들었던 분 없으신가요? 🤔 “PR이나 Issue를 작성할 때, 뭘 기준으로 작성해야하지?”🤔 “반복되는 내용도 새로운 Issue나 PR을 생성할 때마다 작성해야하는 거야?”

Stash를 알게되면 깃을 사용하는 작업에 새로운 눈이 뜨이게 됩니다.

github를 통해 형상관리를 수행하며 개발하다보면,실수로 커밋을 다른 브랜치에 하게되어 문제가 발생하는 경우가 있다. 이때 Cherry-pick이 당신을 구원해줄 것이다.