중요한 내용 및 추가로 알게된 사실
Git
GIT에 대한 내 생각
하나의 프로젝트를 여러 사람이 분업하는 것이 효율적이고, 환경 역시 >업무 시간과 양의 특성상 각자의 로컬에서 작업하는 것이 편할 것이다.이러한 상황에서 각 로컬에서 작업하고 있는 파일(프로젝트의 대상?)이 최신 버전인지, 내가 한 작업이 다른 사람 작업이랑 겹쳐 덮어 씌워지진 않는 지, 문제가 발생해서 예전 버전으로 돌릴 필욘 없는 지 확인하면서 프로젝트를 좀 더 손쉽게 할 수 있도록 도와주는 프로젝트 매니저 역할을 해주는 것이 GIT인 것 같다.
- 프로젝트의 버전 관리를 위한 Tool
- 분산형 관리 시스템
분산형 관리 시스템(구글링한 후 내 생각 중점)
기존의 시스템은 소스 관리를 위한 중앙 서버를 두어 운영을 했었는데 이 경우 중앙 서버에 문제가 발생하면 작업을 하기 힘든 단점이 있었다. 이에 나온 것이 분산형 관리 시스템으로 소스 관리를 각각의 로컬 컴퓨터가 하며 저장소를 공유하는 방식이다. 분산형 관리 시스템을 사용하면 병렬 적으로 작업이 가능하며 중앙 서버에 문제가 발생해도 다른 컴퓨터를 통해 원상 복구가 가능하다.
git add
- 파일을 "Staging Area"로 올리는 명령어
- 이때부터 파일을 컴퓨터가 추적(Tracking)함
Git이 관리하는 폴더라고 하더라도 특정 파일을 추적하라고 컴퓨터에게 알려주지 않으면 Git은 파일의 상태를 알 수 없다. git add <파일이름> 을 통해 해당 파일을 Staging Area라는 곳에 올려두면 그때부터 Git이 그 파일의 상태를 "Untracked, Modified, Staged"로 표시해줄 수 있게 된다.
git commit
- "Staging Area"에 등록된 파일들을 "Local Repository"에 올리는 명령어
Git이 관리한 폴더의 상태를 저장하고 기록하는 것이라 이해했다.
예를들어, 인터넷에서 다운로드 받은 한글 or 엑셀 파일을 변경하고 저장한 것과 같은 것 같다. 내가 변경한 다운로드 받은 파일을 변경했다고 그것이 인터넷에 올려뒀던 원본 파일 자체를 변형 시키진 않듯 내 아직까진 변경점이 내 Local에만 저장되는 상태이다. 다만, 파일 변경 후 저장과는 다른 것이 Git은 파일의 상태를 commit 하는 것으로 마치 사진을 찍는것과 같이 그 것을 기록한다. 이것을 "snapshot"과 "log(or history)"라고 부르는 것 같다.
git push
- "Local Repository"에 올려진 내용을 다른 사람들과 공유할 수 있게 "Remote Repository"에 올리는 명령어
전 단계에서 내가 변경한 파일의 변경점을 인터넷에 올려 다른 사람들도 변경된 파일을 다운받아서 쓸 수 있게 하는 것으로 이해했다. 추가적으로 문제점이 발생하면 변경전으로도 되돌릴 수 있다.
git pull
- "Remote Repository"와 "Local Repository"를 비교하여 다른 점을 업데이트 하는 명령어
누군가 인터넷에 올린 달라진 파일을 받아 내 파일이 바뀌는 흔히 말하는 버전 업그레이드와 같은 것으로 이해했다.
여기서의 인터넷, 파일, 한글, 엑셀 등의 단어는 내가 이해 및 설명을 하기위해 예시를 든 것이지 git 명령어를 통해 이렇게 된다는 것은 아니다!
