Programing/Git20 GitHub로 협업 하기 학습 출처 | 유튜브 코딩알려주는누나 Git과 GitHub에 대한 개념이 있더라도 이를 통해 팀원들과 협업하는 과정은 어렵다. 별도로 학습해야 할 필요가 있다. 이 내용을 학습하려면 Git과 GitHub에 대한 이해가 선행되어야 한다. 학습 순서 Repository 생성 팀원 초대 프로젝트 환경설정 develop 브랜치 생성 master 브랜치 보호 프로젝트 보드 생성 Git issue 생성 feature 브랜치 생성 팀원 역할 시작 (협업 시작) 프로젝트 클론 feature 브랜치 생성 개발 진행 소스코드 업로드 풀 리케스트 (PR) 생성 코드리뷰 깃 충돌 해결하기 develop 브랜치에 최신 코드 가져오기 다시 feature 브랜치로 돌아가기 feature 브랜치에서 develop 브랜치와 merge.. Programing/Git 2024. 3. 16. 더보기 ›› [빠르게 git] Branch를 이용한 협업 개념 협업의 전통적인 방법 기존에는 협업을 할 때 역할을 나눈 개발자들이 각자의 소스코드를 작성해서 소스코드 파일을 주고 받아 하나로 합치는 작업을 했다. 그런데 이 과정에서 상대방의 소스코드와 내 소스코드를 합치려면 상대방의 소스코드와 충돌이 나지 않는지, 겹치는 부분은 없는지 모든 소스코드를 확인해야 했기 때문에 내가 작업한 코드 이외에도 상대방의 소스코드를 전체를 이해해야 하는 번거로움이 더해졌었다. Branch를 이용한 협업 Branch는 나뭇가지를 말한다. 하나의 나무에 여러 나뭇가지가 있는 것처럼 각자 맡은 파트를 개발자들은 나뭇가지를 만들듯이 그 나뭇가지에서만 만들고 Git 통해서 하나로 합치면 된다. 이렇게 되면 파트별로 분야를 나누어 공간을 나누면서 작업할 수 있는 장점이 있다. 예를 들.. Programing/Git 2024. 3. 15. 더보기 ›› [빠르게 git] Git 버전 복구 (백업) 개념 Git으로 버전관리 하고 있는 것을 실수나 착오로 인해 이전 버전으로 되돌릴 수 있는 백업 기능을 사용 하는 방법이다. 기본 명령어 git reset 수정범위 옵션 의미 수정한 것 통째로 --hard HEAD^ 강력히 add한 것까지만 --mixed HEAD^ 적당히 commit한 것까지만 --soft HEAD^ 살짝만 git reset 명령어는 한 번이라도 commit된 파일에 대해서만 작동한다. 응용 $ git reset --hard HEAD^ $ git reset --mixed HEAD^ $ git reset --soft HEAD^ HEAD : 가장 최근 버전에서 ^ : 한 개를 되돌려라 (^^ 두개 ...) git reset의 default 값이 --mixed 이기 때문에 --mixed를 하.. Programing/Git 2024. 3. 15. 더보기 ›› [빠르게 git] GitHub 시작하기 의미 앞서 Git Bash를 통해 내 로컬 저장소를 통해 Staging Area를 만들고 버전관리를 하는 방법에 대해 알아 보았다. 그런데 이것은 우리 로컬 저장소에서 관리하는 것이기 때문에 다른 사람과 협업하기는 마찬가지로 어렵다. 그래서 GitHub와 같은 서비스가 등장했고, GitHub는 각자의 컴퓨터에만 존재하는 버전을 저장하고 관리해주는 클라우드 서비스이다. 개념 우리 PC, 즉 로컬 저장소에서 원격 저장소로 파일을 Push(업로드)하여 클라우드 서비스에 업로드 하는 개념. 회원가입 GitHub 접속 회원가입 진행 Free 요금제와 매달 7달러의 Pro 요금제가 있는데 일반 사용자는 Free 선에서 충분하다. 요금제 스토리지 데이터 전송량(월별) 가격 Free 500mb 1gb 무료 Pro 2g.. Programing/Git 2024. 3. 15. 더보기 ›› [빠르게 git] Git 시작하기 (개념, 설치, init, add, commit) Git의 기본 개념 : 버전이 만들어지는 두 개의 단계 버전이 되기까지 거쳐가는 세 개의 공간이 있다. Working directory (작업 공간) 내가 코드작업을 하는 공간 / 파일들이 생성, 수정, 삭제되는 공간 /변경사항이 생기는 공간 작업 공간에 있는 모든 파일을 버전 관리할 필요는 없다. 임시로 작업 중인 파일도 있을 것이고, 만들다 실수한 파일도 뒤섞여 있을 것이기 때문에 유의미한 변화가 일어난 최종 파일을 버전 관리하는 것이지 이 모든 공간을 버전관리 할 필요는 없고 선별된 파일만 버전 관리 하면 된다. Staging Area (무대) 버전이 될 후보들이 올라오는 공간(무대) Repository 최종 버전들이 저장되어 있는 공간 위의 순서를 거쳐가며 Working directory에서 St.. Programing/Git 2024. 3. 15. 더보기 ›› 이전 1 2 3 4 다음