benjykim

* branch의 원리 우선 새로운 저장소를 만든다. Q. git init했을 때 내부에서 어떤 일이 일어나는가? -> head라는 파일은 git을 처음 생성했을 때 생성이 되며 동시에 refs/heads/master라고 적혀있다. 이것은 파일의 이름 의미하는데 아직 존재하지는 않고 이름만 있는 상태이다. -> commit한 뒤 head라는 파일이 어떻게 편하는지 살펴보자. * vim f1.txt (text : "a") > git add f1.txt > git commit -m "1" -> refs/heads/master 라고하는 파일이 생겼다. 클릭해보면 오브젝트 ID값을 가지고 있고 클릭하면 방금 커밋한 내용이 있다. -> 깃을 처음 초기화 하면, git 디렉터리에는 head라는 파일이 생긴다. (일..

Q. stash 란? : stash는 '감추다', '숨겨두다'라는 뜻. -> 브랜치를 활발하게 사용할 경우 사용 Q. stash하기 좋은 경우는 언제인가? 1. 브랜치에서 작업하던 내용이 다 끝나지 않았는데 다른 브랜치로 checkout해서 다른 일을 해야 하는 경우. 2. 끝나지 않은 작업을 커밋할 수는 없고 또한 커밋을 하지 않으면 체크아웃할 수 없는 경우. -> 작업했던 내용을 어딘가 숨겨 놓을 수 있다. 브랜치의 가장 최신 커밋(헤드의 버전)으로 이동해서 현재 브랜치의 상태를 깔끔하게 만들고 다른 브랜치로 체크아웃할 수 있다. * 들어가기 전 설정 1. git init > vim f1.txt (text : "a") > git add f1.txt > git commit -m "1"2. git che..

* 병합(merge)할 때 충돌(conflict)이 일어나는 경우 1) index.html 파일을 만들어서 "function a() {}' 내용을 입력한다. (master branch) * cat index.html 결과 -> git add와 commit을 진행. 2) iss1 브랜치(branch)를 만들어서 이동한다. * git branch iss1* git checkout iss1 3) index.html 파일을 수정한다. ( iss1 branch ) -> git add와 commit을 진행. 4) master 브랜치로 이동하여 index.html의 내용에 function c() {}"를 추가한다. (master branch) -> git add와 commit을 진행. * master 브랜치의 ind..

* merge 하는 방법 ( 작업들은 어느 시점에서 병합해야 할 순간이 필요하다. ) * git log --branches --graph --decorate --oneline 명령을 통해 현재 상태를 본다. * 지금까지 exp에서 작업했던 내용을 master로 병합하는 방법을 살펴보겠다. (exp 를 master로 옮기는 방법) -> 3,4라는 커밋의 내용을 master 브랜치도 갖게 하는 것이 첫번째 목표이다.master 브랜치로 체크아웃한 다음에 merge를 한다. * git merge exp Q. 현재 마스터는 어떤 커밋으로 체크아웃됐나? -> 방금 자동으로 작성된 커밋 메세지가 있는 커밋이 마스터의 최신 커밋이 됐다. 그리고 이 커밋은 두 개의 부모 커밋을 갖는다. 1) 원래 마스터가 가지고 있는..

* git bash에서 branch를 직관적으로 보고 싶은 경우 * git log --branches --decorate --graph --oneline * branch 간의 차이를 확인하고 싶을 때 * git log master(branch)..exp(branch)-> master에는 없고 exp는 있는 것을 보여줌 * git log -p master..exp : -p 옵션을 써서 branch 간의 소스코드 차이를 구체적으로 볼 수 있음. * git diff master..exp : diff도 마찬가지. -> log와 diff 명령을 통해 각각의 브랜치 사이의 차이점을 알 수 있다. *이 포스트는 이고잉님의 '지옥에서 온 Git'강의를 참고하여 작성했습니다.URL : https://opentutoria..

Q. branch 란? : 작업이 분기되는 현상을 말한다. ( branch를 만든다. ) -> 기본적으로 작업을 진행해왔다면 기본적으로 하나의 branch를 가지고 있는 것이다. Q. branch하기 좋은 경우는 언제인가? 1. 고객사에게 커스텀된 기능을 추가하는 경우.-> 원래 코드를 변경하지 않으면서 그 고객을 위한 커스터마이징에 해당되는 기능을 추가해야하는 경우. 2. 필요하지 않은 기능을 만들어 달라고 할 경우, branch를 만든 뒤 나중에 해당 branch를 버리면 된다. 3. 작업한 것(테스트를 위한 코드)을 서버에 반영할 때 따로 (테스트를 위한)branch를 만들어 관리한다. * git branch 관련 명령어 정리 1. 브랜치의 목록을 볼 때git branch 2. 브랜치를 생성할 때 ..

* Index와 objects 파일을 비교하면 커밋할 것이 있는지 없는지를 확인할 수 있다. -> 예를 들어 working directory의 d1/f1.txt와 index의 d1/f1.txt의 내용이 일치한다면 현재 커밋할 것이 없다. ( working directory는 git bash에서 작업하는 디렉터리로 이해하면 된다.) 1. f1.txt 의 파일을 수정한 뒤 git status를 하면 f1.txt가 빨간색 텍스트로 표시된다. -> 결국 gistory에서 working directory의 f1.txt의 내용과 Index상에서의 f1.txt의 내용이 다르면 파일이 수정된 것을 알 수 있다. -> 이후 git add f1.txt를 한 뒤 다시 gistory를 reload 하면 수정한 내용이 반영됨을..

* 들어가기 전 설정 1. f1.txt(text : a), f2.txt(text : b), f3.txt( cp f1.txt f3.txt ) 2. git add f1.txt f2.txt f3.txt3. git commit 4. commit message : 1 -> 커밋 메세지에 해당되는 정보가 objects 안에 저장되어있다.commit을 하면 버전(commit message)도 파일의 내용처럼 objects안에 들어간다.( 결국 커밋도 내부적으로는 객체라고 할 수 있다. ) 커밋 안에는 누가 커밋을 했는지에 대한 정보가 적혀있다.그리고 tree 옆에는 object가 링크되어있다.( tree는 f1.txt이라는 파일과 f2, f3 각각의 파일의 내용이 무엇인지에 대한 정보가 담겨있다. ) -> 방금 우리..

* 파일의 이름이 결정되는 메커니즘이 무엇을 사용하고 있는지 알아보자. 1. 우선 구글에서 sha1 online을 검색하여 http://www.sha1-online.com에 접속한다. 2. 화면에서 "hello"를 입력한 뒤 hash를 눌러보자. -> hello라고 하는 정보는 hash라는 매커니즘을 통과하면 'aaf4....34d'라는 일정한 길이의 텍스트를 얻어낼 수 있다. -> 즉 깃은 'sha1'이라는 해쉬 알고리즘을 통과시켜서 그 파일의 이름을 도출한 다음, aaf4...34d(해쉬값)에서 앞 2글자를 따서 aa라는 폴더를 만들고 f4....34d라는 파일을 만들어서 그 안에다가 hello라는 정보를 저장한다. (실제로는 hello라는 정보만 들어가는 것이 아니고 부가적인 정보 또한 포함된다.)..

* git bash에서 작업한 내용입니다. 1. mkdir gitfth2 2. git init 3. vim f1.txt (text : 'a' 입력) //t1.txt를 만든 뒤 git add를 하지 않으면 gistory에 반영되지 않는다. 4. git add f1.txt //이 명령(add) 이후부터 gistory에 f1.txt의 내용이 반영된다. 5. vim f2.txt (text : 'z' 입력) 6. git add f2.txt 7. cp f1.txt f3.txt 8. git add f3.txt * 1~8의 명령을 수행한 뒤 gistory 화면 결과 * 1번째 오브젝트를 클릭한 결과 (\78\981922..........4e85는 78번 디렉터리에 있는 981.....e85파일을 의미한다._ * 2번째..