| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
- mp4GIF변환
- WAMP
- Resource Owner
- revealjs
- optionality
- 웹서버설치
- Gamebar
- 아파치루트
- 마우스캡쳐
- captures
- 크롬개발자도구
- client secret
- 리모트디버깅
- Android-pc
- 온라인프리젠테이션
- 관계형데이터베이스
- 비트나미루트
- Intel CPU #13th Gen #i9 CPU
- refresh token
- 비트맵 인덱스
- 므카데쉬
- client id
- 생체정보프로그램
- 정보에너지장
- 호반써밋
- introjs
- 치드케누
- Resource Sevrer
- authorization code
- MySQL사용자이름
- Today
- Total
솔트펀 티스토리
Git CLI - 버전관리 본문
0. INTRO
1. 설치
2. 버전관리의 시작
3. 버전의 생성
4. 버전간의 차이점 비교
5. checkout과 시간여행
6. 보충수업
7. 버전 삭제 - git reset
8. 버전 되돌리기 - git revert
9. 마무리
0. INTRO
git CLI [Command Line Interface] 명령어의 특성상 처리해야 할 일을 한 번에 명령하여 자동화를 할 수 있다. GUI 를 사용할 수 없는 서버환경에서도 쓸 수 있기 때문에 많은 개발자들이 사용하고 있다.
1. 설치
Mac 에서의 설치
Windows에서 설치
2. 버전관리의 시작
pwd, ls -al, cd, mkdir 등 리눅스 명령들을 사용[Mac 환경].
git init 버전관리할디렉토리
git init . 현재 디렉토리 버전관리 시작. .git이라는 디렉토리가 생김. 이 안에는 현재 버전관리가 시작된 현재 디렉토리에서 일어나는 여러 가지 변화들을 기록함. 따라서 .git 이라는 디렉토리를 절대 지우면 안됨.
3. 버전의 생성
버전생성
git은 파일의 변경사항들을 버전으로 만들어 관리한다.
버전이 저장되는 곳이 저장소 Repository이다. .git이라는 디렉토리이다.
Working tree: 아직 버전으로 만들어지기 전 단계
Staging Area: Working tree 에 있는 파일 중에서 이 Staging Area에 있는 파일만 버전으로 되어 Repository에 기록된다.
즉 버전으로 만들려고 하는 파일들이다.
버전으로 관리하려고 하면 명령어를 써서 한 번 알려줘야 한다. 버전관리가 되지 않는 상황일 때에는 git status 명령으로 확인할 경우 Untracked files에 나타난다. 즉 아직 Working tree 에 있다는 뜻이 되겠다.
이것을 Staging Area에 올리는 명령어는 git add 파일명 이다. 파일을 Staging Area에 올린 후 git status 명령으로 다시 확인해보면 Changes to be commited: new file: 파일명 으로 나타난다.
Staging Area에 있는 파일을 Repository에 넘기는 명령은 git commit 인데 옵션과 "버전이름"이름을 주어 한 번에 실행시킬 수 있다. git commit -m "Message1" 명령어에 의해 Repository에 만들어지고 git status로 확인하면 버전대기가 없이 깨끗하다는 메세지가 뜬다. Working tree의 내용이 모두 버전으로 만들어지면 working tree 도 비어있다고 메세지가 뜬다.
git log: 버전이 만들어진 log확인. 확인을 마칠 때에는 Q 입력
여러 개의 파일을 하나의 버전으로 만들기
이미 버전 관리가 되는 파일이든 추가로 버전관리를 하려는 파일이든 각각 모두 git add로 Staging Area에 올려놓고 git commit을 실행한다.
각각의 버전별로 어떤 파일들이 들어있는지 알기 위해 "git log files list" 로 구글링하니 이런 결과를 얻었다.
위의 검색결과에 딸 git log --stat 이라고 입력하면 버전별로 변화를 알 수 있으며 이런 작업을 파일명을 바꾸면서 관리하려면 매우 복잡하지만 git 은 이 복잡한 작업을 쉽게 관리할 수 있도록 해준다.
4. 버전간의 차이점 비교
버전관리를 하면 버전과 버전 사이의 비교를 할 수 있다. 이를 통해 의사 결정을 하는데 큰 도움을 받을 수 있다.
git diff 이전 버전과이 차이를 상세히 보여주기 때문에 의사결정을 심사숙고 하는데 매우 큰 도움이 된다.
git reset --hard 새로 한 작업을 무시해버리고 이전 버전으로 되돌린다.
git log -p p는 패치. 로그 내용을 보여주는데 변경된 부분까지 상세하게 보여준다.
이런 기능은 코드등을 작성하다가 문제가 발생했을 때 어디에서 문제가 발생했는지 찾아내는데 큰 도움이 된다.
5. checkout과 시간여행
checkout은 특정 버전으로 working tree를 변경시킨다. 이를 통해 버전과 버전을 넘나드는 방법을 살펴본다.
git log 명령을 실행 시키면 HEAD 현재 master를 가리키는 것을 볼 수 있다. master 최신 상태를 뜻하는 주소쯤으로 이해할 수 있겠다. 이제 HEAD 값은 다른 버전의 commit 해시코드를 설정하는 것에 의해 이전 버전으로 혹은 버전 사이를 왔다갔다 할 수 있다.
git checkout e706e06... 명령에 의해 HEAD 가 변하고 해당 버전의 상태로 바뀌었다.
최신 버전으로 다시 돌아가려면 HEAD 값을 다시 master 로 설정하면 된다.
git checkout master
6. 보충수업
git add 파일명 : 지정한 파일을 Staging Area에 넘기라는 뜻. 각각의 파일마다 다 하기가 번거로울 때에는
git add . : 현재 디렉토리 모든 파일을 Staging Area에 보내라는 뜻. 당연히 디렉토리명을 지정할 수도 있다.
git commit -am "버전명" :a 옵션은 add 와 commit을 동시에 실행한다는 뜻. 이때 Untracked 파일 즉 한 번도 Staging Area 에 올라 commit 된 적이 없는 파일은 역시 commit 되지 않는다.
git commit : m 옵션을 쓰면 "버전명"을 바로 지정할 수 있지만, 아무 옵션도 없으면 기본에디터가 실행되면서 해당 버전에 대한 상세한 내용을 작성하는 것이 가능하다.
또한 이때 열리는 편집기를 바꿀 수도 있는데 "change git default text editor"로 구글링하여 방법을 찾을 수 있다.
git config .... 하는 식으로 환경을 바꾸는 것이다.
7. 버전 삭제 - git reset
git reset --hard commitHashcode20byte : 버전을 reset하면 지정한 버전으로 되어버린다.
Fig 8에서처럼 버전 간 이동이 아니라 버전이 아예 바뀌어 벼렸다. master가 바뀐 것이다.
명령어의 도움말이 필요하면 git reset --help 와 같이 하면 된다. 이 도움말을 보면 reset에는 --hard 외에도 다른 옵션들이 여럿 있다.
8. 버전 되돌리기 - git revert
git reset은 버전을 아예 지워버리지만 revert은 삭제와 보존의 목적을 동시에 달성할 수 있다.
한 단계이전의 버전으로만 되돌리는 것으로 보인다. 즉 버전이 1, 2, v3, v4 가 있고 master 가 v4라고 하면,
git revert commitHashcode20byte 와 같이 바로 이전 버전 즉 v3 버전의 commit 코드를 지정하여 v3 버전으로 바뀌는데 이때 v3 버전으로 되돌아간다기 보다는 v4 버전에서 v3 버전으로 변한다는 것이다. 이게 무슨 말이냐면, 버전이 1, 2, v3 이 되는 것이 아니라, 버전은 1, 2, v3, v4, v3 으로 된다는 뜻이다. v3이 master 이고.
따라서 버전을 건너뛰어 revert를 적용하면 conflict 오류가 발생하며 만일 1 버전으로 되돌리려고 한다면 이런 식으로 가야 한다는 것이다. 현재 버전이 1, 2, v3, v4라면 1, 2, v3, v4, v3, 2 이런 식으로 말이다.
참고 : http://www.devpools.kr/2017/01/31/개발바보들-1화-git-back-to-the-future/
9. 마무리
버전관리의 핵심은 비교이다. 비교를 통해 과거를 되돌아 볼 수 있다는 것이 버전관리의 핵심적인 효용이다. "diff tool"을 검색해보면 좋은 도구들이 많은데 이 도구들을 이용해 차이점을 보다 정교하게 비교할 수 있다. 정확한 의사결정을 내리고 현재의 상황을 신속하게 파악하는데 큰 도움이 될 것이다.
버전관리를 하지 말아야 할 파일이 있을 수도 있다. 그런 경우 .gitignore라는 파일을 만들고 거기에 파일의 이름을 적으면 된다. 예를 들어 파일을 편집하다 보면 그 프로그램이 필요에 따라 임시파일을 만드는 경우가 있다. 혹은 나혼자 보기 위해 비밀번호 같은 것을 특정 파일에 메모를 하고 있기는 하지만 그에 대해 버전관리를 원하지 않을 수 있는 것이다. 이때 .gitignore라는 파일을 만들고 거기에 무시하려는 파일들을 적어두는 것이다. 검색을 통해 방법을 찾을 수 있다.
또한 git에는 정말 중요한 특징이면서 혁신적인 면 중의 하나인 branch라는 환상적인 도구가 있다. branch는 우리의 저장소를 여러 가지 상태로 공존할 수 있게 해준다. 예를 들어 보고서를 하나 작성해다 치자. 그런데 여러 고객사들에게 해당 보고서의 내용을 고객사 별로 조금씩 수정해서 보내야 한다면 어떻게 해야 할까? 아마도 이때 쓸 수 있는 방법은 저장소 전체를 복사해서 디렉토리를 만든 후 각각에 대해 작업하는 것일 수 있다. 이때 branch를 이용하면 저장소 이름에 영향을 주지 않고 하나의 저장소에서 다양한 작업을 진행할 수 있다.
복잡한 commitHashcode대신에 tag를 이용할 수도 있다. 버전에 이해하기 쉬운 이름을 붙여 보다 쉽게 중요한 버전을 찾아갈 수 있다는 장점이 생긴다.
버전관리에서 정말 중요한 것 중의 하나는 backup이다. backup을 하지 않는다는 것은 자신의 정보를 언젠가는 유실하겠다고 선언하는 것이나 다름없는 것이다. git은 자체적으로 매우 안전하고 편리한 backup 장치를 가지고 있다. 클릭 한 번으로 지금까지 작업한 것을 인터넷에 업로드 할 수 있다. 필요할 때 바로 다운로드 받아 작업할 수도 있다. git의 백업에 대해 잘 모른다 할지라도 dropbox, google drive, one drive등을 이용하여 자료를 백업해두는 것이 하지 않는 것보다 100만배는 더 낫다. 백업을 하면 백업너머에 자연스럽게 협업이라는 기능이 보인다. >
'DEVELOPMENT > Git&GitHub' 카테고리의 다른 글
| GitHub (0) | 2020.02.01 |
|---|---|
| GIT (0) | 2020.01.31 |
