2019.04.10 TIL
(TIL은 스스로 이해한 것을 바탕으로 정리한 것으로 오류가 있을 수 있습니다)
# 질문에 답하기
원격 저장소
원격 저장소는 소스코드와 버전을 백업 및 관리하고, 다른 사람과의 협업이 가능하도록 도와주는 기능이다.
- local repository & remote repository
- 원격저장소의 중요한 의미 2가지
- 소스코드를 백업한다.
- 다른사람과 협업한다.
- 참고 : Git - 리모트 브랜치
원격 저장소를 지역 저장소로 복제
clone 명령어는 다음과 같습니다.
- git clone { 원격 저장소 URL }
특정 브랜치를 clone 하고 싶다면,
- git clone -b { 브랜치명 } { 원격 저장소 URL }
지역 저장소에서 브랜치 작업 시작
현재 브랜치의 상태 확인
- git branch : 지금 현재 어느 브런치로 설정되어 있는지 확인
- git branch -r : remote branch 확인(원격저장소 브랜치 확인)
- git branch -a : 모든 브랜치 상태 확인
브랜치 생성
git branch feat/loop
- master 브랜치 밑에 feat/loop 브랜치 생성
- 확인 : git branch로 확인을 해보면 feat/loop 브랜치 생성
- 아직까지 remote에는 생성되지 않았다. (commit을 해줘야 생성된다.)
- 브랜치 생성만 해주면 github에서 인식 불가
브랜치 이동
**git checkout <브랜치 이름="">**
- git branch를 통해 실제로 이동했는지 확인한다.
브랜치를 원격 저장소로 전송
git push -u origin feat/loop
- 새로운 브런치를 만들고 처음 원격 저장소로 업로드 할 때는 -u를 해줘서 업스트링 셋을 해줘야 한다.
- 한번만 경로 설정 이후에는 git push를 통해 진행을 해도 가능하다.
- 안해주면 10분정도 혼날 수 있는 각이다.
브랜치 밑에 새로은 브랜치 생성
git checkout feat/loop # 새로운 브랜치 바로 위의 브랜치로 이동
git branch feat/con-state # 새로운 브랜치 생성
git branch # 생성 확인
git checkout feat/con-state # 새로은 브랜치로 이동
MERGE (당긴다)
feat/con-state를 feat/loop 로 옴기기
- 당긴다고 생각하면 좋다.
- 당길 곳으로 이동해서 그 당길 것을 당긴다.
- feat /loop로 이동해서 feat/con-state를 당긴다.
git checkout feat/loop
git merge feat/con-state
# feat/loop 입장에서는 feat/con-state 내용이 들어온 것이므로 commit이 한개 생긴다.
git push -u origin feat/loop
마스터에서 merge 해주기
git checkout master #마스터 브랜치로 이동
git branch #실제 이동 상태 확인
git merge feat/loop # feat/loop를 마스터 브랜치로 merge
git status #현재 git 상태확인
git push origin master # origin master로 전송
브런치 지우기
우리가 실제로 작업 할 때 기능 개발이 완벽히 끝났을 때는 브랜치가 남아 있으면 안된다.
**git branch -D <브랜치 이름="">**
우리가 개발하는 모든 부분은 DEV이라는 브런치를 따서 만들고
master에는 고객들이 쓰는 상용화 된 것만 놔둔다. 우리는 항상 master를 쓸 일이 잘 있지 않을 것이다.
master를 지워도 타임스탬프로 돌아가면 된다.
뭔가 이유 없는 테이블은 없다. DB를 훔쳐보면 안된다.
git flow strategy
- 메인 공간은 사용자만 쓰는 것으로 놔둬야 한다.
- git flow를 통해서 브랜치 관리를 쉽게 사용할 수 있다.
- git-flow : git-flow cheatsheet
- git init 이후에 바로 git flow init 으로 git flow 도 쓸 것이라고 해준다.
- git flow init을 설정까지 하고 나면 develop가 알아서 생성되고 들어가준다.
- git flow init 이후에 feature,release,hotfix 각각에 start/ finish / publish/ pull 사용 가능
- git flow feature start <이름> ==> 해당 브런치를 생성해주고 해당 브랜치로 이동까지 해준다.
release란?
- 배포를 위한 버전 관리
- git flow release start/finish/publish/pull 가능
v.0.0.1.00190410001
릴리즈 피니시를 하면 merge에 관한 것 1개와 release 작업 물에 대한 태그를 달 수 있는 2개가 나온다.
릴리즈 절차를 끝내면 마스터와 develop에 commit이 남는다.
github에서 확인하기 위해서는 마스터 및 develop에서 push 해줘야 한다.
git 을 기반으로 git-flow를 사용하여 애플리케이션 배포버전을 관리하자.
git clone, pull, fetch의 차이
- 이해하기에 좋은 글이 있어서 그대로 가지고 옵니다.
[참고 : Git 개념] remote, push, clone, pull :: victolee
git pull 명령어 역시 Github에 있는 파일들을 local로 가져오는 것입니다.
git clone은 Github의 모든 파일들을 가져오기만 하는 것이고,
git pull은 local repository에 저장( add )까지 되며, 현재 local repository와 비교까지 합니다.
다시 말하면, git pull = git fetch + git merge 와 같습니다.
git fetch는 local에 연결된 remote repository의 브랜치 목록과 그 파일 내용을 가져오는 역할, 즉 업데이트를 하는 명령어입니다.
git merge는 나중에 알아볼 명령어인데, 두 개의 branch를 병합해서 하나의 코드로 만드는 명령어입니다.
즉, git pull은 협업 과정에서 최신 코드로 업데이트 하는 용도로 많이 사용합니다.
예를 들어, 팀 프로젝트를 진행하다가 친구가 기능 구현을 완료해서 git push를 했다고 가정해보겠습니다.
저는 새로운 버전을 사용하기 위하여 Github에 있는 코드를 가져와야 하는데 어떤 방식으로 가져와야 할까요?
git clone을 하면 제가 그동안 작업했던 내용들과 최신 버전의 파일은 독립된 존재가 되어버립니다.
즉, clone을 해서 받은 폴더에 제가 작업했던 내용들을 일일이 수작업으로 적용시켜야 하죠. 이는 좋은 방법이 아닙니다.
git pull을 하면 어떨까요?
현재 제가 작업 중인 local repository와 최신 코드가 비교되고 병합되어, 최신 버전 파일들이 저의 local repository에 적용됩니다.
따라서 제가 작업하고 있던 코드들과 최신 버전 파일의 코드는 함께 존재하게 되죠.
즉, 제가 작업한 코드와 친구의 작업 코드가 자동으로 합쳐지게 되니까 매우 바람직합니다.
그런데 만약 동일한 파일 내역을 수정했다면 어떻게 될까요?
이 경우 충돌( conflicts )이 발생하며 일일이 충돌된 부분을 수정해야 합니다.
이 부분은 다음 글에서 merge를 할 때 다루도록 하겠습니다.
정리하자면,
git clone은 완전히 새로운 프로젝트에 투입 되었을 때,
git pull은 작업하면서 최신 버전을 가져올 때
사용한다고 생각하시면 좋을 것 같습니다.