[git] 버젼관리 #1

[버젼관리]

- 말그대로 버젼관리의 필요성을 느끼고 그에 따른 프로그램을 사용함

- 대표적인 프로그램으로 SVN, git이 있음 

- github은 코드 공유에 초점이 맞춰져있음

- 지금부터 할 것은 git에 초점을 맞춘 것 : 버젼관리!

[git으로 특정파일 버젼관리]

1) 전용 디렉토리를 만듬 : 분류를 위해

2) git init을 통해 전용 디렉토리 내에 .git 디렉토리(버젼관리기록이 저장될 디렉토리 > 자동으로 만들어짐)를 만듬 

3) vim(텍스트 편집기)으로 임의 html 문서 만들고 편집 후 저장, 빠져나오기 === 버젼관리 확인을 위해

4) git status를 통해 우선적으로 현재 디렉토리 안에 있는 파일에 대한 버젼관리 상황을 확인을 해봄

- Untracked files라면서 방금 만들었던 파일이름(a.html)이 나올 것임

=> 현재 디렉토리에 대한 버젼 관리 디렉토리가 만들어져있지만, 디렉토리 내에 있는 파일이 버젼관리 대상이 아님을 알리는 것

- 버젼관리 디렉토리만 만든다고해서 끝나는 것이 아니라, 직접 지정해줘야함(다음 단계)

5) git add를 통해 방금 생성한 파일을 버젼관리 대상에 넣음, 그러고 난 후 git status로 다시 확인해봄

- 버젼관리 대상으로 넣은 후 확인해본 결과 커밋되기위해 변경되었다는 메세지가 나옴(+ 파일명)

- 아직 버젼으로 기록된 상태가 아님, 버젼으로 기록되기 전 단계 === 파일 추가 단계까지옴 

- 현재 단계를 staging area라고 함 (참고 : http://jinbroing.tistory.com/1)

- add 명령어는 버젼관리 목록에 해당파일을 넣을 때 사용하지만 커밋을 하기 위해 기존 파일을 add 시키기도 함

=> 여러 파일이 있는데, 이 파일에 대해서 커밋을 한다고 staging area로 보내려고한다면 따로따로 add 명령어로 add할 수 있음

6) 추가한 파일을 가지고 버젼으로 기록해봄(git commit)

- 커밋 메세지는 현재 단계의 버젼이 어떤 작업을 했느냐를 적는 것

- 커밋하기 전! 자신이 누구인지 설정하지않았다면 위와 같이 커밋오류가 남, 그래서 아래 이미지처럼 설정할 것

7) git log를 통해 현재까지 한 커밋 로그 내역을 볼 수 있음

- commit 이후 긴 문자열은 커밋의 id값 : 나중에 포스팅할 내용에서 중요한 역할을 함

- Author에는 방금 설정한 user.name과 email이 저장되어있음 : 누구의 코드인가(협업 차원이 더 큼)

- Date : 커밋한 날짜와 시간

- first commit은 방금 커밋할 때 설정한 커밋 메세지(실제로는 간결하면서도 현재 버젼에 대한 정보가 딱 있어야함)

[정리]

- git init -> 파일 작성 -> git add 파일명(Staging Area) -> git commit(Repository) 순

- 버젼관리의 가장 기본적인 흐름임

- 다음 포스팅을 통해 원리들을 알아보고 점점 살을 붙일 예정

[다음 포스팅 예고]

- 버젼1과 버젼2(최신)의 차이점 보는 방법

- 버젼3에서 버젼1로 돌아가는 방법

- git 명령어 공부하는 방법