728x90

참고 URL : gmlwjd9405.github.io/2018/05/25/git-add-cancle.html

 

git으로 commit 을 하는데 잘못 commit 하였다면 취소할 수 있습니다.

각 단계별로 취소하는 방법이 있습니다.

 

1. git add를 취소할 수 있다.
2. git commit을 취소할 수 있다.
3. git push를 취소할 수 있다.
4. untracked 파일을 삭제할 수 있다.

 

intelij 에서 git commit을 하는 경우 Rollback..으로 할 수 있으나 Terminal 을 열어서 하는게 더 나을 수도 있습니다.

 


git add 취소하기 (파일 상태를 Unstage로 변경하기)

 

$ git reset HEAD

 

아래와 같이 실수로 git add * 명령을 사용하여 모든 파일을 Staging Area에 넣는 경우가 발생하였다면 

$ git add *
// 파일들의 상태를 확인한다.
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
  renamed:    README.md -> README
  modified:   CONTRIBUTING.md

 

 

뒤에 파일명이 없으면 add한 파일 전체를 취소할 수 있습니다.

$ git reset HEAD
// 파일들의 상태를 확인한다.

$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
........

 

git add 한 파일중에서 README 파일을 Unstage로 변경할 수 있습니다.

$ git reset HEAD 파일명

$ git reset HEAD README
Unstaged changes after reset:
M	README


-- 파일들의 상태를 확인합니다.

$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
  renamed:    README.md -> README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
  modified:   README

 


git commit 취소하기  (git reset HEAD^)

 

commit이 완료된 경우 취소할 수 있습니다.
어떤 파일을 빼먹고 commit한 경우나 너무 일찍 commit 한 경우 등에서

git reset HEAD^ 명령어를 통해 git commit을 취소할 수 있습니다.

-- commit 목록 확인을 확인합니다.
$ git log



-- 1. commit을 취소하고 해당 파일들은 staged 상태로 유지하고, 워킹 디렉터리에 보존합니다.
$ git reset --soft HEAD^



-- 2. commit을 취소하고 해당 파일들은 unstaged 상태로 변경하고, 워킹 디렉터리에 보존합니다.
$ git reset --mixed HEAD^ // 기본 옵션
$ git reset HEAD^         // 위와 동일
$ git reset HEAD~2        // 마지막 2개의 commit을 취소



-- 3. commit을 취소하고 해당 파일들은 unstaged 상태로 변경하고, 워킹 디렉터리에서도 삭제합니다.
$ git reset --hard HEAD^

 

(실제 사용한 예)

$ git reset HEAD^
리셋 뒤에 스테이징하지 않은 변경 사항:
M       ...........
M       .....


$

 

 

git reset 명령은 아래의 옵션과 관련해서 주의하여 사용해야 합니다.

 

reset 옵션

–soft : index 보존(add한 상태, staged 상태), 워킹 디렉터리의 파일 보존. 즉 모두 보존.
–mixed : index 취소(add하기 전 상태, unstaged 상태), 워킹 디렉터리의 파일 보존 (기본 옵션)
–hard : index 취소(add하기 전 상태, unstaged 상태), 워킹 디렉터리의 파일 삭제. 즉 모두 취소.

 

 

만약 워킹 디렉터리를 원격 저장소의 마지막 commit 상태로 되돌리고 싶으면, 아래의 명령어를 사용해야 합니다.

단, 이 명령을 사용하면 원격 저장소에 있는 마지막 commit 이후의 워킹 디렉터리와 add했던 파일들이 모두 사라지므로 주의해야 합니다.

-- 워킹 디렉터리를 원격 저장소의 마지막 commit 상태로 되돌린다.

$ git reset --hard HEAD

 


commit message 변경하기 (git commit -ament "메세지")

commit message를 잘못 적은 경우, git commit –amend 명령어를 통해 git commit message를 변경할 수 있습니다.

$ git commit --amend

 


git push 취소하기

 

이 명령을 사용하는 것은 자신의 local의 내용을 remote에 강제로 덮어쓰기를 하는 것이기 때문에 주의해야 합니다.

왜냐하면 되돌아간 commit 이후의 모든 commit 정보가 사라지기 때문에 주의를 해야 하는 것입니다.

특히, 협업 프로젝트에서는 동기화 문제가 발생할 수 있으므로 팀원과 꼭 상의하셔야 합니다.

 

원격 저장소에 push하여 저장되어 있는 경우는 아래와 같은 단계로 취소할 수 있습니다.

 

1단계 : 원하는 시점으로 워킹 디렉터리를 되돌립니다.

2단계 : 되돌려진 상태에서 다시 commit을 합니다.

3단계 : 원격 저장소에 강제로 push 합니다.

-- 1단계 : 가장 최근의 commit을 취소합니다. (기본 옵션: --mixed)
$ git reset HEAD^

-- 1단계 : 원하는 시점으로 워킹 디렉터리가 되었는지 확인합니다.
-- 1단계 : Reflog(브랜치와 HEAD가 지난 몇 달 동안에 가리켰었던 커밋) 목록 확인

$ git reflog 
또는 
$ git log -g


-- 1단계 : 원하는 시점으로 워킹 디렉터리를 되돌립니다.
$ git reset HEAD@{number} 
또는 
$ git reset [commit id]

-- 2단계 : 되돌려진 상태에서 다시 commit을 합니다.
$ git commit -m "Write commit messages"


-- 2단계 : 원격 저장소에 강제로 push 합니다.
$ git push origin [branch name] -f
또는
$ git push origin +[branch name]

-- 예를 들어 master branch를 원격 저장소(origin)에 강제로 push하겠다고 한다면
$ git push origin +master

 


추적중이지 않은 파일 삭제하기 : git clean

 

git clean 명령은 추적 중이지 않은 파일만 지우는 명령입니다.

하지만 .gitignore 에 명시하여 무시되는 파일은 지우지 않지 않습니다.

$ git clean -f         // 디렉터리를 제외한 파일들만 삭제
$ git clean -f -d      // 디렉터리까지 삭제
$ git clean -f -d -x   // 무시된 파일까지 삭제

 

-d 옵션  : 디렉터리까지 지우는 것
-x 옵션  : 무시된 파일(.DS_Store나 .gitignore에 등록한 확장자 파일들)까지 모두 지우는 것
     Ex) .o 파일 같은 빌드 파일까지도 지울 수 있다.
-n 옵션  : 가상으로 실행해보고 어떤 파일들이 지워질지 알려주는 것

728x90

하나의 예시일뿐이며 해당 내용에 대한 작업 플로우는 아래 참고URL이 있으니 확인해 보시길 바랍니다.

Git을 사용하기 위한 세팅을 마친 "A책임"와 "B선임"는 서로 나뉘어서 코딩을 하기로 했습니다.

1. 20XX년 04월 01일, "A책임"과 "B선임"이 각각 브랜치를 땁니다.

"A책임"는 "main 페이지"를 만들기 위해 ‘feature/A-source’이란 이름으로, "B선임"는 "register 페이지"를 만들기 위해 ‘feature/B-source’ 이란 이름으로 "orgin/prod" 브랜치의 최신 커밋으로부터 새로운 브랜치를 만들었습니다.

   * 브랜치 앞에 ‘feature/‘처럼 슬래시로 구분된 이름을 달아주면 이 구분별로 브랜치를 묶어볼 수 있는 장점이 있습니다.


2. "A책임"와 "B선임"은 각자 브랜치에서 코딩을 합니다.

3. 20XX년 04월 05일 - A책임 : ‘feature/A-source’ 1차 작업 완료, "Pull Request"

   시간이 흘러 "A책임"이 main 페이지를 다 만들어 "orgin/dev" 에 ‘feature/A-source’ 브랜치를 merge 할려고 합니다.
   하지만 "예고 없이" 바로 합치기 보다는 "B선임"에게 리뷰를 먼저 받고 합치고 싶습니다.
   * 그러기 위해서 사용하는 것이 "Pull Request" 입니다. (git의 기능이 아니고 github에서 제공하는 기능입니다.)

 

4. 20XX년 04월 05일 - A책임 : "Pull Request" 버튼을 눌러 ‘feature/A-source’에서 "orgin/dev" 브랜치로 Pull Request(땡김 요청)

   "Github저장소"에 있는 "Pull Request" 버튼을 눌러 ‘feature/A-source’에서 "orgin/dev" 브랜치로 Pull Request(땡김 요청)를 보냅니다.
   * 즉, "feature/A-source"에 소스를 수정해놨으니 "orgin/dev" 브랜치에서 땡겨가라고 요청하는 것입니다.

 

5. 20XX년 04월 05일 - 배포담당자 : "Pull Requests"로 요청한 내용 확인 후 "Merge pull request"로 "orgin/dev"에 merge

그럼 GitHub저장소의 ‘Pull requests’섹션에서 "A책임"이 보낸 "Pull Request" 를 확인할 수 있습니다.
Files changed를 보고 잘 만들었는지 여부를 확인하고, 잘 되었다면 ‘Merge pull request’를 눌러 "A책임"의 커밋들을 "orgin/dev" 브랜치에 합칩니다. 원하는게 아니라고 생각되면 거부할 수도 있습니다.

 

6. 20XX년 04월 06일 - B선임 : 작업마치고 "Pull Request" 할려니 Merge Conflicts (소스 충돌) 우려 발생

그 와중에 "B선임"도 "register 페이지" 작업을 마치고 "orgin/dev" 브랜치에 "Pull Request"를 보내려 보니 "A책임"의 새로운 코드가 추가(20XX년 04월 05일)되어 "이책임"이 처음에 땄던 "orgin/dev" 커밋(20XX년 04월 01일)와 상태가 달라졌습니다.

   * "B선임"이 만든 소스는 'orgin/dev'에서 2020년 04월 01일에 브랜치를 땄기 때문에 옛날 버전이 되었습니다.
   * "A책임"이 2020년 04월 05일 'orgin/dev'에 소스를 추가하였기 때문입니다.

 

7. 20XX년 04월 06일 - B선임 : 'orgin/dev'의 소스를 자신의 "feature/B-source" 에 merge

"B선임"은 ‘선-merge 후-pull request’를 보냈습니다.
자신의 local 'feature/B-source'에 'orgin/dev'의 최신 커밋을 마우스 오른쪽 버튼을 눌러 Merge하였습니다.
그랬더니 Merge Conflicts(Merge 충돌) 이 났습니다.

 

8. 2020년 04월 06일 - B선임 : Merge Conflicts(Merge 충돌)해결

   "A책임"와 "B선임" 둘 다 같은 소스를 고치다 보니 충돌이 났습니다.
   코드를 보니 "B선임"의 코드가 맞다고 합니다.
   수동으로 "A책임"의 코드를 지우고 "B선임"의 코드를 남겨 commit+push 합니다.
   * marge compare 를 통해서 해당 부분을 체크해서 merge 처리 합니다.

 

9. 2020년 04월 06일 - 이제 "B선임"도 "orgin/dev"로 "Pull request"를 보내고 배포관리자는 merge합니다.

"A책임"이 확인하고 "merge"하니 오류가 없습니다.
"이책임"의 "feature/B-source"에는 "orgin/dev"의 코드도 잘 섞여있는 버전이 들어가 있기 때문입니다.

 

10. 이제 "orgin/dev"에 "A책임"의 "main 페이지" 와 "B책임"의 ‘"register 페이지"가 모두 반영되었습니다.

 

11. 배포를 위해 "orgin/dev"에서 "orgin/master" 브랜치로 "pull request"를 보내고 "배포관리자"는 merge 합니다.

 

참조 : 
https://medium.com/@psychet_learn/git-%EC%82%AC%EC%9A%A9%EB%B2%95-3%EC%9E%A5-github-%EC%9D%B4%EC%9A%A9%ED%95%98%EA%B8%B0-f53e765844e3
참조 : 
https://milooy.wordpress.com/2017/06/21/working-together-with-github-tutorial/

 

+ Recent posts