[부트캠프] TIL - Git revert & reset, 쓰레드(Daemon,Priority,ThreadGroup)

금일의 코드카타 풀이 진행간 1시간 동안 Java 문제만 간신히 풀어내어

일단은 제출하고자 커밋하고 원격 저장소에 Push까지 진행을 하였다.

 

하지만 추후의 일정에 여유가 생겨 풀지못한 sql 문제를 시도한 뒤 풀게되었고.

이를 커밋하고자 하니 아까 push했던 commit을 한번 취소한 뒤 sql과 함께 push를 해보는 경험을 

해보려고한다.

 

이미 0731 codeKata가 main에 push된 상태.

 

일단, 생소하지만 Git 저장소에 commit한 내용을 되돌리기 위해서는 reset과 revert에 대해 알 필요가 있습니다.

 

reset : HEAD의 위치를 바꿔준다

revert : commit의 내용을 되돌리는 commit을 새로 만듭니다.

 

간단하게 역할에 대해 적어보았지만, 더욱 이해하기 쉽게 말하자면 

reset은 HEAD의 위치를 바꿔주기 때문에 아직 원격 저장소에 push 이전, 로컬에서 자신의 변경사항만을 되돌릴 때 사용한다 라고 이해하면 되고.

revert는 commit을 되돌리는데 이미 원격 저장소에 push를 한 상태에서 이전 commit을 취소하는 새로운 commit을 만드는것이다, 왜 이전 commit을 취소하는 새로운 commit이냐?? -> main에 push된 commit을 마음대로 취소하고 그러면 협업 과정에서 커밋이력이 꼬일 수 있기 때문에, 협업 과정에서는 revert를 사용하여 commit을 취소하는 새로운 commit을 만듬으로써 커밋 이력이 꼬이지 않게 해주는것.

 

 

코드카타는 나 혼자 로컬에서 작성하며 원격 레포지토리인 메인 브랜치 역시도 혼자 사용하는것이기 때문에 

reset을 사용하면 되지만, 그냥 revert도 같이 연습해 보도록 하겠습니다.

 

git reset을 사용한 상태

 

git reset [commit id]

바로 이전 커밋으로 reset을 사용한 모습입니다, Head가 이전 커밋으로 이동한 상태를 터미널에서 볼 수 있으며

좌측에 java codeKata가 언스테이징 상태 즉 (오늘 커밋하기 전) 상태로 돌아간 것을 볼 수 있습니다.

커밋하고 푸시했던 java 파일이 언스테이징상태로 돌아왔다.

 

다만! 위에 "origin/main에서 1개 커밋 풀" 이 갑자기 생겨났다는 것에 주목해야합니다.

 

원인을 찾기위해 원격 레포지토리에 가봅니다.

원격 레포지토리는 reset에 영향을받지않았다.

 

원격 레포지토리는 0731 커밋이 그대로 남아있는 모습을 볼 수 있었습니다, 그렇다면 저 메시지의 의미는

니 로컬 레포지토리의 커밋이 원격 레포지토리의 커밋보다 1개 뒤쳐져있다, Pull하겠느냐?(0731커밋을 Pull하겠느냐?) 죠

 

다시 원상태로 돌리기 위해서는 git pull을 하면 됩니다. 

하지만 이상태로 push를 하면 에러가 발생합니다.

git reset은 과거로 돌아가면서 그 사이에있던 커밋들을 옵션에 따라 삭제시켜버립니다 ex) --hard

github 입장에서는 갑자기 과거의 내가 나타나서 나를 지워버리겠다고 하니 이상할겁니다.물론 push를 할 수도 있습니다, git push --force 를 하면 과거의 버전으로 원격 레포지토리를 덮어씌워버립니다.혼자라면 괜찮지만, 누군가와 협업을 하며 원격 레포지토리를 공유하는 상황이라면? 절대 해서는 안되는 행동입니다.

 

 

revert를 해봅시다.

Revert를 진행하고 마무리한 상태

revert를 하게되면 돌아간 시점 이후의 커밋들이 삭제되는것이 아니라, 새로운 커밋이 생깁니다.

새로운 커밋 내용은 Revert "~~"로  어느 커밋으로 돌아갔다는 내역을 남겨주게되는데

이렇게 되면 원격 레포지토리에 push를 하게 되더라도 협업자의 커밋 로그가 꼬이지 않게 해줍니다.

(내용은 되돌아갔지만, 커밋 로그는 쭉 이어져있기때문에)

 

연습을 진행하면서 잘못된 실행도 있고 오류도 있어서 git reset --hard ~~ 를 진행하기도 했지만, reset과 revert 과정에

한번씩 연습을 해볼 수 있는 경험이었습니다.

 

---

 

프로그램, 프로세스, 쓰레드 간의 관계 및 동작방식에 대해 정리했다면 오늘은

Daemon 쓰레드, 쓰레드의 Priority, ThreadGroup 에 대해 마무리로 정리합니다.

 

1. Daemon 쓰레드

백그라운드에서 동작하며 낮은 우선순위를 가지고 일반적인 서비스 스레드의 보조 역할을 담당합니다.

백그라운드에서 동작하고 우선순위도 낮기때문에 얘가 만약 작업중인데 main 쓰레드에서 프록램의 실행이 끝나 

프로그램을 종료해야한다? 라고 하면 Daemon쓰레드의 작업이 남아있더라도 무시하고 프로그램이 중단됩니다.

예시로 가비지컬렉터(GC)가 있습니다.

 

2.쓰레드의 Priority

쓰레드간에도 우선순위를 설정할 수 있습니다, 다만 이 우선순위란게 높은애를 무조건 먼저해야한다, 높은애가 무조건 먼저 작업이 끝나야한다의 개념이 아니라 CPU의 작업을 더많이, 더 자주 받을 수 있다는 개념입니다,

그렇기때문에 우선순위가 높다고해서 무조건 우선순위가 낮은 쓰레드보다 작업이 먼저 끝나고 이런게 아닌 

더 많은 자원을 할당받을 수 있기 때문에 빠르게 처리될 확률이 높다 정도가 이해하기 좋습니다.

 

3. ThreadGroup

쓰레드 들은 자동적으로 어떤 그룹에 포함이됩니다. 

JVM 안에서 System 그룹이 자동으로 생성되고 모든 쓰레드들은 System 그룹에 자동적으로 포함됩니다.

그리고 마찬가지로 JVM은 Main 메소드를 실행시키며 main 쓰레드를 실행시키는데 

개발자가 main 함수에서 생성한 쓰레드들은 기본적으로 main쓰레드 하위에 존재하는것이기 때문에

별도로 쓰레드 생성시 그룹을 설정하지 않는다면 main 그룹에 포함되게됩니다.