반응형

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 stash –all 명령을 이용하면 지우는 건 똑같지만, 먼저 모든 파일을 Stash 하므로 좀 더 안전하다.

워킹 디렉토리의 불필요한 파일들을 전부 지우려면 git clean 을 사용한다. 추적 중이지 않은 모든 정보를 워킹 디렉토리에서 지우고 싶다면 git clean -f -d 명령을 사용하자. 이 명령은 하위 디렉토리까지 모두 지워버린다. -f 옵션은 강제(force)의 의미이며 "진짜로 그냥 해라"라는 뜻이다.


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

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



728x90
반응형
반응형

명령어 절차를 매번 찾기 귀찮아서 이렇게 기록 놓기로 했다.


1. 먼저 Github에 새로운 Repository 하나를 생성한다.



2. 실제 repository에 올리고 싶은 프로젝트의 로컬 디렉토리로 이동해서 git init 명령어를 실행한다. 그리고 git status 를 실행하면 아래와 같이 나온다.



3. git add . 명령어를 실행한다. 



4. git commit -m "커밋 메세지" 를 실행한다.



5. 1번에서 만들어 놓았던 repository 의 주소를 복사한다.


6. git remote add origin 복사한 주소 를 실행한다.


7. git push -u origin master 를 실행한다. 그런 다음 아무 에러가 안나면 끝난다. 

그런데 이때 reject 가 나오는 경우가 있다. Git Repository 를 생성할때 ReadeME  파일을 생성하도록 하면 이미 commit 한 내용이 있기 때문에 pull 을 받으라고 나온다.



 그런데 막상 pull을 받으면 아래와 같이 메세지가 나온다.



이때에는 git pull origin master 라고 입력해주면 된다. 


그리고 또 혹~~ 시라도 아래와 같은 메세지가 나오는 경우가 있다.


fatal: refusing to merge unrelated histories


이 에러는 각각의 history를 가진 프로젝트를 병합 하려고 할때 나온다고 한다. 그럴 경우에는 아래와 같이 옵션을 추가해서 pull을 받아야 한다.


git pull origin <branch name> --allow-unrelated-histories


참고 사이트

https://help.github.com/articles/adding-an-existing-project-to-github-using-the-command-line/

https://hongjinseob.wordpress.com/2017/11/24/git-fatalrefusing-to-merge-unrelated-histories-%ED%95%B4%EA%B2%B0/

728x90
반응형
반응형

아침 저녁으로 출퇴근 하면서 생활코딩의 "지옥에서 온 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을 쓰고 있긴 하지만 부족한것 같아서 듣기 시작한 강의 였는데 정말 듣기를 잘했다는 생각이 들었다. 아직 다 듣지 않아서 앞으로 들을 내용들이 더 기대가 된다.


728x90
반응형

+ Recent posts