GitHub - (1) 협업 환경의 버전 관리
1. 버전 관리
1.1. 개요
- 협업 환경에서는 실시간으로 수정되는 환경에서 일을 한다.
- Git을 기반으로 하여 언제 무엇을 어떻게 누가 했는지가 기록된다.
- Git Bash가 기본적으로 설치되었는가 확인할 것.
- GitHub Desktop의 설치가 되었는가 확인.
- GitHub 계정을 생성한다.
1.2. 초기 설정
- git push --force, git reset --hard 이렇게 둘은 사용하지 말 것(어지간하면 사용할 일은 없음).
- 간혹 새로운 환경에서 기존 GitHub Desktop에 다른 계정이 있다면 재설정 해줄 것(Account, Git).
- Git은 버전 관리 시스템이다.
- 이전 관리 상태로 되돌리기, 시간에 따른 변경 비교, 파일 복구 등에 사용.
- 이력을 보존하고 되돌리기가 가능해야 한다.
- 버전 관리를 할 때, commit을 통해 드러난다. commit 이력이 보고서인 셈.
<그래, 커밋 이력은 어디있나?>
- Git의 흐름은 다음과 같다.
Mermaid렌더링 중...
- .git 폴더에 있는 위치가 개인이 가진 로컬 저장소고 push, pull을 통해 GitHub의 원격 저장소로 보내고 가져오는 것.
- commit은 저장을 말한다.
- commit까지가 내부 저장소에서 하는 일의 끝이다.
<로컬의 범위는 커밋까지>
- 로컬에 .git을 동기화시키고 이력이 기록된다.
- 결과적으로 GitHub에 내 이력이 남게끔 하는 것.
- 이것을 Git push라고 부른다.
- 로컬 저장소는 인터넷이 없어도 작업 가능.
- 단, 원격 저장소에 push, pull을 못할 뿐.
- commit은 특정 시점에서 프로젝트 전체 상태를 말한다.
<상태 체크를 자주 하면 좋듯 커밋도 자주 해주는 편이 좋기는 하다>
1.3. 용어
- fetch : 로컬에서 작업하다가 원격 저장소에서의 변경을 확인.
- pull : 변경된 것을 내 로컬로 가져오는 것.
- log : 기록.
1.4. 연동 및 사용
- 생성한 뒤, clone Repository로 들어간다.
- 원격 저장소를 복사하여 내 로컬 경로에 당겨오면서 연동시키는 것을 Clone이라고 한다.
<직관적으로 로컬 저장소에 원격 저장소의 요소를 가져오는 느낌이다>
- 경로를 설정하고 Clone을 누른다.
- https를 선택하면 url이 뜨고 url 탭에서 입력하여 들어갈 수 있다.
- ctrl shift F를 하면 경로로 들어가진다.
- ctrl shift G는 깃허브 계정으로 들어간다.
- 어지간하면 .git 폴더를 뜯어서 볼 필요는 없다.
- 경로에 IDE 생성하고 보내볼 것.
- commit 후 publish를 누르면 올라간다.
- Browse를 클릭해보면 선택한 id로 들어간다.
- 이를 통해 원격 저장소에서 특정 시점으로 돌아가는 것이 가능하다.
- History에서 과거 이력 내용이 필요하면 그 시점을 우클릭하여 Checkout Commit을 통해 회귀 가능하고 다시 상단 Branch 쪽을 선택하여 main을 클릭하면 최신 것으로 돌아온다.
- 의미불명의 id는 해시 코드인데 정해진 길이의 결과물로 저장하는 것이다.
- 커밋 로그들은 이 해시들의 나열이다.
- 이제 의도대로 안되어 되돌려야 하는 경우가 존재한다.
- reset 및 revert에 대한 것이 있는데 꼬이거나 돌이킬 수 없을 경우가 종종 있다.
<되돌릴 수 없는 일이 일어나기 전에 그냥 reset과 revert는 없다 생각하자>
- 수동으로 탐색기로 들어가서 삭제된 것을 복사하고 해당 경로에 붙여주는 형식으로 진행할 것을 권장. 이게 실제로 가장 안전함.
1.5. .Gitignore
- 필요없는 것들을 제외하고 프로젝트를 만들 예정임.
<너무 큰 리소스들은 여기서 거르고 push되지 않게 해야 한다>
- rider나 VS든 IDE 관련 gitignore 준비
- Ctrl Shift A를 눌렀을 때 VS가 생성됨.
- 그 상태에서 파일을 추가하여 .gitignore를 생성할 수 있다. 마크가 변경된다.
- 그곳에 준비된 IDE별 gitignore를 붙여넣어주고 저장을 하면 훨씬 적은 리소스가 들어간다.
- 그리고 원래 했던 것처럼 다루면 된다.
1.6. 이슈
- issue는 편히 사용할 수 있는 것인데 New Issue를 눌렀을 때 작성이 가능할 수 있다.
- Setting에서 General/Feature에서 issue가 있는데 Set up template를 통해 양식을 만들 수 있다.
- 양식을 만들고 이슈를 만들어진 템플릿으로 작성한다.
- 우측에서 설정할만한 사항들이 존재한다.
- 칸반버그 같은 것은 Project에서 이슈와 연동하여 할 수 있다.
- 원격 저장소에서 일어난 것에 대해서는 아직 로컬에 반영되지 않았다.
- 그게 Fetch origin이다. 이제 Pull Origin으로 가져올 수 있다.
- Fetch는 수시로 하는 것이 좋다.
1.7. 에러
- 간혹 같은 것을 작업을 해서 동시에 했을 때 충돌이 발생한다.
<그래서 보통은 같은 곳을 수정하기 보다는 분업을 해야 한다는 것>
- 다른 분기로 들어가는 것을 branch라고 하는데 branch에 들어가는 방법을 생각해야 한다.
- 별도의 작업 공간으로 분류되어 진행될 수 있다.
- 작업을 하고 난 다음 메인에 합쳐줘야 하는데 방어선이 없는 merge보다는 웹에서 pull request를 하는 것이 조금 더 안전하다.
- Delete Branch라는 상황도 있다. 그래서 branch에서의 작업이 끝나고 난 다음에 지우기 위해 필요하다.
- 원격에서 한 것은 다시 로컬에서 메인에 Fetch를 해서 반영 후, 로컬에서도 branch를 지운다.
- branch 병합 중 충돌이 발생하면 둘 다 살리고 주석으로 추가적으로 코멘트를 남겨두는 방향으로 생각해야 한다.
- 수정을 하면 Merge가 가능해질 것이고
