새소식

git,github

git 활용

  • -

- git reset 은 Head가 가리키는 브랜치가 가리키는 커밋을 변경함

- git reset --hard 커밋id1: working directory의 내용이 커밋id1 때까지로 변경됨

- history를 보면 커밋id1 때까지의 커밋이 보이고, 파일도 그 커밋에 알맞게 변경됨

- But, hard 작업을 해도 커밋 자체가 삭제되지는 않음, reset 커밋id2(id1 이후의 커밋) 해도 정상적으로 작동

(최신커밋으로 되돌아갈 때는 그 최신커밋의 id를 알고 있어야 함)

 

>> Head가 가리키는 브랜치가 새로운 커밋을 가리키게 됨

 

1. reflog

- 최신 커밋의 id를 모를 때는 git reflog를 사용해서 확인 가능

맨 위의 줄은 reset 동작을 통해 커밋id  abad를 head가 가리킨다는 뜻

- git reset --hard abad 와 git reset --hard HEAD@{1} 은 같은 의미

 

 

2. --graph

git log 를 이용하면 현재 설정된 브랜치에 대한 커밋들을 볼 수 있음

다른 브랜치 정보까지 보기 위해선 --all 옵션 이용

ex) git log --pretty=oneline --all

 

--graph 옵션: 커밋 히스토리가 각 브랜치와의 관계가 잘 드러나도록 그래프 형식으로 출력됨

* 하나가 커밋 하나를 칭함, 갈라진 모습은 여러 브랜치로 코드 흐름이 갈라진 것, 합쳐진 부분은 merge 커밋

 

3. rebase

' git rebase 브랜치명': merge 와 비슷한 용도 충돌이 일어나면 내용 수정 후 git add . 하고

git rebase --continue 사용(충돌이 나서 제대로 진행되지 않은 rebase를 다시 진행하라는 뜻)

 

프리미엄 브랜치가 add get_Median function commit을 거쳐온 것처럼 커밋 히스토리의 구조 자체가 변경됨

 

 

4. stash

error: Your local changes to the following files would be overwritten by checkout:

>>

다른 브랜치로 넘어가면 방금까지 작업한 내용이 날라갈 수 있다.

 

git stash: 어떤 브랜치에서 하던 작업을 아직 커밋하지 않았는데 다른 브랜치로 가야하는 상황에서 작업중이던 내용을 잠깐 저장하고 싶을 때 사용

working directory에서 작업하던 내용은 깃이 따로 보관(스택에 보관(후입선출 LIFO))

git stash list: 최근 커밋 이후로 작업했던 내용들은 모두 스택에 옮겨지고 working directory 내부는 다시 최근 커밋의 상태로 초기화  

스택에 보관된 내용 리스트를 알 수 있음

git stash apply: 최근에 저장된 작업 내용이 적용됨

 

stash 이용할 때 어떤 작업을 이용할지 정확하게 지정해야 할 때는 

git stash apply stash@{n} 사용(n은 0 이상의 정수) 

 

>> 잘못된 브랜치에서 작업하는 실수를 했을 땐 git stash에 작업 내용을 저장하고 올바른 브랜치로 가서

git stash apply 를 적용

(적용한 작업내용은 지워주는게 좋음, git stash drop stashID 이용)

 

+ 작업 내용을 적용하면서 동시에 스택에서 제거도 해주는 커맨드: git stash pop [작업 내용의 아이디]

1. [작업 내용의 아이디]를 인자로 주면, 특정 작업 내용을 적용하면서 스택에서 제거

2. [작업 내용의 아이디]를 인자로 주지 않으면, 가장 최근에 한 작업 내용을 적용하면서 스택에서 제거

 

스택에 저장된 작업 내용을 working directory에 적용할 때

그 작업 내용을 나중에 또 쓸 필요가 있다면 git stash apply를, 나중에 또 쓸 필요가 없다면 git stash pop을 사용 

(일반적으로 후자 사용)

 

 

5. 필요한 커밋의 내용을 가져오고 싶을 때

 

A. git log --pretty=oneline --all --graph 통해 필요한 커밋의 id 알기

B. git cherry-pick [가져오고 싶은 작업내용이 담긴 커밋id]: 자신이 원하는 작업이 들어있는 커밋들만 가져와서 현재 브랜치에 추가

 

6. 여러 커밋을 하나의 커밋으로 만들기 

현재 working directory를 건드리지 않는 mixed나 soft 사용

- 위 작업을 하면 여전히 working directory는 최신 상태

- git add. 후 commit

- 그 이전에는 여러개 있었던 커밋 파일들이 mixed/soft reset 후 다시 commit하는 과정을 통해 하나로 줄어들게됨

 

+ 그런데 working directory 안에 있음에도 불구하고 Git에 의해 그 존재 자체가 무시되는 파일들이 있음

gitignore 파일: working directory 내에 존재하는 파일들 중에서 마치 존재하지 않는 것처럼 Git이 인식해야할 파일들의 목록이 적힌 파일

- GitHub에서 레포지토리를 만들 때 화면 하단을 보면 Add .gitignore: None 이라는 설정 탭이 있음, 이 말은 .gitignore 파일을 만들지 않겠다는 뜻

- 이 탭을 클릭해보면, 알파벳 A부터 순서대로 그 알파벳으로 시작하는 단어들이 등장 > 이 단어들은 모두 프로그램이 실행되는 플랫폼이나 프로그래밍 언어들을 뜻함

- 이런 것들 중 하나를 선택하면 그 플랫폼에서 실행될 프로그램을 만들거나, 해당 프로그래밍 언어로 코드를 작성할 때 (보통 자동으로) 생성되는 파일들 중에서 굳이 Git에 의해 버전 관리될 필요가 없는, 불필요한 파일들의 이름이 정리된 .gitignore 파일을 자동으로 생성됨

 

 

 

Add .gore: None

이라는 설정 탭이 보입

 

 

Contents

포스팅 주소를 복사했습니다

이 글이 도움이 되었다면 공감 부탁드립니다.