팀프로젝트 하면서 정말 신중하게 했던 건 github
관리였다.
첫 프로젝트를 했을 때 commit
충돌이 너무 많이 발생했고 브랜치 관리도 잘 안 됐어서 이번에는 git 관리에 좀 더 집중해보았다.
.
.
.
순탄하게 잘 진행되는 듯 했지만 역시나 github한테 거하게 혼이 나버렸ㄷ ㅏ...🫠
티내지 않았지만(났을지도) develop 브랜치 전부를 날리게 되는건가 싶어서 발동동했다. 대부분 작업이 끝난 상태였어서 더 무서웠닼ㅋㅋㅋ.. 아무튼
그래도 며칠 동안 에러 없이 잘 관리했었고 처음 써보는 명령어들도 있어서 다음 팀플을 위해 남겨두려고 TIL을 썼다.
git pull / pull request
우선 우리는 브랜치를 여러개 만들어서 관리했었다.
add .
, commit
,push
하기.develop
브랜치에 올린 후 pr하기큰 수정사항이 있을 때마다 개인 브랜치에 push
를 해주었고 커밋 메시지 내용도 직관적으로 정리했다.
그리고 pull
을 자주 해서 깃허브에 있는 버전과 내 로컬 버전의 싱크를 맞추려고 노력했다.
아직 깃 사용이 익숙하지 않기도 하고 특히나 브랜치가 개인 작업할 때보다 많아서 어렵거나 헷갈리면 무조건 물어보고 화면공유해서 서로 봐주었다.
이렇게 하니까 오타도 발견할 수 있어서 큰 도움이 되었다.
1. git log
첫번째로 볼 git log 는 git에 commit한 이력을 조회할 수 있다.
vscode 터미널에 치면 이렇게 뜨는데 노란색 commit
옆에 주욱 뜨는 글자들이 commit
한 그 시점의 아이디?
라고 생각하면 쉽다. 이걸 활용해서 코드를 복구할 수 있기 때문에 유용하다.
2. git rebase
git에서 다른 브랜치로 합치는 방법은 2가지가 있는데 merge
와 rebase
이다.
브랜치를 합치는 것 말고도 다른 용도로도 사용할 수 있는데 잘못 push
해서 merge
된 거를 되돌릴 때 사용했었다.
이때 rebase
말고도 git push--force
와 함께 사용한다.
3. git push --force
원격 저장소의 내용과 로컬 저장소의 내용이 일치하도록 원격 저장소의 변경사항들을 강제로 덮어쓰게 될 때 사용한다. 아무래도 강제로 push해서 덮어 씌우는 것이기 때문에 git push --force-with-lease
옵션을 사용하는게 안전한 편이다.
이런 일이 자주 발생하면 안되지만 사람이고 처음이라 다들 어렵고 실수하는게 당연하다!
나중에 회사가서 실수하지말고 여기서 배우면서 많이 경험해보도록 하자!🔥