git의 데이터는 파일 시스템의 스냅샷(Snapshot) 이라 할수 있으며, 크기가 아주 작다.
git 은 commit 하거나 프로젝트의 상태를 저장할때마다 파일이 존재하는 그 순간을 중요하게 여긴다.
파일이 달라지지 않는다면 git은 파일을 새로 저장하지 않고 단지 이전 상태의 "링크" 만 저장한다.
= git 은 데이터를 스냅샷의 스트림으로 취급함
SVN 의 경우 중앙저장소에서 버전별로 델타(파일의 변화)를 관리한다. 즉 특정 버전을 가져오기 위해서는 초기 버전에서 원하는 버전까지의 델타 히스토리를 연쇄적으로 계속 적용하여 그 결과를 보여줘야한다.
반면 git 은 델타를 관리하는것이 아니라 스냅샷으로 관리한다.
즉 SVN 처럼 변화를 관리하는 것이 아니라, 그 시점의 데이터 그대로 관리하기때문에 훨씬 빠르게 특정 시점의 버전으로 돌아갈수 있다.
GitHub 과 GitLab 은 둘다 git repository를 위한 호스팅 플랫폼이다. 이들은 git 저장소를 대신 유지 및 관리 해준다.
많이 사용하는것들 위주로 정리해보았다.
그중 중요한 명령어 들에 대해 설명하자면,
브랜치를 분기한 후에 각 브랜치에서 변경사항이 적용되면 각 브랜치의 변경내용을 하나로 통합할 필요가 있다.
따라서 양쪽의 변경 사항을 가져온 “merge commit” 을 실행하게 되면 병합 완료후 통합브랜치인 “master”의 브랜치로 통합할수있다.
rebase 는 bugfix의 작업이력을 master 와 동일하게 병합하는것.
bugfix 브랜치를master 브랜치에 rebase 하면, bugfix 의 브랜치 이력이 master 브랜치 뒤로 이동하게 되고 하나의 줄기로 이어지게된다.
merge 는 변경내역의 이력이 모두 남아있기때문에 이력이 복잡해지지만, rebase는 이력은 단순해지지만 원래의 커밋 이력이 변경된다. 정확한 이력을 남길 경우에는 사용하지 않는걸 권장한다.
stash 란 , 파일의 변경 내용을 일시적으로 기록해두는것.
stash 를 사용하여 작업 트리와 인덱스 내에서 아직 커밋하지 않은 변경을 일시적으로 저장해둘수 있다.
이 stash 에 저장된 변경내용은 나중에 다시 불러와 원래의 브랜치나 다른 브랜치에 커밋할 수 있다.