프론트엔드 정복하기
Git & Bit Bucket 본문
소스 코드의 '변경 사항'을 관리하는 도구 = 버전 관리 시스템 이라고 한다.
<버전>을 통해 만들어진 => 각각의 파일을 => 백업해주고 공유해서 => 여러 사람이 작업할 수 있게 해주는 것.
버전관리 시스템
: CVS, SVN, GIT 등
Client와 Server의 개념
** Dropbox
Dropbox Client : 파일을 수정했을 때 수정한 파일을 업로드해주는 역할
dropbox.com (Server) : 수정된 파일을 업로드 받아서 server에 올려주는 역할
** Git (오픈소스로 구성된 시스템)
Git Client : 소스트리, github desktop 등등...
Git Server : Git 원격 저장소 라고도 부른다. (Github.com, bitbucket 등 다양하게 존재함)
WorkFlow
: origin/master에서 branch 생성 => branch 작업 및 완성 => dev로 merge => dev는 master에 병합
-
master에서 local branch 생성
-Source Tree (이하 ST) : master탭을 더블클릭하여 checkout한다. => master에서 브랜치 분리 버튼 클릭
-command (이하 CM) : git branch 브랜치명
-
생성한 branch에 checkout
-ST : 해당 branch를 더블클릭
-CM : git checkout 브랜치명
( 현재 체크아웃한 브랜치 확인 : git branch )
-
이때, untracked file 등장
: git status 했을 때, untracked 파일이 존재하고, git add 하라고 나온다.
*여기서, untracked file이란?)
git은 자기 폴더에 있는 파일을 크게 Tracked, Untracked 두 가지 상태로 분류하여 관리한다.
Untracked 파일이란, Git이 관리하지 않는 상태의 것을 말한다.
빨간 글씨로 표기된 untracked file의 location을 복사 한 후,
git add 복사한로케이션
file이 여러개라면, 띄어쓰기로 여러 개를 add한다.
git add 복사한로케이션1 복사한로케이션2
stash한거는???
-
작업 완료 후 push하기
처음 push할 때
git push -u origin 브랜치명
=> -u : 로컬브랜치가 remote branch를 track한다는걸 명확히 해준다.
=> pull request를 위한 URL이 제공된다.
*** 여기서 pull request란?) 당신이 변경한 내용에 대해서 다른 사람들에게 말해준다.
작업 제목 + 설명 + commit 기록 + reviewer를 설정해서 올림.
(remote : https://..... 라는 url이 나옴.)
이 url을 주소창에 치면 bitbucket 페이지에서
Create a pull request 창이 뜬다.
=> 브랜치 => 병합할 브랜치
pull request를 하고 merge할 수 있게 됨.
-
브랜치 삭제
=> 우선 dev 브랜치로 체크아웃한다.
=> remote repository에서 pull 한다. : 모든 remote repository 변화를 불러온다.
: git pull origin dev브랜치명
git branch -a
: all 모든 브랜치와 체크아웃한 브랜치를 보여준다.
git branch -D 삭제할브랜치명
: 작업했던 로컬브랜치가 삭제된다.
git push origin --delete 삭제할브랜치명
: 작업했던 원격브랜치 또한 삭제된다.
Question
Q ) add, commit을 여러 번 하고, push하면 여러 개의 commit이 올라가는가???
: add, commit을 여러 번 하는 것도 가능하다.
단, commit을 하나로 합치고 싶다면
rebase 명령어 사용 (검색해보기)
'분리 하기 전에 미리 했을 경우 어떻게 stash 하는가'
'충돌 났을 때 대처하는 방법'
'같은 branch에서 또 push를 하면 어떤 현상이 발생하는가?'
'소스 트리 보는 방법'
'master에서 분리하고, merge는 dev에서 하는 것이 맞는가?'
처음 작업을 시작할 때는, origin/master ? master ? dev ? origin/dev ?
아무런 pull 받을 게 없고, 추가수정된 게 없을 때 : origin/master
사람들이 작업을 하면 origin/dev 상태가 무조건 되어 있을거다.
master에서 하는 게 맞지 싶다.
작업 모두 마치고 master로 병합하기 전에
dev 단계에서 실험을 해보고 싶을 때!!
dev로 체크아웃 한 후, pull 받아서 실행?!
'버전 관리' 카테고리의 다른 글
git diff로 브랜치 간 차이점 확인하기 (0) | 2020.12.24 |
---|---|
git에서 원격저장소의 branch 가져오기 (0) | 2020.12.24 |
git stash 사용법 (0) | 2020.11.15 |