요약 :
❗ 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하면 된다.
