4주차 내일배움캠프 개발일지

이번주는 github와 sourcetree를 사용하는데
익숙치 못했던 저를 떠올리며

회고하는 방식으로

4주차 개발일지를 작성해보려합니다.

 

우선 제가 어려움을 겪었던 부분은 바로

fork와 clone의 차이

그리고 이런 부분을 이해하지 못하고

다른 사람의 repo에 원격으로 바로 내용을

수정하려고 했던 부분

이와 더불어 issue나 pr

sourcetree 내 기능 사용 등을

종합적으로 복습했답니다.

 

그 전에 sourcetree에서 충돌 병합 메시지가 나왔을 때

해결하는 법에 대하여 정리해볼까 합니다.

 

 

시작해볼까요!!

 

first를 25로 설정한 것은 나의 큰 그림이었다.

파이참의 파일을 sourcetree 내에 git-init 방법으로 초기화를 하여 등록하게 되면

파이참의 파일을 수정할 때 수정내용을 sourcetree 내에서

커밋, 푸시 등을 사용할 수 있게 된다.

 

각기 다른 브랜치에서 같은 파일을 수정하게 될 때 생기는 병합 충돌

 

이렇게 병합 충돌 메시지가 나오게 되면 그 내용을 읽어보자.

충돌된 파일을 선택 후 충돌 해결 밑의 메뉴를 사용하여 해결할 수 있다고 한다.

 

충돌된 내역을 파이참에서 자동으로 나오게 한다.

 

이제 이 부분을 보고 어느 내용을 커밋할 것인지 먼저 결정한다.

새로운 내용을 적어야 한다면 먼저 충돌된 파일을 해결하고

그 다음에 새로운 내용을 적어 커밋을 진행하도록 한다.

 

그럼 이제 pr은 어떻게 하는지 간단히 적어보려 한다.

 

 

local에서 만든 브랜치 수정 내용을 local main 브랜치로 pr

 

오류 확인이 어려워 업무분장 재조정을 요청한다는 내용을 pull request 한다.(pr)

creat pull request를 눌러 완료한다.

pr 요청을 받은 관리자(지금은 내 저장소이기 때문에 나)는 요청을 받을 것인지

무를 것인지 결정할 수 있다.

 

merge를 통해 pr을 받아들일 수 있다

 

자, 그럼 여기서 fork와 clone의 차이를 말해보려 한다.

fork는 내 저장소가 아닌 다른 사람의 저장소를 그대로 나의 저장소로

가져오는 것을 말한다.

따라서 fork를 통해 가져온 저장소와 original 저장소가 연결이 되어 있는 것이다.

그럼 나는 sourcetree를 통해 fork한 나의 저장소를 clone하는 것이다.

soucetree에 clone된 저장소와 fork를 통해 가져온 저장소가 연결이 되어 있는 것이다.

clone은 code https 주소를 복사하여 sourcetree에 붙여넣을 수 있다.

 

이런 사실을 모르고 clone한 저장소와 다른 사람의 저장소가 바로 연결되어 있는 줄 알았다.

왜 내용이 왜 내용이 바로 반영되지 않는 것인지 계속 고민한 것이다.

 

그래서 이번 프로젝트의 경우 나의 저장소를 따로 만들지 않고 github 내 contributor 등록을 하여

팀장님의 repo를 clone 한 이후

파이참 내 깃허브 연동을 통해서 pull commit push만을 사용했다.

팀 프로젝트 인원이 적어서

이런 방식이 이번에는 조금 더 효율적이었다고 생각한다.

 

따로 issue를 통해 담당을 정하고 어느 부분을 진행하는지 공유하기보단

실시간으로 소통하며 문제점을 잡아갔고

.md(markdown)을 이용하여 전체적인 업무내용만 정하고 맞춰어 갔다.

 

그러나 이러한 방식은 병합충돌이 잘 일어날 수 있다는 단점이 있다.

그래서 앞으로는 개발자로서 업무를 진행하기 위해

github에 대해 좀 더 이해할 필요가 있다고 생각되어

다시 회고 겸 정리를 하는 중인 것이다.

 

마지막으로 sourcetree 내 기능을 익힐 겸

amend, revert, reset, stash 를 공부해봤다.

 

amend의 경우 간단한데 아래와 같이 커밋을 잘못했을 경우

다시 정정한다는 뜻이다.

모르고 하나만 커밋한 상황

이렇게 해주면 끝!

마지막 커밋 정정을 누르고 나머지 파일도 같이 커밋을 해주면

최신 커밋을 수정하는 것이 가능하다.

단, 커밋을 수정하고 없애는 것은 나의 브랜치 내에서만 해야한다.

다른 사람들이 같이 사용하는 곳에서는 내가 실수로 커밋한 이후

다른 사람들이 무언가 작업을 하게 되면

다음의 커밋을 수정할 때 파일이 꼬일 수 있기 때문에 신중해야한다.

(브랜치의 소중함을 여기서 느낄 수 있다는 것!)

 

앞서 설명한 amend는 push 이전에 사용하는 방법이고

push까지 이미 마친 상황이라면

강제 push 기능을 활성화해주어야 한다.

강제푸시 기능 활성화 방법

강제푸시를 활성화 하면 amend를 하기위해 커밋 옵션에서 마지막 커밋 수정을 클릭합니다.

이후 강제 푸시 옵션을 선택하고 푸시하면 다시 내용이 변경된 것을 확인할 수 있습니다.

반드시 나의 브랜치 내에서만 강제푸시 기능을 사용하도록 한다.

어쨌든 amend 기능 뿐만 아니라 revert, reset 역시 마찬가지이다.

 

앞서 배운 amend는 가장 최신의 커밋만 되돌릴 수 있다.

또한 어떤 내용을 되돌렸는지도 알 수 없다.

어떤 내용을 되돌렸는지 협업을 하는 경우엔 알려줄 필요가 있다.

이를 revert를 통해 가능하게 한다.

revert는 최신 커밋과 과거 작업한 커밋도 되돌리는 것이 가능하다.

 

되돌리고 싶은 커밋을 선택 후 마우스 우측 버튼을 클릭한다.

revert 사용을 위해 커밋 되돌리기 클릭

커밋 되돌리기를 클릭하면 이전 커밋의 내용을 수정하는 새로운 커밋이 만들어진다.

 

revert의 경우 주의할 점이 있는데

branch가 갈라져서 나온 커밋을

branch가 갈라지기 전 다른 branch 커밋으로

revert하기 위해선 추가적인 설정이 필요로 한다.

 

또한 revert 되어 만들어진 커밋을 다시 revert 할 수는 있다.

그러나 revert 후에 그 내용이 없어졌다면 다시 revert 할 수는 없다.

 

그리고 reset의 경우 커밋했던 작업내용을 없앤다고 생각하면 되겠다.

soft, mixed, hard 방식으로 나눌 수 있다.

soft는 커밋을 되돌리고 변경된 파일 작업 내용을 보존하여 변경사항으로 보여준다.

단 변경사항을 add 되어 있지 않다.

mixed는 커밋을 되돌이고 변경된 파일 작업 내용을 보존하여 변경사항으로 보여준다.

변경사항을 add 되어 있다.

hard는 히스토리를 남기지 않고 없애버린다.

웬만하면 공부할 때 사용하지 않는 것이 바람직하다고 생각한다.

 

이 커밋까지 현재 브랜치를 초기화를 클릭하여 reset!

 

stash는 커밋을 하기 애매한 상황에서 활용하면 좋다.

예를 들면 기능 관련 hotfix(급히 수정해야할 상황)가 있어서

지금까지 작업하던 브랜치를 떠나 다른 브랜치에서 작업을 해야하는 상황이 있을 것이다.

커밋을 하기에는 아직 부족하다면 stash를 통해 임시저장을 할 수 있다.

 

위 사진에 볼 수 있듯이 상단 탭에서 스태시를 클릭하면

현재까지의 작업 내용이 좌측 메뉴 하단 스태시에 저장이 된다.

나중에 hotfix가 끝나면 좌측 메뉴 하단 스태시를 클릭하여 적용을 눌러주자.

 

적용을 통해 다시 작업 내용을 불러왔다면 스태시 내용을 삭제해주는 것이 바람직하다.

 

한편 작업 내용을 수정할 때 상단 메뉴의 탐색기를 사용하는 것이 좋다.

해당 파일에서 직접 수정을 하면 수정내용이 잘 적용되지 않을 수 있기 때문이다.

 

이렇게 git과 sourcetree 내용을 정리해보았다.

1달 정도 개발 수업을 들으며 공부를 진행했는데

개발에 대해 아무것도 모르는 상황에서

팀 프로젝트를 통해 간단한 웹페이지를 구현할 정도로 성장할 수 있었다는 사실이

굉장히 뿌듯하다.

 

남은 3개월 동안 얼마나 더 성장할 수 있을지 기대가 되고

늦었지만 2022년 새해 복 많이 받으시길 바란다.