smallbee

02 Git

2018-01-16

03 GIT

TABLE

01. Note
02. Storehouse
03. Site
04. Bookmark
05. Question



##01 Notetaking

CVCS의 문제점은 서버가 죽으면 끝

DCVS 저장소를 전부 복사. 로컬 = 서버 서버의 내용과 로컬의 내용이 상관이 없음. 최소 서버에서 받아온 시점까지는 복구가능


기존에는 서버에 접속해서 올리고 내리고. 이것이 불편. 항상 네트워크에 항상 연결되어 있어야함. 나중에 엄청나게 많은 변경사항을 한꺼번에 올려버림.
vs
내 저장소에 이것저것 저장해놓고 나중에 서버에 한꺼번에 변경사항을 다 기록함.


해당 시점으로 돌아가는 역할을 할 때 훨씬 효율적 링크라는 방법으로 해결. 가장 최근 시점을 표현하는데 가장 효율적이고 빠르다. 가장 최근 변경사항 한번만 가져오면 되기 때문. Branch는 다 있지만 Git의 branch는 가볍다. 아까 그 snapshot 때문에? 다른 서비스는 코드를 복사해야했는데 git은 그냥 링크만 줌.


데이터는 따로 있고 그 데이터에 접근하기 위한 키가 필요. ex) 방 번호같이 배정해주면 그 안에 데이터가 쌓여있음. 무결성이란 것은 수억개의 방이 생겨도 항상 겹치지 않는 방이 생김. 데이들이 겹치지 않는다는 것을 무결성이라 함. 16의 40승의 확률. 해시 : 임의의 길이의 데이터를 고정된 길이의 데이터로 매핑하는 함수이다.

Git에서 기록을 삭제할 수는 없음. 삭제하려면 commit 자체를 삭제하고 새로운 commit을 만들어야함. 그러나 저장소에 한번 저장된 것은 지우지 못함.


aws의 고유 값이 기수마다 Git에 포함이 계속 되서.. 이게 유출되면 비트코인 채굴에 쓰여서 서버비가 수백만원씩 발생할 수 있음.


Git hub와 Git과 관련이 없음 -ㅅ-; 2등으로 bitbucket.org private 저장소 공짜. github student


다른 사람 컴퓨터에 접근할 때는 오히려 GUI가 더 복잡함.


###본격적인 실습내용 시작

git commit -m ‘ ‘ 할 때 화살표 위키 누르면 이전에 한것 불러온다.


untracked는 git에서 관리되지 않기때문에 전혀 차이 상황을 볼 수 없다.


.DS_Store는 desktop store의 약자로 데스크탑 관련 정보를 넣음. git에는 필요없는 정보.


비어있는 폴더는 untracked에도 표시안됨?


git add [ ] : 의 경우 modified된 파일만 staged됨.


stage area 생략하기는 아직 쓰지 않음.


git rm 명령으로 git에서 삭제하는 것까지 알아서 해줌.


rm 이나 mv 모두 add 안해도 알아서 해줌 pretty 는 한줄로 보여줌


checkout 하면 다시 되돌릴 수 있는 방법이 없음.


release한 다음 zip 파일 링크를 보내주면 다운받을 수 있음


git에서는 파일 하나 단위를 blob이라고 부른다.


정보가 들어있는 것이 트리개체하나(초록색) 밑에 뭐가 연결되어있기 때문에. 트리의 가장 처음부분을 root tree

처음 커밋이후에 또 하면 다음에는 parent와 연결이되고 또 하면 parent가 도 다시 연결이됨

포인터 개념. 커밋을 가르키는 것도 포인터 여기서 커밋은 데이터를 가르킴

HEAD : 지금 가르키고 있는 로컬 브랜치를 의미 git branch는 HEAD 포인터가 있는데에서 생김. head some(앞의 숫자들)으로도 이동가능


rm -rf .git 으로 git에 관한 정보를 모두 날려버리고 다시 시작할 수 있음

clone은 맨 처음에만 쓰는것

checkout master 하는게 스냅샷 찍는 것이라 이해하면 됨.


Conflict 충돌실험

A와 B

  1. A가 index.html의 특정부분 수정 후 커밋 -> 푸시
  2. B도 index.html의 같은부분을 수정 후 커밋 -> 푸시 시도(실패)
  3. B가 리모트 저장소의 내용을 fetch받아와서 자신의 커밋에 auto merge 시도(conflict)
  4. B가 conflict가 생긴 index.html을 적절히 수정해서 3-way merge commit을 만들고 해당 내용을 push
  5. A는 B가 올린 커밋을 fetch후 merge적용(실패없이 진행되어야 함)


checkout iss53에서 master로 merge 할 수는 없음. 왜냐면 iss53이 더 최신이기 때문에.


다 되면 dev 라는 branch에 합침. 한번씩 release함.

원래는 branch도 안정되야..

master - develop - topic 실서버 개발자통합 개발자개개인

콜래보래이터 업ㅅ없으면 비공개 프랜치는 푸시 안하면 비공개에요.


헉! CONTRIBUTING.md`가 Staged 상태이면서 동시에 Unstaged 상태로 나온다.
2.2 Git의 기초 - 수정하고 저장소에 저장하기

이미 올라가 있는 것에 대해서 ammend나 rebase를 절대 하면 안된다. 1) 이미 푸시한 것을 rebase 하면 다른 사용자에게 없앤 것이 있는 것으로 봐서 새로운 쓰리웨이가 생김. 2) 이미 푸시한 것을 ammend 해서 강제로 –force푸시하면 또 충돌남.



##02 Storehouse

  • 체크섬
 Git은 데이터를 저장하기 전에 항상 체크섬을 구하고 그 체크섬으로 데이터를 관리한다. 그래서 체크섬을 이해하는 Git 없이는 어떠한 파일이나 디렉토리도 변경할 수 없다. 체크섬은 Git에서 사용하는 가장 기본적인(Atomic) 데이터 단위이자 Git의 기본 철학이다. Git 없이는 체크섬을 다룰 수 없어서 파일의 상태도 알 수 없고 심지어 데이터를 잃어버릴 수도 없다.  
Git은 SHA-1 해시를 사용하여 체크섬을 만든다. 만든 체크섬은 40자 길이의 16진수 문자열이다. 파일의 내용이나 디렉토리 구조를 이용하여 체크섬을 구한다. SHA-1은 아래처럼 생겼다.  
24b9da6552252987aa493b52f8696cd6d3b00373  
Git은 모든 것을 해시로 식별하기 때문에 이런 값은 여기저기서 보인다. 실제로 Git은 파일을 이름으로 저장하지 않고 해당 파일의 해시로 저장한다.


  • rm -rf .git
 git 파일을 지워야 할때


  • git commit -m ‘변경사항’
 git commit 을 입력한 후 vim창에서 변경사항을
 입력하는 과정을 단순화 한것.


  • git add –all or add -A
 현재 디렉토리의 모든 파일을 추가


  • git log -p
 git log의 결과에서 diff까지 추가된 명령어
 여러 옵션 중 `-p`는 굉장히 유용한 옵션이다. 
 commit 한 파일의 파일명까지 보여준다.
 `-p`는 각 커밋의 diff 결과를 보여준다. 다른 유용한 
 옵션으로 `-2`가 있는데 최근 두 개의 결과만 보여주는 옵션이다:


  • git log –all
 서버의 내용까지 반영해서 log를 보여주기 때문에
 fetch 이후에는 git log 와 차이가 없어지게 된다.


  • git log –oneline –all –graph
 첫번째 줄에서 *가 선으로 표시되기 때문에
 좀 더 눈에 띄는 모양으로 볼 수 있음


  • git diff
 modified 와 staged의 차이를 보여준다.


  • git diff ‘버전 id’..’버전 id2’
 버전 간의 차이점을 비교할 때


  • git diff –staged or –cashed
 staged 안에서의 commit 차이를 보여준다.


  • git diff [ ] .. [ ]
 staged 안에서의 commit 차이를 보여준다.


  • git clone https://github.com/smallbee3/Git-Practice.git
$ git clone https://github.com/smallbee3
 /Git-Practice.git get-practice 
 -> 폴더명까지 적어두면 만들어서 거기에 넣음.


  • __git remote add [remote 저장소에 붙일 단축이름] [remote 저장소 url] __
 git 주소에 현재 origin 추가
 ex)
$ git remote add origin https://github.com/smallbee3/Git-Practice.git
  • git remote
  현재 프로젝트에 등록된 리모트 저장소를 확인할 수 있다. 이 명령은 리모트 저장소의 단축 이름을 보여준다.
  • git remote -v
 리모트 저장소의 단축이름과 URL을 함께 볼 수 있다. 리모트 저장소가 여러 개 있다면 이 명령은 등록된 전부를 보여준다.
  • git remote
좀 더 Git을 열심히 사용하다 보면 git remote show 명령으로 더 많은 정보를 보는 날이 온다. 여러분도 언젠가는 아래와 같은 메시지(역주 - 다수의 브랜치를 사용하는 메시지)를 볼 날이 올 것이다.  
브랜치명을 생략하고 git push 명령을 실행할 때 어떤 브랜치가 어떤 브랜치로 Push 되는지 보여준다. 또 아직 로컬로 가져오지 않은 리모트 저장소의 브랜치는 어떤 것들이 있는지, 서버에서는 삭제됐지만 아직 가지고 있는 브랜치는 어떤 것인지, git pull 명령을 실행했을 때 자동으로 Merge 할 브랜치는 어떤 것이 있는지 보여준다.
  • git remote rename [기존단축이름] [새로운이름] 
     예를 들어 pb`를 `paul`로 변경하려면 
 `$ git remote rename pb paul'  
 이라는 명령을 사용한다.


  • git remote remove(rm) [remote-name]
서버 정보가 바뀌었을 때, 더는 별도의 미러가 필요하지 않을 때, 더는 기여자가 활동하지 않아 리모트를 삭제해야할 때 필요하다.
 ``` <br>
 

- __git branch__

현재 branch 목록과 HEAD 상황을 보여줌

 <br>

 
- __git branch -v__

branch의 현재 상황 조회 git status와 비슷한 역할

 <br>
 
 
 - __remote branch 리모트브랜치__ 

 ```리모트 트래킹 브랜치는 리모트 브랜치를 추적하는 브랜치다. 이 브랜치는 로컬에 있지만 움직일 수 없다. 리모트 서버에 연결할 때마다 리모트 브랜치에 따라서 자동으로 움직일 뿐이다. 리모트 트래킹 브랜치는 일종의 북마크라고 할 수 있다. 리모트 저장소에 마지막으로 연결했던 순간에 브랜치가 무슨 커밋을 가리키고 있었는지를 나타낸다.
리모트 브랜치의 이름은 (remote)/(branch) 형식으로 되어 있다.


중급 명령어

  • –amend
 종종 완료한 커밋을 수정해야 할 때가 있다. 너무 일찍 커밋했거나
 어떤 파일을 빼먹었을 때 그리고 커밋 메시지를 잘못 적었을 때 한다.
 다시 커밋하고 싶으면 --amend 옵션을 사용한다.
 .
 Modified 파일 되돌리기 쓰면 문제가 있음
 .
 바로 전 것 까지만 다 삭제하는 방법이 amend
 내 local에서 만큼은 기록을 전부 삭제할 수 있다.


  • git fetch [remote-name]
이 명령은 로컬에는 없지만, 리모트 저장소에는 있는 데이터를 모두 가져온다. 그러면 리모트 저장소의 모든 브랜치를 로컬에서 접근할 수 있어서 언제든지 Merge를 하거나 내용을 살펴볼 수 있다.
설명1)
git fetch 명령은 리모트 저장소의 데이터를 모두 로컬로 가져오지만, 자동으로 Merge 하지 않는다. 그래서 당신이 로컬에서 하던 작업을 정리하고 나서 수동으로 Merge 해야 한다.
설명2) 
git fetch하고 git log로 확인하면 별도의 master
가 생성된 것을 확인할 수 있고 이후에 git merge
origin/master를 하면 가져온 branch를 master와
합쳐서 git log를 보면 합쳐진 결과를 확인할 수 있다


  • git push origin master –force
 기존 서버에있는 내용을 무시하고 강제로 푸쉬하는 명령어


  • git tag -a v1.0 -m ‘1.0 version is ready’
 git 파일에 태그를 달아 정보를 표시하는 방법
 이후 git log를 통해 확정본 시겹ㄹ자를 확인할 수 있다.


  • git push origin [tag-name]
 tag를 달면 서버에 반영이 안되기때문에
 푸시까지 해주어야 한다.
 * 다른 사용자가 이미 태그를 푸시를 했으면
 해당 버전에는 오류메시지가 출력되며 푸시가 되지 않는다.
To https://github.com/smallbee3/Git-Practice.git
 ! [rejected]        v1.0 -> v1.0 (already exists)
error: failed to push some refs to 'https://github.com/smallbee3/Git-Practice.git'
hint: Updates were rejected because the tag already exists in the remote.


  • .gitignore
 로그 파일이나 빌드 시스템이 자동으로 생성한 파일 등을 무시하려면
.gitignore 파일을 만들고 그 안에 무시할
파일 패턴을 적는다.

- .gitignore 파일에 입력하는 패턴은 아래 규칙을 따른다.
- 아무것도 없는 라인이나, `#`로 시작하는 라인은 무시한다.
- 표준 Glob 패턴을 사용한다.
- 슬래시(/)로 시작하면 하위 디렉토리에 적용되지(Recursivity) 않는다.
- 디렉토리는 슬래시(/)를 끝에 사용하는 것으로 표현한다.
- 느낌표(!)로 시작하는 패턴의 파일은 무시하지 않는다.

- 확장자가 .a인 파일 무시
*.a
- 윗 라인에서 확장자가 .a인 파일은 무시하게 했지만 lib.a는 무시하지 않음
!lib.a
- 현재 디렉토리에 있는 TODO파일은 무시하고 subdir/TODO처럼 하위디렉토리에 있는 파일은 무시하지 않음
/TODO
- build/ 디렉토리에 있는 모든 파일은 무시
build/
- doc/notes.txt 파일은 무시하고 doc/server/arch.txt 파일은 무시하지 않음
doc/*.txt
- doc 디렉토리 아래의 모든 .pdf 파일을 무시
doc/**/*.pdf


  • git rm –cached README
 Staging Area에서만 제거하고 워킹 디렉토리에 있는 파일은 지우지 않고 남겨둘 수 있다.
다시 말해서 하드디스크에 있는 파일은 그대로 두고 Git만 추적하지 않게 한다. 
이것은 .gitignore 파일에 추가하는 것을 빼먹었거나 대용량 로그 파일이나 컴파일된 파일인 .a 파일 같은 것을 실수로 추가했을 때 쓴다.
cached 옵션을 사용하여 명령을 실행한다.


  • git reset HEAD [file] git reset –hard HEAD [file]
 1) Stage 상태의 파일을 Unstage로 변경하기
 a. modified에서 staged로 바꾸거나  
 b. untracked에서 staged로 바꾸거나 (새파일)
 둘 중에 하나인 것을 다시 되돌림.
 git reset 명령은 매우 위험하다.
 2) HEAD~1 뒤에 숫c자는 가장 최근 commit에서 부터 날려버리는 개수 
 3) --hard 옵션과 함께 사용하면 working directory의 파일에까지 영향이 간다.


  • git checkout – [file]
Modified 파일 되돌리기
이 명령은 꽤 위험한 명령이라는 것을 알아야 한다. 원래 파일로 덮어썼기 때문에 수정한 내용은 전부 사라진다. 수정한 내용이 진짜 마음에 들지 않을 때만 사용하자.
변경한 내용을 쉽게 버릴수는 없고 하지만 당장은 되돌려야만 하는 상황이라면 대신 Stash와 Branch를 사용하자. Git 브랜치 에서 다루는 이 방법들이 훨씬 낫다.


  • git checkout -b [branch-name] 
     브랜치를 만들면서 Checkout까지 한 번에 하려면 git checkout 명령에 `-b`라는 옵션을 추가한다.
 위 명령은 아래 명령을 한 줄로 줄인 것이다.
 $ git branch [branch-name]
 $ git checkout [branch-name]


  • ‘Fast forward’
 hotfix 브랜치가 가리키는 C4 커밋이 C2 커밋에 기반한 브랜치이기 때문에 브랜치 포인터는 Merge 과정 없이 그저 최신 커밋으로 이동한다. 이런 Merge 방식을 'Fast forward’라고 부른다. 다시 말해 A 브랜치에서 다른 B 브랜치를 Merge 할 때 B 브랜치가 A 브랜치 이후의 커밋을 가리키고 있으면 그저 A 브랜치가 B 브랜치와 동일한 커밋을 가리키도록 이동시킬 뿐이다.
 $ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast-forward
index.html | 2 ++
1 file changed, 2 insertions(+)


  • Github의 release
 오픈소스일 때 사람들한테 다운로드 주소알려줄 때
 저장소 주소를 그대로 걸어줄 수 없는데 zip파일을 이용해서 다운로드 가능.


  • git remote add [remote-name] [remote-address]
 오픈소스일 때 사람들한테 다운로드 주소알려줄 때
 저장소 주소를 그대로 걸어줄 수 없는데 zip파일을 이용해서 다운로드 가능.


  • git branch -d [branch-name]
  * 기호가 붙어 있지 않은 브랜치는 git branch -d 명령으로 삭제해도 되는 브랜치다. 이미 다른 브랜치와 Merge 했기 때문에 삭제해도 정보를 잃지 않는다.  
 Merge 하지 않은 브랜치를 강제로 삭제하려면 -D 옵션으로 삭제한다.


심화 명령어

  • git cherry-pick [commit명]
 체리는 commit을 의미합니다. 다른 브랜치의 commit 중 하나를 쏙 골라서 현재 브랜치에 넣는 겁니다. merge나 rebase는 다른 브랜치를 통째로 가져오는 데 비해, 다른 브랜치의 원하는 commit 한 개만 가져올 수 있습니다.  
commit명이 문제인데 commit명은 우리가 commit할 때 썼던 메시지가 아닙니다. 바로 Git 자체에서 붙여주는 고유값인데 이게 랜덤한 문자라서 외우기 힘듭니다. 그나마 git log하면 볼 수 있습니다.  
노란 부분의 79945~b16e8이 바로 commit의 이름입니다. 황당하죠? 저 긴 것을 다 써주면 됩니다... 저게 싫다면 밑에 git tag를 참조하세요. 아니면 GUI 도구를 사용하면 쉽게 cherry-pick할 수 있습니다.


  • credential cache
 이 리모트에 접근할 때마다 매번 사용자이름나 암호를 입력하지 않도록 “credential cache” 기능을 이용할 수 있다.  
이 기능을 활성화하면 Git은 몇 분 동안 입력한 사용자이름이나 암호를 저장해둔다.  
이 기능을 활성화하려면  
$ git config --global credential.helper cache  
명령을 실행하여 환경설정을 추가한다.


  • remotebranch merge
 새로 받은 브랜치의 내용을 Merge 하려면 git merge origin/serverfix 명령을 사용한다.  
Merge 하지 않고 리모트 트래킹 브랜치에서 시작하는 새 브랜치를 만들려면 아래와 같은 명령을 사용한다.  
$ git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'


  • 트래킹브랜치의 git pull
    (리모트트래킹브랜치 vs 트래킹브랜치)
 리모트 트래킹 브랜치를 로컬 브랜치로 Checkout 하면 자동으로 "트래킹(Tracking) 브랜치"가 만들어진다 (트래킹 하는 대상 브랜치를 "Upstream 브랜치" 라고 부른다).
트래킹 브랜치는 리모트 브랜치와 직접적인 연결고리가 있는 로컬 브랜치이다.
트래킹 브랜치에서 git pull 명령을 내리면 리모트 저장소로부터 데이터를 내려받아 연결된 리모트 브랜치와 자동으로 Merge 한다.


  • @{upstream}이나 @{u}`

    ``` 추적 브랜치를 설정했다면 추적 브랜치 이름을 @{upstream}이나 @{u}로 짧게 대체하여 사용할 수 있다.
    master 브랜치가 origin/master 브랜치를 추적하는 경우라면 git merge origin/master 명령과 git merge @{u} 명령을 똑같이 사용할 수 있다.

  • ```

  • git push origin –delete serverfix

 리모트 브랜치 삭제


  • $ git fetch –all; git branch -vv
 추적 브랜치가 현재 어떻게 설정되어 있는지 확인하려면 git branch 명령에 -vv 옵션을 더한다. 이 명령을 실행하면 로컬 브랜치 목록과 로컬 브랜치가 추적하고 있는 리모트 브랜치도 함께 보여준다. 게다가, 로컬 브랜치가 앞서가는지 뒤쳐지는지에 대한 내용도 보여준다.  
 현재 시점에서 진짜 최신 데이터로 추적 상황을 알아보려면 먼저 서버로부터 최신 데이터를 받아온 후에 추적 상황을 확인해야 한다. 아래처럼 두 명령을 이어서 사용하는 것이 적당하다 하겠다.  
https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%A6%AC%EB%AA%A8%ED%8A%B8-%EB%B8%8C%EB%9E%9C%EC%B9%98


  • rebase
$ git rebase master
=
1 rebase할 experiment branch가 master branch를 가르키게 한다.
2 $ git checkout master
3 $ git merge experiment


  • git fetch –all –prune
 서버쪽에서 지워진 branch를 local에도 적용시킴.
 * Terminal에서 branch를 삭제하지 않고 Github에서 GUI로 없애면 terminal에 바로 반영이 안되는 문제가 발생하는 것 같음.


  • git push [remote-name] [branch-name] [체크섬 name] __git checkout [branch-name] [체크섬 name]

    180116 | Git 7 ~ 3.5 45:15


  • git branch [branch-name] [실제존재하는 브랜치명] ``` git branch-name뒤에 실제 존재하는 브렌치명을 적어주면 현재 HEAD가 가르키는 곳이 아닌 해당 위치에 branch를 생성한다. 180116 | Git7 3~5 1:04:00

```

  • 업스트림 브랜치 remote tracking branch를 추적하는 브랜치를 ‘tracking branch’라고 하는데 (이 트래킹브랜치가 필요한 이유는 remote branch 자체가 수정이 안되기때문에 merge해서 새로운 브랜치를 만들어서 수정하려고 하는 것 같다. ex 실습 때 serverfix 처럼.) 그런데 이 tracking branch가 추적하는 remote tracking branch를 업스트림 브랜치라고 부를 수 있고 이때 git push와 git pull 만으로도 푸시와 풀이 가능하다.

이때의 push는 원래 ‘git push origin serverfix’처럼 해야하고 git pull은 원래 ‘git fetch origin’ ‘git merge origin/master

그리고 새로운 브랜치가 아니라 기존에 존재하는 브랜치로 추적하게하려면 $ git branch -u origin/serverfix 와 같이 하면 된다. 그러면 git pull / git push를 쓸 수 있다.

  • reset + 옵션 + HEAD~?

  1. reset의 옵션 3가지의 의미정리 –soft : 커밋만 날린다. –mixed : (기본값) 커밋과 add 둘 다 날린다. (unstaged하는것) –hard : 커밋과 add 뿐만 아니라 커밋된 수정파일 자체를 날려버린다. 흔적도 없이.

  2. 뒤에오는 HEAD는 reset의 기준을 말하며 HEAD~3에서 숫자 3은 HEAD가 세번 이동한 커밋을 삭제하라는 의미이다.



##03 Sites

https://git-scm.com/book/ko/v2 : Git에 대한 사용 매뉴얼을 한국어로 번역, 문제는 내용이 너무 많다는 것

https://en.wikipedia.org/wiki/Glob_(programming)

Gitignore glob에 기반으로 프로그래밍 언어 체계를 제공함. 정규표현식 : 특정한 규칙을 가진 문자여릐 집합을 표현하는데 사용하는 형식 언어이다. 긴 글에서 특정 문자를 가져올 때 쓰는 것. glob과 언어는 조금 다름. 파이썬 배울 때 한번 더 할 것. Glob 패턴은 정규표현식을 단순하게 만든것으로 생각ㄱ하면 된다. !는 무시하지 않는다는 의미




##04 Bookmark

  1. Git: 주요 명령어 정리
    http://noritersand.tistory.com/86

  2. Git tips and tricks https://about.gitlab.com/2016/12/08/git-tips-and-tricks/

  3. GIT이 무시하도록 하는 파일목록 작성하기 2.2 Git의 기초 - 수정하고 저장소에 저장하기

  4. GitHub 치트 시트
    https://github.com/tiimgreen/github-cheat-sheet/blob/master/README.ko.md



##05 Question

  1. git push origin master –force로 하면 서버에 있는 정보는 사?라짐? –force는 무슨 의미

  2. git push origin master vs
    git push origin/master vs

  3. Note git reset 명령은 매우 위험하다. –hard 옵션과 함께 사용하면 더욱 위험하다. 하지만 위에서 처럼 옵션 없이 사용하면 워킹 디렉토리의 파일은 건드리지 않는다. [https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EB%90%98%EB%8F%8C%EB%A6%AC%EA%B8%B0] (https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EB%90%98%EB%8F%8C%EB%A6%AC%EA%B8%B0)

  4. git reset –hard (HEAD) 라고 범위지정을 생략하면?

master <- commit 1 dev iss1 <- A iss2 <- B

  1. `fast-forward’
    ‘hotfix 브랜치가 가리키는 C4 커밋이 C2 커밋에 기반한 브랜치이기 때문에 브랜치 포인터는 Merge 과정 없이 그저 최신 커밋으로 이동한다. 이런 Merge 방식을 ‘Fast forward’라고 부른다. 다시 말해 A 브랜치에서 다른 B 브랜치를 Merge 할 때 B 브랜치가 A 브랜치 이후의 커밋을 가리키고 있으면 그저 A 브랜치가 B 브랜치와 동일한 커밋을 가리키도록 이동시킬 뿐이다.

Q 기존 사항을 변경해도 충돌 x?

  • 맞다. 심지어 A내용을 다 날려도 fast-forward 할 수 있다.
  1. Figure 23. master와 별개로 진행하는 iss53 브랜치 위에서 작업한 hotfix가 iss53 브랜치에 영향을 끼치지 않는다는 점을 이해하는 것이 중요하다. git merge master 명령으로 master 브랜치를 iss53 브랜치에 Merge 하면 iss53 브랜치에 hotfix가 적용된다. 아니면 iss53 브랜치가 master에 Merge 할 수 있는 수준이 될 때까지 기다렸다가 Merge 하면 hotfix와 iss53 브랜치가 합쳐진다.
  • 상관없다. 그리고 merge 후에도 브랜치는 남아있다. 그때 master 브랜치를 삭제하면 그냥 iss53만 남아서 master역할을 대체하면 된다.

https://git-scm.com/book/ko/v2/Git-브랜치-브랜치와-Merge-의-기초

Q1. master로 merge하는 것과 다른 가지로 merge하는 것의 차이.

Q2. 다른가지에서 merge하면 merge 후의 branch는 iss53 branch가 master역할을 하는 branch로 남는 것? 그냥 mv로 이름만 master로 바꾸고 쓰는것?

안없어진다

Q3. 만약에 위에서 iss53이 남으면 두번재줄로만 그래프가 그려지는지?

무조건 첫번째줄로간다.

  1. git log –oneline –all –graph에서 선 색깔 의미

없는듯하다. 있다해도 중요치 않다.

  1. git branch —track

  2. git reset HEAD git reset –

체크섬이나 ‘HEAD~숫자’를 사용해서 헤드가 지난 커밋을 가리키게 할 수 있다. vs

HEAD 이해 완료

上一篇 02 HTML/CSS

下一篇 03 Python Study

Comments

Content