오늘 수업에서는 branch에 대한 내용이 주를 이루었다. 배운 내용들을 간단히 적은 후 오늘 알게 된 내용들을 써보겠다.
⚙ git branch 관련 명령어 간단 요약
$ git config --global init.defaultBranch main
앞으로 생성하는 주 브랜치를 main 이름으로 생성
$ git branch -m main
이미 생성된 브랜치의 명칭을 main으로 바꾸고, 기능을 전부 옮김.
$ git switch -c (새 브랜치 명) == $git checkout -b
새롭게 브랜치를 생성하고, 해당 브랜치로 이동.
$ git branch --list == git branch
현재 생성된 모든 브랜치를 확인함.
$ git branch -D (지울 브랜치 명)
기존의 브랜치를 삭제함. 단, 현재 사용중인 브랜치는 삭제 불가.
$ rm -rf .git (git bash, mac용)
$ rmdir /s /q .git (window용)
git 명령어 결과물이 모두 삭제됨. (+ 브랜치도 다 지워짐!)
$ git merge (병합할 브랜치명)
병합하고자 하는 브랜치에서 사용.
🚅 Fast-Forward
Fast-Forward 란?
새로운 commit 이 생기는 것이 아니라, 다른 브랜치에 있던 commit 기록이 병합되면서 이어지도록 커밋 기록이 만들어지는 것
- 장점 : 분기점이 남지 않기 때문에 커밋 기록을 더 직관적으로 확인할 수 있다.
- 단점 : merge했다는 기록도 없고, 분기점도 없다.
$ git merge develop --no-ff
Fast-Forward 방식 off (기록 남기기)🪂 Pull Request
pull request란?
협업의 한 형태로, 자신의 브랜치에서 완성한 코드를 병합하기 위해 요청을 보내는 것.
pull request를 하는 이유
- 작성한 코드에서 발생할 수 있는 문제들을 merge전에 방지
- 현재 코드에 대한 리뷰 진행
- 프로젝트 진행상황의 효율적인 관리
🛠 Github - issue/milestone
issue/milestone이란?
issue - 새롭게 추가될 가능, 개선 해야할 가능, 버그 등등의 모든 것.
ex) branch의 생성목적 == 한 기능의 구현 -> 하나의 issue
milestone - 작업 방향의 이정표 및 issue들의 집합.
Git clone 문제점 확인 및 해결
오늘은 수업이 끝난 후 고맙게도 같은조 하연님께서 선뜻 실습을 같이 진행해보자고 제안해주셨다.
(감사합니다.. 덕분에 좋은 공부가 됐어요..)
실습을 진행하게 되면서 내가 그동안 git을 잘못된 방법으로 사용하고 있었던 것을 확인할 수 있었다.
1. 현재 터미널의 위치를 항상 확인하자.
사진을 보면 터미널의 경로가 C:\Yanolja\study> 인 것과는 달리, 현재 실습을 위해 clone을 진행항 파일은 똑같은 이름의 Study라는 폴더안에 무려 2개나 더 중복되는 폴더가 있음을 확인할 수 있다.
이와 같은 상황이 발생하면, main 브랜치는 상위 study 폴더에 지정되어 있지만, 하위 branch는 제일 안쪽의 study 폴더부터 발생하는 문제점을 야기 할 수도 있다.
repo에서 clone을 하기 전 항상 터미널의 현재 위치를 확인하여 올바를 경로를 지정해야 한다.
2. push는 main 브랜치로, pull은 내 브랜치에서?
그동안 Github 데스크탑 프로그램의 힘만 빌리다 보니, 직접 git 명령어를 통해서 branch를 관리하려다 보니 헷갈리는 부분이 이만 저만이 아니었다.. 그러다 보니 어디로 push와 pull을 해야할지 많이 헷갈리기도 했다.
push의 경우 내가 작업한 결과물이 있는 해당 branch, 즉 내 브랜치로 push를 해 주어야 하고, pull의 경우 만약 병합을 한 상황이라고 가정한다면, 내가 작업한 결과물을 병합했던 브랜치에서 pull을 해와야 한다. 이는 협업간 발생할 수 있는 merge conflict를 최소한으로 하기 위해서라고 보면 되겠다.
잘가.. Github Desktop.. 다음에 보자..
