Polpid's Pensieve

IntelliJ 2020.3 의 기능 중에 Git 스테이징 지원 이라는 항목이 있다.

그래서 이걸 써보려고 위에 나와있는 것 처럼 환경 설정을 확인해봤다.

그런데 Git 설정을 들어가 보니 위의 그림처럼 Enable staging area 가 비활성화 되어있다. (처음에는 체크가 안된 상태로 비활성화 되어있었다. ) 

이것때문에 한참을 찾았는데 다음과 같이 해결을 하면 된다.

Version Control > Commit 항목에 보면 Use non-modal commit interface 라는 항목이 있다. 이걸 체크해주고 apply 해주면 위에 Enable staging area 가 활성화 된다.

활성화를 하고 나면 위와 같이 staged, unstaged 항목을 볼 수 있는 창을 사용할수 있게 된다.

Git 을 사용하면서 pull 을 받을때 다른 브랜치를 pull 받는 경우가 있다.

예를 들어서 나는 현재 A 브랜치에서 작업을 하고 있다. 그런데 B 브랜치의 내용을 A 브랜치로 pull 을 받아야 한다. ( 왜 이렇게 사용하냐고 묻는 다면.. 어쩌다 보니 이렇게 사용하게 됐다..)

그래서 한가지 궁금한게 생겼다. 

다른 브랜치를 pull 받는것과 merge 하는것과 차이가 있을까???

그럼 한번 실험을 해보자.

- master 브랜치, dev01 브랜치 생성

먼저 위 그림을 보자. 위 상황은 다음과 같다.

1. master 브랜치에서 test1.md 파일 생성후 커밋

2. dev01 브랜치 생성

3. dev01 브랜치에서 test2.md 파일 생성

- dev02 브랜치 추가 , test3.md 파일 추가 

그럼 위와 같은 상태가 된다.

- dev01 브랜치로 돌아가서 test2.md 파일 수정

1. dev01 브랜치로 checkout

2. test1.md, test2.md 파일 수정

3. 커밋

- dev02 브랜치로 가서 dev01 브랜치 pull

dev02 브랜치에 있는 tet1.md 파일과 test2.md 파일은 변경이 되지 않은 상태이다.

여기에서 다음가 같이 명령어를 쓴다.

git pull . dev01

리모트 저장소에 push 된 상태라면 명령어는 다음과 같이 된다. (지금 화면에서는 내가 리모트 저장소에 push 를 안한 상태로 local 만 사용중이기 때문에 . 을 사용한다.)

git pull origin dev01

음??  merge 를 한다고 나오네??

저장을 하게 되면 Git graph 는 다음과 같이 나온다.

결과적으로 서로 다른 브랜치에서 pull을 하게 되면 merge 를 하는것과 동일하게 동작을 한다.

-  Merge 확인해보기

dev03 브랜치를 만들어서 dev01 로 merge 를 해보자.

dev03 브랜치에서 test4.md 파일을 만들고 커밋을 했다.

dev02 에서 merge 를 한다는 것이 dev01 에서 merge 를 해서  dev01 도 표현이 되었다.

위와 약간 차이가 있어서 다시 해보겠다.

위 사진은 다음과 같이 실험한 결과이다.

1. dev02 브랜치에서 test5.md 생성 후 커밋

2. dev03 브랜치 checkout

3. dev03 브랜치에서 test4.md 파일 수정 후 커밋

4. dev02 브랜치로 다시 checkout

5. dev02 브랜치에서 dev03브랜치 merge

결과적으로 아래 Merge branch 'dev01' into dev02 와 동일한 그래프가 나타난다.

내가 내린 결론은 현재 브랜치에서 다른 브랜치를 pull하게 되면 merge와 동일한 동작을 하게 된다 라는 것이다.

....  혹시 글을 읽고 잘못된 점이 있으면 댓글로 알려주세요. (제가 잘못 이해한것 일수도 있어서..)

로컬 브랜치 삭제

git branch -d 브랜치 명

리모트 브랜치 삭제

git push origin --delete 브랜치명

가끔 이런 경우가 있다.

1. master 브랜치에서 현재 소스 기준으로 tag 를 생성한다. 

git tag release-v1.0

2. 그리고 나서 다른 작업들이 쭉~~ 진행 된다. 그러다가 갑자기 release-v1.0 에 대한 버그가 발견되었다. 그럼 어떻게 하지?? 

master 브랜치에는 신규기능을 개발중이거나 다른 작업들이 진행중이어서 bug fix 를 반영하더래도 v1.0 하고는 소스가 다른데... 구글링을 해보니 다음과 같은 절차를 이야기 해주고 있다.

git checkout -b bugfix1 release-v1.0

이렇게 한 후 버그를 고치고 commit 을 한다. 

git tag release-v1.1

그리고 버그를 수정한 거에 대한 tag 를 다시 생성한다. 이렇게 하면 이제 release-v1.1 소스를 가지고 배포를 하면 된다. 

그리고 마지막으로 현재 수정한 bug 를 master 에도 반영한다.

git checkout master

git merge bugfix1

버전관리 하면서 알아두면 유용하게 사용할수 있을것 같다. 

참고url 

https://gist.github.com/adonaldson/1205902

Git 을 사용하다 보면 branch 를 만들어서 사용하게 된다. 그런데 어느 순간 보면 branch 가 여러개로 늘어나 있고 무엇을 하던 branch 인지 조차도 기억이 안나게 된다.

그래서 branch를 삭제를 했다. 난 분명히 branch 를 삭제를 했는데..

git branch --all 을 하면 삭제된 remote 브랜치가 여전히 나온다.. 내가 안지웠나???

그래서 직접 git 사이트에 들어가 봤더니 삭제한 브랜치는 나오지 않는다..

이때 다음과 같이 실행을 하면 된다.

git remote prune origin 

이렇게 하고 다시 git branch --all 을 하게 되면 삭제된 브랜치는 나오지 않는다.

참고

https://git-scm.com/docs/git-remote

현재 브랜치와 다른 브랜치 사이에 merge가 아닌 특정 파일만 합치고 싶을때의 방법이다. 

git -p [브랜치명] -- [파일경로]

브랜치명 : 합쳐야 하는 내용들이 있는 브랜치 명을 입력하면 된다. (현재 브랜치가 아님)

파일경로 : 파일 path 를 넣으면 된다.

파일 경로 입력할때 다음과 같이 찾아보면 편리하다.

git diff --name-status [브랜치명]

이렇게 하면 현재 브랜치와 [브랜치명]에 있는 브랜치의 다른점 목록이 나온다. 

이 경로로 입력을 하면 된다. 

gitignore 파일을 작성을 했는데 이상하게도 계속 해당 파일들이 Untracked Files 에 잡혔다.

그런데 분명히 내가 작성한 gitignore 파일에는 다음과 같이 존재하고 있었다.

.idea/

.DS_Store

그래서 구글링을 해보니 아래와 같이 해결책을 제시해줬다.

https://stackoverflow.com/questions/32384473/gitignore-not-ignoring-idea-path

첫번째 시도

git rm -rf .idea/

Git에서 파일을 제거하려면 git rm 명령으로 Tracked 상태의 파일을 삭제한 후에(정확하게는 Staging Area에서 삭제하는 것) 커밋해야 한다. 이 명령은 워킹 디렉토리에 있는 파일도 삭제하기 때문에 실제로 파일도 지워진다.

<출처 : https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EC%88%98%EC%A0%95%ED%95%98%EA%B3%A0-%EC%A0%80%EC%9E%A5%EC%86%8C%EC%97%90-%EC%A0%80%EC%9E%A5%ED%95%98%EA%B8%B0>

그랬더니 다음과 같은 메세지가 나왔다.

fatal: pathspec '.idea/' did not match any files

상황을 보아 하니 rm 명령어가 Tracked 상태의 파일을 삭제하는 명령어 인데 위 파일들은 tracked 되지 않은 파일이기 때문에 없다고 나온것 같다.

두번째 시도

git clean -f -d .idea/

일단 이렇게 하니깐 Untracked 파일들이 다 지워지긴 했다.

그럼 이 명령어가 무엇을 의미하는지 한번 살펴보자.

워킹 디렉토리 청소하기

작업하고 있던 파일을 Stash 하지 않고 단순히 그 파일들을 치워버리고 싶을 때가 있다. git clean 명령이 그 일을 한다.

<출처 : https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-Stashing%EA%B3%BC-Cleaning >

결과적으로 Untracked 파일들을 모두 지운다는 의미이다.... -_-;; 좀 무서운 명령어다.  설명에도 다음과 같이 써있다.

한마디로 한번 지우면 되돌릴수 없다라는 의미이다. 

문제를 해결 하긴 했지만 위 명령어를 사용할 때에는 좀 신중할 필요는 있어보인다.

아침 저녁으로 출퇴근 하면서 생활코딩의 "지옥에서 온 Git" 을 듣고 있는데 재미있는 내용이 있었다.

https://www.youtube.com/playlist?list=PLuHgQVnccGMA8iwZwrGyNXCGy2LAAsTXk

Git 을 사용하면 프로젝트 폴더 안에 .git 이라는 폴더가 생긴다. 생긴다라고만 알고 있었고 여기에 뭔가 history 가 저장되겠거니 라는 추측만 했었다. 실제로 열어본적도 없어서 뭐가 들어있는지도 몰랐다. 그런데 강의 내용중에 Git 명령어를 실행될 때에 어떻게 그 History를 저장하고 추적하는지에 대해서 설명을 해주었다. 

Git 을 사용할 경우 Add 명령을 이용해서 새로 생성된 파일을 stage area 영역으로 추가할수 있다. 이때에 .git 디렉토리 안에 objects 라는 폴더에 새로운 폴더가 생성된다. 

왼쪽 화면과 오른쪽 화면을 보자. 왼쪽화면은 잘은 안보이겠지만 현재 내가 작업하고 있는 WORKSPACE 에서 파일을 수정하고 "git status" 명령어를 실행했을 때의 모습이다. 빨갛게 파일 이름이 보이고 modified 라고 써있다. 그리고 오른쪽은 gistory 라는 git log 분석하는 툴이다. 오픈소스 툴이며 https://github.com/egoing/gistory 에 가면 설치 방법을 확인 할 수 있다. 내가 지금가지 commit 한 내용이 오른쪽 처럼 표현되고 있다. 

이제 좀전의 build.gradle 파일을 ADD 명령어를 이용해서 ADD를 했다. 어떤 변화가 일어났는지 확인을 해봤다. 오른족에 보면 맨 위에 2개 파일에 just now라고 써있다. 그 2개가 변경이 됐다는 의미이다.

우선 objects를 선택해서 보니 내가 변경한 파일의 내용이 보여진다. [blob]a97..... 라는 key로 되어있다. 그리고 보면 앞에 a9는 objects 폴더의 하위 디렉토리 명으로 되어있다. 

이번에는 좀전에 그 파일을 commit 을 해보았다. 그랬더니 위에 화면처럼 많은 파일들이 변경이 되었다. 그중 몇개 파일을 살펴 보았다.

이 파일에는 [commit] 이라는 타입의 object 이다. 안에 내용을 보면 tree 라는 것이 있고 parent 라는 것이 있다. 그리고 commit 을 한 사람 정보가 나오고 마지막에는 commit 할때 작성했던 message 가 있다. tree 는 현재 commit 한 시점의 모든 file 들이 tree 형태로 존재를 하고 있다. 그리고 parent 는 이전 commit 에 대한 정보들을 담고 있는 object 이다. parent 도 tree 처럼 구성이 되어있을 것이다. 이처럼 commit 을 하게 되면 현재의 파일들을 현재 모습 그대로 snapshot을 찍게 된다. 

그리고 tree 를 클릭해보면 이렇게 파일들을 볼수 있다. 파일의 형태는 단일 파일일 경우 blob 으로 표시 되어있고 또 폴더 일 경우 tree 로 표시가 되어있다. 

결론적으로 Git 이라는 툴은 파일이 변경되고 추가되고 한 작업의 모든 부분을 object 화 해서 관리를 하고 있다. 그 object 가 단일파일일 경우도 있고 tree 형태를 할 경우도 있다. 그리고 commit 자체도 하나의 object 로 관리가 되고 있다. 이런 형태로 파일들이 관리가 되고 있었다니 정말 놀라웠다. 

Git을 쓰고 있긴 하지만 부족한것 같아서 듣기 시작한 강의 였는데 정말 듣기를 잘했다는 생각이 들었다. 아직 다 듣지 않아서 앞으로 들을 내용들이 더 기대가 된다.