git / GitHub

Park Bumsoo·2022년 6월 5일
0

프로젝트를 진행하며 처음으로 git을 통한 협업을 해보았다.
개인 프로젝트를 진행하며 한개의 master branch를 통해 코드와 버전을 관리 하였기 때문에
처음엔 많은 어려움을 겪게 되었다. 그래서 글을 쓰며 내용을 정리하고자 한다.

git과 GitHub

gitlocal 영역내에서 본인의 소스코드와 버전을 관리해 주는 프로그램이다.
주로 git hub와 많이 연관을 지어서 두개가 비슷한 것이 아니냐? 라는 의문이 생기기도 하는데

GitHub로컬 영역이아닌 웹 호스팅 서비스로서 협업 단계에서의 소스코드와 버전을 관리를 지원해준다.

branch

branch는 개인 또는협업에서 별도의 독립적인 저장소를 만들어 작업할 수
있게끔 만들어주는 기능이다.

개인 프로젝트에서는 단일로 작업하기에 개인의 작업 성향에따라 차이는 있지만
master branch 하나에서 작업을해도 local 영역에서
1. git add .
2. git commit -m "설명"
3. git push origin master/main
의 과정이 이루어지며 수정 또한 commit에 남아 있는 본인이 작성한 message로 쉽게
기록이 가능하기에 다수의 branch를 남기는 편은 아니다.

하지만 협업에서는 본인이 작업한 부분도 다르고, 맡은 역활또한 다르기에
branch의 분할이 필요하다.

위의 사진처럼 협업에는 다수의 branch가 존재하며 크게 5종류로 나뉜다.
master
develop에서 개발 되고 release 에서 안정화 된 최종 코드를 배포하기 위한 branch이다.
hotfixes
긴급수정된 항목을 담는 branch로 develop/release를 거치지 않고 바로 master에 병합한다.
release branches
develop 에서 개발된 코드를 배포할 수 있게끔 안정화 시키는 branch이다.
develop
개발이 진행되는 branch이며 보통 develop를 fork 후 개인 local영역에서 feature branch를 통해 작업 후 merge를 시행한다.
feature branch
개인 작업이 이루어지는 branch로 개인 레파지토리로 develop를 fork한 후 upstream 주소를 설정해 개인 pull request 요청을 보내서 develop에서 병합하게 된다.

Repository

Repository는 저장소를 나타내며 git/GitHub 에 의해 관리된 코드/버전을 저장하는 장소이다.

Repository는 크게 upstream 과 origin의 개념으로 나뉘게된다.

  • upstream : 최상위 레파지토리
  • origin : 개인 레파지토리

위쪽의 branch설명과 연결지어보면 우리느 develop branch 에서 본인의 repository로 fork를 받아 온 후 개인 영역에서 작업을 하기에 다수가 사용하는 develop는 upstream이 되며
fork 받아온 개인 repository는 origin이 된다.

fork 이후 git clone로 인해 본인의 작업환경(vsCode, pyCharm....)으로 코드를 받아 온 후
git remote add upstream 원본 주소 명령어를 통해 origin과 upstream을 연결 할 수 있으며

git remote -v 명령어를 통해 연결된 repository를 확인 할수 있다. 이후 작업은

1. git pull upstream develop 명령어를 통해 최상위repository의 develop branch로 부터 코드를 pull을 받아온다.
2. 팀에서 부여받은 역활에 맞게 issue를 발행받아. 개인 local영역의 feature branch에서 issue에 해당하는 작업을 진행한다.
3. 작업이 완료되면 완료된 branch에서 add/commit/push(origin)를 진행한다.
4. 본인의 origin repository에 들어가 upstream repository로 pull request를 요청한다.
5. pull request 승인 이후 여러 사람들이 작업한 코드가 merge 되면 git pull upstream develop를 통해 다시 한번 upstream repository로 부터 코드를 받아온다.

이후에는 바로바로 이슈로 진행될 경우 2번부터 반복되게 된다.
그림으로 보게되면 다음과 같은 구조가 되며 pr에 의한 merge이후 upstream 으로부터 pull을 받게된다.

이번 팀 프로젝트간 팀의 코드/버전관리에 사용한 구조로 실제로는 상황과 약속에 따라 다르게 관리될 수 있다.

git 명령어

아래는 개인 프로젝트를 진행하며 git을 통해 사용한 명령어들이다.

  • git init : git생성하기
  • git remote add repository : 생성된 git에 repository를 연결한다.
  • git clone git_path: 코드가져오기
  • git fetch : git 서버에서 최신명령어 받아오기
  • git pull : 상대방이 작업한 내용물을 가져 올 때 사용
  • git commit -m "내용" : 최종적으로 수정이 끝난 자신의 작업을 메세지와 함께 남긴다.
  • git push : commit으로 기록한 작업을 지정한 저장소에 저장시킨다.
  • git add . : 작업간 발생한 변경사항을 스테이징한다.
  • git log : 현재 본인 git의 상태를 확인 할 수 있다.
  • git reset : git add . 된 상태의 코드를 작업 디렉토리로 반환한다.
  • git reset — hard HEAD^ : commit한 이전 코드 취소하기
  • git reset — soft HEAD^ : 코드는 살리고 commit만 취소하기
  • git reset — merge : merge 취소하기
  • git reset — hard HEAD && git pull : git 코드 강제로 모두 받아오기
  • git stash : 최근 커밋을 분기점으로 작업한 내용을 임시저장하고 이동한다.

첫 협업동안 새로 쓴 git 명령어

  • git remote add upstream 원본 주소 : 최초 git과 repository를 연결한 것처럼 upstream을 연결한다.
  • git branch : 본인이 이동가능한/작업한 branch 목록을 보여준다.
  • git checkout branchName : branchName 으로 branch를 이동한다.
  • git checkout -b branchName : branchName 을 생성하고 branchName으로 이동한다.
  • git remote -v : 본인이 연결된 origin/upstream을 확인 할 수 있다.

git 협업 후기

그동안 git을 통해 개인 코드만 관리를 해온터라 첫 git 협업은 팀원과 pull request를 통한 merge시 충돌도 자주 발생했으며, 애매하게 이해한 부분에 대해 두려움도 많았고, 팀 코드를 날리지는 않을까 싶은 걱정에 부담감도 컷다.

그렇기에 branch와 repository외에도 많은 부분에 대해서 처음부터 공부하였으며, 원활한 협업을 위해 많은 시간을 사용한 부분이였던 것 같다.

아직 부족한 부분도 많고 더 깊은 이해가 필요하다 생각하지만 공부하면서 스스로 발전할 수 있는 좋은 기회가 되었다.

profile
프론트엔드 주니어 개발자(React, Next.js)

0개의 댓글