Git Basic 1

다수의 팀플을 하며 깃을 사용할 일이 많아 깃에 대해 공부한 기본적인 내용들을 정리해보려 한다.

- Git : Version Control System
- Github : git repository(저장소)를 원격 저장하는 웹 서버. 협업관리, GUI 등을 지원함.
-gitignore : 컴파일 등에 사용된 불필요한 것들을 해당 폴더에 넣으면 자동으로 보이지 않게 됨
- apache가 가장 낮은 라이센스, MIT가 그 다음. 이 두 개가 가장 많이 사용되는 것.

github에서 먼저 repository를 만들고, 해당 주소를 git clone으로 커맨더 창에서 쓰면 로컬 repository가 생성된다.
이 때 github은 remote, 로컬은 local repository로 구분된다.

커맨더 창에서 깃은 각 버전을 긴 해시로 관리하며, 일반적으로 앞의 7자리 정도만 쓰면 찾을 수 있다. head는 현재 가리키는 repository, origin은 복사해 온 remote의 원본 repository를 가리킨다. (해당 정보는 로컬에 저장되어 있지만 해당 정보는 복사한 시점의 remote repository의 상태를 나타낸다) origin은 remote를 가리키는 것.

워킹 디렉토리에서 변경한 후에는 중간 단계인 staged 상태로 넘어가야 한다. 이를 add 명령어로 staged 상태로 넘어가게 만들 수 있고, (이를 안하고 그냥 버릴 수도 있다) 그러나 이것은 아직 반영되지 않은 상태이다.
새로운 변경을 하여 새로운 stage 대기 상태가 있으면 기존 것은 버려진다.

이후 commit을 통해 로컬에 변경사항을 모두 반영할 수 있다. 커밋을 하면 remote repository와 local의 버전이 바뀌게 된다. 즉, 커밋을 통해 새로운 버전을 만들어낼 수 있다.

 -  commit은 많이, merge는 신중하게. (돌아가고 싶은 버전의 해시값만 알면 언제든 돌아갈 수 있다)
 - 커밋 시 작성하는 로그는 통용되는 포맷을 사용하거나 통일하는 것이 좋다.

이런 커밋은 로컬에서만 발생하고 원격 저장소에 반영되지 않는다. 따라서 이 상황에서 status를 확인하면 몇 개의 커밋이 현재 로컬이 앞서 있는지 나오게 된다.

언제든 이전 버전의 해시 값을 찾아보려면 git log를 치면 찾아볼 수 있다.

이전 버전으로 돌리려면 reset --soft 를 사용하면 된다. (soft/hard가 있지만 왠만하면 soft만 사용하는 것이 좋다.) 이 경우 이전 버전이 날아가지는 않지만 로그에는 찍히지 않는다. 그리고 working directory의 변경 사항은 여전히 남아있으므로 현재 로컬 깃과 워킹이 달라지게 된다. (ppt 47쪽 = 가 아니라 !=)
이런 것은 commit 이력을 정리할 때 사용하기도 한다.
여기까지의 과정은 모두 로컬에서 발생한 것이므로 어떤 인터넷 연결 혹은 원격 저장소에 영향을 미치지 않는다. git add, status, commit, log, show, reset 등 명령어는 모두 외우기.

* 깃의 저장 방식은 기본 파일은 계속 지속되는 동시에 거기에 변경사항만 쌓이며 각 버전을 해시 값으로 분류하는 형식.

원하는 branch로 push 하면 변경사항이 remote 저장소에 저장된다. 앞서 변경사항 롤백과 동일하게 force push는 하지 말 것.
이후 로그를 찍어보면 로컬과 원격의 버전이 동일해진 것을 확인할 수 있다.

그러나 이런 push를 해버리면, 서로 다른 사람이 서로 다른 개수의 커밋을 푸시 할 경우 컴플릿이 생긴다. 따라서 작업하는 폴더를 분리하여 branch를 여러 개 만들어 사용한다.
이 branch는 로컬/ 원격 모두 만들 수 있다.

여러 개의 branch를 만들면 다양한 버전을 동시에 워킹 디렉토리에서 관리할 수 있다. 단, 브랜치를 변경할 때 수정한 사항은 모두 커밋/푸시를 해놓아야 한다.
branch 형성 - 특정 커밋 버전 으로 형성하면 해당 버전의 브랜치를 만들 수 있다.
이 때 log를 찍으면 각 branch에 대한 로그만 출력된다.

원격 저장소에서도 새로운 브랜치를 만들 경우 로컬과 이름을 동일하게 하는 것이 좋다. 이 경우, 로컬의 헤드/오리진은 원격 저장소에서도 새로운 브랜치를 가리키게 된다.

이 경우, 원격/로컬을 푸시 할 때 같은 브랜치를 가리키고 있는지 확인해야 한다.

fetch : 원격 저장소의 모든 브랜치를 표시
만약 로컬의 특정 브랜치를 원격의 다른 브랜치로 변경하고 있을 경우, rebase 를 사용하면 된다. 이는 origin/head를 변경하여 어느 버전을 가리키는지 변경하는 방법이다. (메인의 가장 최신 커밋을 가져오는 것)

이 때 주의할 점은, 이럴 경우 working directory가 원격 것을 받아오는데 반해, 로컬 커밋에는 이것이 stage/commit이 안되어 있기 때문에 다시 버전을 바꿀 경우 에러가 발생한다. 이는 주소만 바꾸었기 때문에 발생하는 것으로 워킹 디렉토리의 변경 사항은 커밋을 해야 한다.
로컬 저장소도 마찬가지로 버전을 바꿔도 워킹 디렉토리의 변경 사항은 반영되지 않는다는 것을 기억해야 한다.

 - git pull : 원격의 이전 버전을 로컬로 바로 당겨올 수는 없다. (로컬의 버전이 더 높을 경우)

원격의 main branch를 로컬의 새 branch로 가져와서 작업을 하고, 원격 branch 폴더에 push 한 뒤, 이 변경 사항을 다시 원본 파일 main branch 에 합치는 것이 merge이다.
이를 위해 pull request (PR)을 날리게 된다.

커밋을 할 때와 마찬가지로, pr을 할 때도 작성해야할 기본적인 사항들이 존재한다. (title, purpose, change, testing, screenshot, note 등) 이 PR을 기반으로 인수인계와 토의를 하기 때문에 잘 적어놓아야 관리하기 더 편해진다. note는 에러 해결법, 배운 점 등을 쓴다.

pr을 머지하기 전에 hotfix, issue 등을 수정할 경우, pr의 로그에 새로운 커밋이 남게 된다.
이후 file changed 를 눌러보면 추가/삭제된 라인들이 표기된다. 이를 확인하고 모든 이슈를 해결하면 머지가 가능하게 된다.

머지 후에는 main으로 합쳐진 branch를 삭제하거나 남겨놓을 수 있다. 아직 새로운 개발을 할 여지가 있으면 해당 branch를 남겨놓고, main으로 모두 합쳐서 필요 없을 경우는 지운다. 그러나 로컬의 커밋이나 브랜치는 간단하게 정리하기 위해 지우는 것이 더 편리하다.

만약 기존 원격 저장소에 저장된 코드 중에 사내 중요 정보 등이 노출되어 삭제해야 할 경우, 로컬에서 커밋이력을 모두 지운 후, force push를 통해 원격 저장소의 커밋을 모두 변경할 수 있다.
그러나 일반적으로 이를 사용할 일은 잘 없다. (기존의 원격 저장소의 이력이 모두 삭제되므로)

원격 저장소의 머지 등의 작업은 로컬 저장소에 바로 반영되지 않기 때문에 로컬 컴퓨터에는 이전 이력이 남아있게 된다. 따라서 새로 merge 한 원격 저장소의 main을 로컬로 가져와야 한다. 이것은 git pull을 통해 할 수 있다.