깃헙 특강 by 이고잉
예비군 때문에 듣지 못한 것을 뒤늦게라도 듣는 중. 생각보다 다시보기가 정말 불편한 게, 채팅과 사람들의 얼굴을 전혀 보이지 않고 그저 공유된 화면만 보인다. 그래서 채팅으로 소통하고 있는 것에 대해서는 추측하면서 들어야 한다. 이건 좀 건의해볼 만한 사항인 듯. 줌 자체의 녹화기능이 유용하지 않다는 것이다.
.git 속 info 파일에 exclude에서 이근호와 비슷하게 무시할 파일을 지정할 수 있다.
협업 중에 모두가 공유해야 하는 서식이 있다면 확장자를 .template라 하여 형식 파일로 저장하라. 국룰!
gitignore.io에서 편하게 사용하는 기술에 맞는 이근호 파일을 만들 수 있다! 대체로 이근호하는 것들
3way merge 기능이라 하면 3자 대면을 해주는 것을 말한다. 충돌이 나는 두 버전과 둘의 공통 조상에 해당하는 버전.
충돌이 해결되면 add를 해준다.
원격 저장소를 그대로 내려받을 때는 clone. 이미 있는 로컬 깃과 원격 저장소를 연결할 때는 remote.
원격저장소와 연결한 이후 로컬의 어떤 브랜치를 원격과 페어링할 것인지 설정해줘야만 한다. 그러나 그게 꼭 하나일 필요는 없다. master와 exp 두 브랜치 모두 origin으로 연결되어 있는 모습.
그에 맞춰 원격 저장소에서도 브랜치가 분화되었다.
폴더 명을 지정해서 clone이 가능하다. 만약 이미 폴더를 만들고 clone하는 상황이라면 단순히 .을 찍어주면 된다.
같은 원격 저장소를 둔 두 로컬. 한쪽이 먼저 푸쉬를 했다면 다른 쪽은 바로 푸쉬할 수 없다. fetch를해서 브랜치를 가져와 직접 비교하던가, 바로 pull을 시켜 원격과 로컬의 버전 차이를 메꿔줘야 한다.
여태 같은 로컬에서 브랜치를 병합할 때 일어나는 충돌에 대해 공부했다. 그렇다면 다른 로컬에서 충돌이 일어날 수도 있지 않을까?
이건 원격과 로컬이 달라서 생기는 문제다. 엄밀히 말해 conflict와 조금 다름.
fetch를 사용해서 두 버전이 있는 상태에서 머지하는 상황. 이렇게 fetch를 해서 마치 로컬 내에서 충돌이 나는 것으로 만들면 된다.
fast-forward. 두 브랜치를 병합하는데 한 브랜치는 변경사항이 없는 경우. 병합을 하지만 실질적으로 병합을 한다기보다 그냥 변경된 버전의 브랜치만 남는다. 이런 상황에서 일어나는 병합을 fast-forward라고 부른다.
원격에서는? pull request를 통해 만들어진 브랜치를 병합한다. 함부로 병합하지 않도록, 요청을 보내는 것이 선행된다.
성공적으로 pull request를 한 모습
제공되는 기능이 많다. 변경사항에 코드 단위로 코멘트도 달 수 있다. 이런 건 직접 하면서 익히면 좋을 듯.
add 4라는 코멘트를 수용하고 다음 커밋이 이뤄진 것을 확인할 수 있다. 위 코멘트에 outdated가 달려있는데 이 코멘트가 있던 파일이 수정됨에 따라 해당 코멘트가 사라지는 것으로 보인다. 로그만 남을 뿐.
코멘트를 남길 때 아예 리뷰를 수행할 수도 있다. 이것은 한 줄에 대한 것이 아니라 전반적인 코드에 대해 남길 때 사용한다. 이 경우 finish your review를 눌러야 비로소 다른 사람에게 내 글이 노출된다.
참고로 깃헙 페이지에서 code . 을 치면 웹 상에서 vscode를 열 수 있다.
아래 merge를 하면 성공적으로 될 경우 이렇게 보라색이 나오며 병합이 이뤄진다!
두 가지 브랜치에 대해 풀리퀘가 있는 상황.
풀리퀘를 통해 원격에서 병합을 한 후, 로컬의 master에 다시 pull을 하는 과정.
병합하기 전에 충돌이 날 것 같은 상황. 미리 알려준다! 로컬에서 병합을 하는 과정을 통해 이것을 해결해줄 수도 있고, 여기에서 당장 해결하는 것도 가능하다. 이런 상황이 크게 나지 않게 미리미리 마스터의 최신 버전에 브랜치를 잘 맞춰주자.
로컬 내에서 병합을 하고 push만 해주면 깃헙에서도 이를 받아들이고 병합된 것으로 쳐준다!
여태한 것은 깃헙 플로우. github flow. 이런 식으로, master를 두면서 브랜치를 통해 병합하는 과정을 하는 방식. 이것 말고도 git flow라는 것도 있다. 이거는 develop이란 브랜치를 또 완전히 새로 둔 채 거기에서 개발을 진행한다. 안전 장치를 하나 더 두는 꼴. 적당히 완성되면 release라는 브랜치를 또 만든다. 여기에서는 출시를 위한 작업들만 진행. 여기에서 진행되는 것들은 최대한 develop에 반영해줘야 함. 이제 정말 다 끝났으면 release를 마스터로 병합. release는 언제나 잘 작동한다는 것이 전제된다. hotfix를 둔다. 마스터에서 기민하게 수정해야할 사항이 생겼을 때 이 브랜치에서 작업하고 바로 마스터로 병합한다. 충돌나는지 테스트는 결국 해봐야하기 때문에 develop으로도 보낸다.
git flow는 라이브 서비스를 염두하고 있기에 이런 복잡한 과정을 거친다.
git tag는 북마크를 찍는다. 말그대로 태그를 거는 것. 이것은 버전에 이름을 붙이는 작업이라고 보면 된다. 중요한 버전에다 태그를 걸어두면 좋겠지? checkout으로 특정 버전을 갈 때 id로 가는 게 항상 빡세다 생각했는데 마침 이런 좋은 명령어가!
rebase. 머지를 하는데 가지가 합쳐지는 것이 아니라 한 줄로 만들어버리고 싶다면? 체리픽의 과정을 차례차례 거친다. 굳이 필요한 기능은 아니지만, 사용하는 경우가 있을 수 있기에 이게 뭔지만 대충 알고 있자. rebase는 사실 거짓된 병합을 하는 꼴이다. 트리를 이쁘게 바꾸기 위해 조작하는 것. 두 브랜치가 병합될 때 양쪽에서의 변경사항들이 많을 것이고, 그것을 병합된 브랜치 관점에서 각각의 기여를 보는 것은 쉽지 않다. rebase는 그저 현재 브랜치의 관점에서 대충 이런 변천사가 있었노라고 퉁친 트리를 만들어주는 녀석이다.
git rebase --continue도중에 충돌이 생겨 수정을 한다면 add를 해주고 다음 명령어를 입력해 rebase를 계속한다(git status에 표시되는 명령어이다.).
여타 명령어도 있다.
호고곡.. 정말 한 줄이 되어버렸다. 깔끔하게 기억 조작 성공.
rebert라는 복잡한 명령어도 있다. 버전을 거꾸로 되돌리는 것. reset은 브랜치 자리만 옮긴다. 근데 rebert는 현재의 버전을 과거의 버전에 업데이트하는 식의 명령어.. 그래서 커밋 기록이 남는다. 쓸 이유 그다지 없는 듯.
공부
오전에는 듣지 못한 깃 특강을 듣고 정리했다. 원래는 13시에 밑러닝 오프라인 스터디가 있을 예정이었으나, 성훈이 형이 독감에 걸리는 바람에 캔슬. 일단 건강이 롱런을 위해 최우선사항이니 빨리 쾌차하길 바랄 따름이다. 이후에는 강의 정리 시간을 오래 가졌다. 사실 나는 다음 주부터 강의가 프로젝트 시작이라 강의가 없을 것이라고, 그래서 이전에 들었던 강의를 정리할 수 있는 시간이 있을 것이라고 안심하고 있었다. 아닌 게 밝혀진 이상, 이전 강의를 정리하는 것을 더는 미루면 안 된다고 생각했다.
다시 공부하면서 내가 놓쳤던 부분이 있었던 것도 확인했고, 짧은 시간에 많은 것을 배우려다 잊어먹은 게 많다는 것을 느꼈다. 아무래도 정리하더라도 이것을 다시 읽는 과정을 거치지 않으면 또 많이 놓치지 않을까 싶다.
회고
조만간 이사를 해야 할 수도 있을 것 같은데, 어떻게 보면 선택은 나에게 달리게 됐다. 당장 내가 공부에 전념하기에 더 좋은 환경은 어디일까? 판단이 잘 서지 않는다. 뭐랄까, 결국 공부에만 온정신을 쏟고 싶어도 그럴 수 없게 일이 진행되어가고 있다. 야속하구만. 될 대로 되라는 식으로 외면할 순 없다. 사실 이미 마음 속에 답이 있는 건 아닐까도 생각해봤는데, 결국 어느 쪽을 선택하더라도 꽤 큰 것을 포기해야만 한다. 내 속에서는 완전히 결론이 나지 않은 듯하다.
그나마 환경의 현상 유지가 가장 내게 타격이 없긴 할 것 같다. 공부하는 것에는 계속 집중할 수 있겠지. 그런데 이 선택이 내게만 의미를 가지는 게 아니다. 그리고 정말로 나는 학업의 관점에 대해서만 이 일을 대할 수 있는가? 조금 더 생활적인 차원에서 고민을 해보자.