Git
소스코드를 효율적으로 관리하기 위해 만들어진 '분산형 버전 관리 시스템'
사용하는 이유?
소스코드의 변경 이력을 쉽게 확인
특정 시점에 저장된 버전과 비교, 특정 시점으로 돌아가기 용이
브랜치Branch
- 독립적으로 어떤 작업을 하기 위해 필요한 개념
: 최초 branch에서 파생한 각각의 branch를 만들어 작업을 수행하고,
최초 branch로 merge를 통해 각자 작업한 것을 합치는 것도 가능하다.
Branch 생성하기
깃에 새로운 브랜치 만들고, 올리기
- 브랜치 생성 : git branch "branch2"
- 브랜치 옮기기 : git checkout branch2
수정사항 그 브랜치에 올리려면 위치에 가 있기
git add .
git commit -m "메세지"
git push origin branch2
(새 브랜치에는 origin 필수!)
브랜치 삭제하기
로컬에서 지우기 git branch -d branch2
만약 안되면 git branch -D branch2
깃에서 지우기 git push origin --delete branch2
새로운 브랜치 생성 및 이동을 동시에
git checkout -b "만들 브랜치명"
Merge
- git branch를 다른 branch로 합치는 과정
ex. a 브랜치에 b 브랜치를 합치고 싶은 경우
git checkout a //a 브랜치로 이동
git merge b // b브랜치에 합치기
Case1
a와b브랜치에서 서로 다른 파일을 수정했을 때
각각 브랜치 a, b를 만들고
각각 다른 파일을 수정한 뒤 merge
> 알아서 합쳐진다
git branch a
git branch b
a브랜치로 넘어간 다음 b를 병합(merge)한다.
이때 vscocde 터미널에서 하면 git bash와 달리 merge메세지를 설정할 수 없고 자동으로 머지라는 메세지가 설정되어있다고 한다.
(메세지 설정없이 자동 merge)
Git bash를 이용하면 i를 눌러 insert 모드로 메세지를 바꿀 수 있다 .
수정한 다음에는 wq! 를 눌러 나온다.
merge를 한 다음에 이를 다시 깃에 반영해야한다.
git push origin a
그럼 잘 합쳐진걸 확인할 수있다.
Case2
서로 같은 파일에서 다른 부분을 수정했을 때
c는 title을 branch C로,
d는 body의 h1 부분을 D branch로 수정한다.
알아서 잘 합쳐진다!
Case3
서로 같은 파일에서 같은 부분을 수정했을 때
e branch와 f branch를 만들어서 둘 다 title을 수정한다.
병합할 branch로 간다. (요기서는 e branch로 이동)
그 다음 병합할 브랜치명을 입력한다. (f branch)
짠~
같은 파일에서 같은 부분을 수정하면, conflict (충돌)이 일어난다!
-> 수동으로 해결해야 한다!
1. 현재 브랜치를 반영
2. 병합할 브랜치 반영
3. 둘다 반영 (이때는 title이 두 개가 된다)
4. 비교하겠다
이때 모두 선택하지 않고 새롭게 작성해도 된다!
단 충돌이 난 이후, 해결이 된 다음
git add .
git commit -m
git push 을 해줘야 완료!
즉, 충돌이 났다면
해결 후 파일 저장 -> add -> commit -> push
수동으로 코드를 머지하면 된다.
프로젝트를 위한 개발 git 상식
Branch의 종류
master(main)
- 제품으로 출시될 수 있는 브랜치 (완성이 되면 마스터에 올리는 것 )
- 배포 이력을 관리하기 위해 사용
- 배포 가능한 상태만을 관리하는 브랜치
develop
- 다음 출시 버전을 개발하는 브랜치
- 기능 개발을 위한 브랜치들을 병합하기 위해 사용
- 평소 개발을 진행하는 브랜치 (보통 여기서 공부한다)
feature
- 기능 개발을 진행하는 브랜치
- 새로운 기능 개발 및 버그 수정을 할 때 마다,
'develop'에서 분기
- 공유할 필요가 없어 로컬에서 진행 후
develop 에 merge해 공유
- 이름 : feature/~~~
release
- 출시 버전을 준비하는 브랜치
- 배포를 위한 전용 브랜치
- 이름 : release-0.0
hotfix
- 출시 버전 이후 발생한 버그 수정 브랜치
- 배포한 버전에 긴급하게 수정해야 할 필요가 있는 경우 사용
- Master에서 분기- 이름 : hotfix-0.0.0
보통 우리가 팀플로 작업할 때에는 develop을 기본으로 두고 feature를 사용할 것이다!
add와 commit , 동시에 하기
git add .
git commit -m "커밋메세지"
여기서 .은 현재 위치이므로 다른 특정한 것을 올릴 수 있다.
이 둘을 동시에 하는
git commit -am "커밋메세지"
이때 .처럼 특정한 파일만 골라서 커밋할 수는 없다.
Commit 취소하기
가장 최근에 한 커밋&add 취소
git reset HEAD^
특정 커밋 취소
이때 특정 커밋의 아이디를 알아야 한다
git log
를 하면 commit 오른쪽의 id가 나온다
git reset --hard id(b~~~~)
Pull Request
- push 권한이 없는 오픈소스 프로젝트에 기여할 때 많이 사용함
- "내가 수정한 코드가 있으니, 내 branch를 가져가 병합 해주세요!"
- 당황스러운 코드 충돌을 줄일 수 있다.
머지 방식은 3가지가 있다.
먼저 pull Request를 한 다음, 누군가의 review가 달리면 확인 받고 merge하는 걸 추천!
또한 가장 많은 실수 중 하나는 같은 class 이름을 사용한 경우 제대로 불러와지지 않는 오류가 있으므로 꼭 확인
.gitignore
- git 버전 관리에서 제외할 파일 목록을 지정하는 파일
- 파일이나 변경 이력을 관리할 때, .gitignore에 제외할 파일을 적으면 제외한다
- 보통 라이브러리 등을 무시할 때 사용한다. (용량만 크므로 굳이 올리지 않는다)
- mySQL을 할 때, 아이디나 비밀번호를 깃에 올리지 않기 위해 사용 (개인정보)
- 단 git이 무시할 수 있는 것은 "아직 한 번도 올라가지 않은 파일"에 한함
즉 git에 이미 올라가 추적이 시작되었다면, 그 파일은 무시할 수 없는 파일!
따라서 처음 깃에 올리기 전에 무시할 파일을 명시하자.
*.txt 확장자 txt로 끝나는 파일 모두 무시
!test.txt test.txt는 무시되지 않음
test/ test 폴더 내부의 모든 파일 무시
/test (현재폴더)내에 존재하는 폴더 내부의 모든 파일 무시
'[부트캠프] IT 코딩 부트캠프 후기 > [Let's TIL🚴♀️] CodingON' 카테고리의 다른 글
| [Node.js] 노드 내장 객체와 모듈 알기 (+ 객체 구조 분해, 콜백 함수) (2) | 2022.11.19 |
|---|---|
| [Node.Js] Node.js 설치와 기초 (0) | 2022.11.15 |
| [개발 문화 및 협업 도구] 개발 방법론(폭포수, 애자일) and 스크럼, 칸반 (0) | 2022.11.15 |
| [Server서버] NCP 서버 구축하기 (Naver Cloud Platform) (0) | 2022.11.14 |
| [JQuery] 제이쿼리와 부트스트랩(Bootstrap) ch.1 (0) | 2022.11.10 |
