[GIT]Git flow

박민하·2022년 6월 10일
0

GIT

목록 보기
3/10
post-thumbnail
post-custom-banner

요약 :
❗ push할때 꼭 branch 확인
❗ push 하기전에 꼭 pull 하기
❗ 뭐부터 코드가 작성되어야 할까 flow 생각해보기


✅ basic flow

  GitHub는 다른 개발자와 같은 프로젝트를 두고 협업하거나 내 코드를 공유하기 적합한 플랫폼이다. 이번에는 협업을 위한 기본적인 과정에 대해 정리해보자.

1. 초기 세팅

  먼저 하나의 컴퓨터에서 초기세팅을 한다. 환경변수 my_sttings.py 넣고, requirement.txt.gitignore를 만들고, master branch를 main으로 바꾸고, 등등 초기세팅을 완료했다면 git commit -m "Add: initial settins complete" commit을 하고 git remote add origin 주소를 입력해서 repository와 연결한다. 그리고 git push .를 하면 프로젝트를 시작할 첫 단계가 끝난다.

2. repository clone

  위에서 초기 세팅을하고 repository가 생성됐으니 나머지 팀원들은 clone 을 받아 내 로컬환경에 다운로드 후 프로젝트를 시작하면 된다. clone 하기 위해서 'Clone or download' 라는 초록색 버튼을 누른 뒤 아래 복사 아이콘을 클릭하면 repository 주소를 복사할 수 있다.

  그 다음 해당 remote repository 를 내 컴퓨터로 받아오기 위해 다운로드 받고 싶은 경로로 이동한 뒤, git clone 명령어에 방금 복사해준 URL 을 붙여주고 실행한다.

git clone <github-repo-link>

  이렇게 하면 해당 경로에 clone 받은 GitHub repository 의 이름을 그대로 딴 폴더가 생성되고, cd 명령어를 사용해 해당 폴더로 이동하면 clone 시점에 remote repository에 존재했던 모든 폴더 및 파일들이 그대로 복제되어 있는것을 볼 수 있다.

2-1. Clone 이후

  Clone을 했다면 작업을 할 파일을 만들고, 그 파일로 들어가 conda activate 가상환경_이름으로 가상환경부터 만들자. 그 후에는 pip install -r requirements.txt 로 버전 통일을 하고 django를 시작하면 된다. dgango-admin startproject 프로젝트_이름 . 명령어를 입력하는데, .을 같이 찍지 않으면 현재 위치에 생기는게 아니라 또 다른 파일이 생기고 그 파일 내에서 만들어지기 때문에 잊지 말자.

  django를 시작하면 .gitignore, my_settings.py 파일을 만들고 ls -al 로 파일이 잘 만들어졌는지 확인하자. 모든 작업이 끝나면 git log, git add ., git commit -m "Add: initial settings", 그리고 git log로 다시 확인하고 새로운 branch를 만들면 된다.

3. Branching and merging

  여러사람과 협업해야 하는 프로젝트에서 master branch에서만 작업을 할 수 는 없다. 메인 branch를 건드릴 필요없이 작업환경에서 기능을 추가하거나 테스트를 진행하기 위해서는 새로운 branch를 만들어야한다.

  여선 아래 명령어를 통해 새로운 브랜치를 생성하고 이동해야한다. 만약 main branch에 잘못 commit 한거는 git reset --hard 를 하면 잘못 commit한 내용 전으로 돌아갈수있다.

git checkout -b feature/기능_유추_가능한_이름

  그 뒤로는 git add ., git commit, git push origin 과정을 통해 remote 로 올려주면 된다.

4. Pull Request(PR) 생성하기

  push 이후에 Pull Request(PR) 라는 것을 통해 프로젝트 오너(혹은 팀 리더) 에게 내가 작업한 브랜치의 작업내용을 master branch에 반영해달라는 요청을 보낼 수 있다.

  Pull Request 에서는 해당 repository 를 열람할 수 있는 권한이 있는 개발자들이 master 브랜치로 합쳐지기 전에 작업내용에 대한 리뷰를 해주거나 변경 사항을 확인할 수 있다. 해당 링크를 클릭하면 PR의 제목과 어떤 내용을 담고 있는지 설명하는 Description을 작성할 수 있다. 작성을 완료했다면, 하단에 'Create pull request' 버튼을 누르면 된다.

  이때부터는 함께 협업하는 개발자들이 방금 만든 PR을 리뷰, 분석하고 댓글까지 달아줄 수 있다. 모든 리뷰 내용이 반영된 후 master 브랜치와 충돌이 발생하지 않았다면 해당 PR은 master 브랜치로 merge 될 준비가 완료됐다고 보면 된다.

5. GitHub 으로부터 변경사항 pull 하기

  Pull Request 를 통해 master 브랜치를 업데이트했다면 이제 로컬 repository 는 GitHub 에 있는 master 와 서로 다른 내용을 가지고 있게 된다. 이 때 git pull 명령어를 통해 remote의 최신화된 코드를 내 로컬 repository 에 반영할 수 있다.

git pull origin master

  git pull origin을 자주 해서 계속 업데이트되는 내용을 확인해야 한다. pull이 끝난 뒤에 branch 삭제하는건 자유다.

✅ conflict

  항상 이렇게 순조롭게 merge 까지 진행되지는 않는다. merge 하기 전 conflicts(충돌) 가 발생할 수도 있다. 충돌은 어떤 파일의 변경사항이 기준이 되는 master 브랜치의 파일과 겹쳐, Git 에서 어떤 버전의 코드를 선택해야하는지 모를 때 발생한다. 이런 상황에서는 개발자가 직접 코드를 비교해 충돌을 해결하고 merge 를 마무리 해야한다. 이 때 우선순위와 시간적 순서, 어떤 코드가 선행되어야하고 후행되어야하는지 판단하는 역량이 필요하다.

  push 하기 전에 꼭 pull부터 해야 충돌이 안된다. 만약 conflict가 발생했다면 해결 방법은 add commit을 해놓고 main으로 돌아가 git pull origin main을 한 다음에 내 local main을 원격 main repository와 일치시킨다. 그 다음 git checkout 새로_만들었던_branch로 돌아가서 git merge main 으로 합치면 conflict 에러가 뜰 것이다. code . 명령어로 conflict가 발생한 부분을 볼 수 있고, 이 때 남길것만 남기고 다시 git add ., git commit, git push를 하면 끝이다!

✅ 파일 삭제?

  git을 사용하면서 파일을 잘못 만들었거나, commit을 잘못해서 지워야 하는 경우가 한 번 쯤 있을것이다. 이 때 디렉토리에서 삭제한다고 git에 반영이 되는게 아니기 때문에 반드시 git의 캐시를 삭제해야한다. 대표적인 문제로는 .gitignore 파일에 추가했어도 이전에 Commit한 파일들이 반영이 안되는 경우가 있다.

1. git 파일 삭제

// 원격 & 로컬 저장소에서 삭제
$ git rm 파일명

// 원격 저장소에서만 삭제
$ git rm --cached 파일명

// 하위폴더 모두 삭제
$ git rm -r --cached 폴더명

2. git cache 삭제

// 캐시 삭제
$ git rm -r --cached .

삭제가 완료됐으면 다시 git add ., git commit 하면 된다.

profile
backend developer 🐌
post-custom-banner

0개의 댓글