#230221 화
어제랑 오늘 <Do it! 지옥에서 온 문서관리자 깃&깃허브 입문>을 읽었다!
1. 깃은 뭘까?
깃은 작업 환경을 효율적으로 관리할 수 있는 시스템이다. 깃을 이용하면 버전 관리, 백업, 협업을 할 수 있다. 깃허브 데스크톱, 토터스깃, 소스트리 등 깃을 편리하게 사용할 수 있는 깃 프로그램들이 여러 개 존재한다(전 깃허브밖에 안 써봤어요..).
2. 깃으로 버전 관리하기
(가 << 에는 영어 이름이 지정된다)
- 터미널 기본 명령어
cd ~ : c/Users/아이디 로 이동
cd ./ : 현재 작업 디렉토리
cd ../ : 현재 작업 상위 디렉토리로 이동
mkdir 가 : 가라는 하위 디렉토리 생성
rm 가 : 가라는 디렉토리 삭제
rm -r 가 : 가라는 디렉토리와 안에 있는 모든 파일 삭제
ls -a : 현 디레토리 안에 있는 숨김 파일과 각 디렉토리 표시
ls -l : 현 디렉토리 안에 있는 파일들의 상세 장보
ls -r : 파일 정렬 거꾸로
ls -t : 작성 시간 내림차순 정렬
vim 가 : 가라는 텍스트 파일 생성 or 열기
cat vim 가 : 가 텍스트 파일의 내용 출력 - git 저장소 만들기
우선 알아야할 것이 두 가지가 있다. 저장소가 생성되어있는 위치, 즉 현재 작업 중인 디렉토리를 작업 트리라고 한다. 작업 트리에서 만든/수정한 파일을 버전으로 만들기 위해 대기(?)시키는 것을 스테이징이라고 한다. 스테이징 영역에서 대기 중인 파일을 버전으로 만드는 명령을 커밋이라고 한다. 커밋 명령을 내리면 저장소에 파일이 저장된다.
git init : 디렉토리에 저장소를 만듦
git status : 깃의 상태를 나타냄(현재 브랜치, 커밋한 파일 개수, 커밋할 수 있는 파일)
git add 가: 가 파일을 스테이징함
git add. : 현 디렉토리에서 수정된 모든 파일을 스테이징함
git commit -m "메세지" : 대기 중인 파일을 메세지와 함께 저장소에 저장함
git commit -am "메세지" : 수정한 파일에 대하여 스테이징과 커밋을 한 번에 수행(새로 생성된 파일은 불가능)
git commit --ammend : 커밋 직후 커밋 메세지를 수정하고 싶을 때 사용하는 명령어
git diff : 스테이징 전의 수정된 파일과 저장소에 있는 최신 버전의 파일의 차이를 출력함
git log : 커밋 기록을 알려줌
git log --oneline : 한 줄에 커밋 한 개씩 출력(git log보다 로그가 깔끔하고 짧다)- 되돌리기
저장한 걸 수정하고 싶을 때도 있을 것이다. 되돌리는 명령어에 대해서도 알아보자. 여기에선 HEAD와 branch가 무엇인지에 대해 알아야한다. HEAD는 현재 작업 트리가 어떤 버전을 기반으로 작업 중인지 가르키고, 브랜치는 가장 최근의 커밋을 가리키는 일종의 포인터 같은 존재이다. 예를 들어 우리가 현재 작업 중인 브랜치에서(새로 만든 브랜치가 없다면 기본은 master 브랜치이다28938473891(커밋 해시)를 커밋했다고 하자. 이때(HEAD->master)는 HEAD가 master 브랜치를, master는 28938473891 커밋을 가리킨다.
git checkout --가 : 가의 수정된 내용을 없애고 저장소의 최신 상태로 되돌려줌(수정된 가가 스테이징 전인 경우에 가능)
git reset HEAD 가 : 가 파일을 unstage 한다(스테이징 취소)
git reset HEAD^ : 가장 최근의 커밋 취소
git reset --hard (해시) : 해시에 해당하는 커밋을 최근 처밋으로 정한다 (그 이후의 커밋은 모두 삭제됨)
git revert (해시) : 해시에 해당하는 커밋으로 되돌리되, 그 이후의 커밋은 삭제 되지 않고 따로 보관된다3. 브랜치 관리
앞서 2)에서 브랜치는 가장 최근의 커밋을 가리키는 포인터 같은 존재라고 하였다. 깃으로 버전 관리를 시작하면 기본적으로 master 브랜치가 만들어진다고도 하였다. 만약 master 브랜치에 저장된 파일을 유지하면서, 기존 파일 내용을 수정하거나 새로운 기능을 구현한 파일을 추가하는 것도 필요할 땐 어떻게 해야할까? master 브랜치에서 파생된 새 브랜치를 만들면 된다. 이를 분기라고 한다. 반대로 다른 브랜치에서 만든 작업을 master 브랜치에 합치고 싶을 때, 그렇게 할 수도 있다. 이를 병합이라고 한다.
- 분기와 병합
git branch : 브랜치 확인 (출력된 브랜치들 중 이름 앞에 *가 표시된 브랜치가 현재 작업 중인 브랜치이다)
git branch 가 : 가라는 브랜치 생성
git log --oneline --branches : 브랜치별 커밋 확인
git log --oneline --branches --graph : 브랜치간 관계 확인 (분기와 병합의 과정을 알 수 있음)
git log 가..나 : 가 브랜치 대비 나의 차이점(가에는 없고 나에만 있는 커밋)
git checkout 가 : 가 브랜치로 이동
git checkout -b 가 : 가 브랜치가 없으면 생성 후 이동, 있으면 이동
git merge 나 : 현재 브랜치에 나 브랜치를 병합
git branch -d 가 : 가 브랜치 삭제만약 가 브랜치에 나 브랜치를 merge할 때 충돌이 일어나면 어떻게 될까?
1) 다른 파일 : 가에 없는 파일이 나에 있다면 충돌 없이 가에 파일이 추가된다
2) 같은 파일 다른 위치 : 충돌 없이 auto-merging이 이루어진다
3) 같은 파일 같은 위치 : 충돌 발생 (같은 파일의 같은 위치에 대하여 가의 내용과 나의 내용이 다르면 충돌이 발생한다)
충돌이 발생하면 직접 파일을 열어 수정하고, 스테이징하고, 커밋하면 된다.
- 커밋 전 다른 파일을 수정하고 싶을 때
브랜치에서 작업할 때 아직 수정을 마치지 않아 커밋하지 않은 파일이 있는 상태에서 다른 파일을 수정해야하는 상황이 생길 수도 있을 것이다. 그럴 땐 다음과 같은 명령어들을 사용할 수 있다.
git stash : 스테이징하지 않은 수정된 파일들을 따로 보관함
git stash list : 따로 보관되어있던 파일들을 보여줌
git stash pop : 가장 최근 보관된 항목을 보여줌
git stash drop : 가장 최근 보관된 항목을 삭제해줌스택으로 저장되기 때문에 가장 최근에 들어온 파일이 가장 먼저 보여지고 삭제된다.
4. 원격 저장소
지역 저장소는 주로 내 컴퓨터가 된다. 만약 다른 컴퓨터에서 작업해야할 때 (직장->집, 노트북->컴퓨터) 지역 저장소만으로는 불가능하다. 또한, 지역 저장소만 사용하면 컴퓨터가 망가졌을 때 파일을 모두 잃게 된다. 따라서 우리는 지역 저장소와 원격 저장소를 연결하여 하드웨어보다 비교적 안정적인 서버 공간에 파일을 백업해줘야 한다.
git remote add origin (원격저장소 주소) : 지역 저장소와 원격 저장소 연결
git remote -v : 연결 확인
git push -u origin master : 원격 저장소(origin)의 master branch에 지역 저장소의 브랜치를 푸시
git push -u origin 가 : 원격 저장소의 가 브랜치에 푸시
git push : git push -u origin 명령어를 한 번 사용하고 나면 이후부턴 git push만으로 가능
git pull (origin master) : 원격 저장소(origin)의 내용을 지역 저장소의 master 브랜치에 가져옴. origin, master는 생략 가능
git fetch : 원격 브랜치의 변화를 풀 하기 전 확인하고 싶을 때 사용하는 명령어
git checkout FETCH_HEAD : fetch로 가져온 원격 브랜치의 최신 커밋을 보여줌
$git checkout master $git merge FETCH_HEAD : 지역 저장소의 master 브랜치로 다시 이동한 후, 원격 브랜치의 변화를 지역 브랜치에 병합
git clone (원격 저장소 주소) : 원격 저장소를 내 컴퓨터에 복제5. 깃 프로그램(여기에선 깃허브)에서 협업할 때 기능들
- new pull request : 지역저장소에서 푸시한 새 브랜치를 pull request로 병합해야 원격 저장소에 반영될 수 있음
- merge pull request : new pull request로 새 브랜치의 내용들을 확인한 후, 병합해도 된다고 생각하면 원격 저장소의 master에 pull함
- fork : 깃허브의 다른 저장소를 자신의 깃허브 저장소로 복제
끝!
출처 : <Do it! 지옥에서 온 문서관리자 깃&깃허브 입문>
