관리 메뉴

프론트엔드 정복하기

Git & Bit Bucket 본문

버전 관리

Git & Bit Bucket

GROWNFRESH 2020. 11. 14. 11:00

소스 코드의 '변경 사항'을 관리하는 도구 = 버전 관리 시스템 이라고 한다.

 

<버전>을 통해 만들어진 => 각각의 파일을 => 백업해주고 공유해서 => 여러 사람이 작업할 수 있게 해주는 것.

 

 

버전관리 시스템

: 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