2019.08.08 git으로 보는 소스 코드 관리

(TIL은 스스로 이해한 것을 바탕으로 정리한 것으로 오류가 있을 수 있습니다)

# 질문에 답하기

  1. git

  • ㅠㅠ.. 분명 며칠 전에 와 거이다 이해했다하고 글을 적었었는데... 그 사이에 또 굉장히 많은 것들을 알게 되어서 다시 정리한다.
  • 그리고 이 글도.. 아마 며칠 뒤면 또 새로워질 것 같아서 걱정이 된다.
  • git은 쉽지 않다.

전체적으로 보면 Origin과 Local이 있다.

  • 일단 전체적인 것을 보는 것이 중요하다.
  • 우리 회사에서는 소스코드 관리를 bitbucket으로 진행되고 있다.
  • 그리고 그 bitbucket에도 origin master와 origin branch가 있다.
  • 내가 이용하고 있는 로컬에도 local master와 local branch가 있다. 이것을 이해하지 못하면 계속 봐도 이해가 안된다.

그림으로 보는 git

스크린샷 2019-08-08 오전 9 22 04
  • 기본적으로 local master의 경우 origin master를 pull해와서 생성한다.
  • local에 해당 파일을 만들었다면 일차 목표는 성공했다.
  • 이제 작업을 하기 위한 과정들을 하나씩 살펴보자

local에서 작업하기

  • local에서 작업하기 위해서는 branch를 따주어야 한다.
  • 그 명령어는 git branch [브랜치명]이다.
  • 보통은 그 이슈가 주어진 명과 비슷하게 따면 좋다.
  • 그 다음에는 git checkout [브랜치명]을 통해 해당 브랜치로 이동한다.
  • 해당 브랜치에서 이동을 한 이후에 작업을 진행 해주면 된다.
  • 작업 도중에 다른 브랜치로 이동하려면 git add 와 git commit을 통해 local에 저장을 시켜줘야 한다.

local에서 작업이 끝난 이후

  • 다시 local master브랜치로 이동을 한다.
  • 먼저 git add와 git commit이 되어야 한다.
  • local master로 이동한 이후에 git status를 확인해보면 그동안 origin master에서 쌓인 다른 작업들을 확인할 수 있다.
  • 일단 그 local master와 origin master를 하나로 합쳐 주어야 한다.
  • local master에서 git pull origin master명령어 실행
  • 그러면 local master와 origin master가 같아진다.
  • 이후에 다시 해당 브랜치로 이동한다.
  • git checkout [브랜치명]

해당 브랜치에서 rebase해주기

  • rebase를 통해서 그 동안 master에서 올라왔던 commit들과 현재 내가 branch에서 했던 commit들을 다시 잘 정렬해준다.
  • rebase 혹은 merge를 해줘도 된다.
  • 근데 merge에 대해서는 다시 한번 생각해봐야 되겠다.

해당 브랜치에서 origin branch로 push 해주기

  • 해당 브랜치에서 git push를 해주면 origin branch로 올라가게 된다.
  • 올리기 전에 git status를 해보고 여러개의 commit들이 꼬여있다고 하면 git push -f를 해주면 된다.
  • 하지만 아마 보통 origin에서 브랜치가 없을 예정이다.
  • 그러면 밑과 같은 경고 메시지가 나온다.

스크린샷 2019-08-07 오전 11 45 30

  • 해당 문구는 origin에 브랜치가 없다는 말로, origin에 올리면서 해당 브랜치도 함께 만들겠다는 명령어이다.
  • 위에 내와 있는 git push --set -upstream origin [브랜치명]을 입력해주면 된다.

origin branch에서 origin master로 pull request 보내주기

  • 이때는 source tree를 사용하여 origin master로 pull request를 보내준다.
  • 아마 회사마다 사용하는 툴이 있을 것이므로 위 과정을 실행해주면 된다.
  • 이제 이때부터 origin master에 merge되기 위해 코드리뷰 등이 시작된다.
  • pull request 좀 받아주세용 ㅠㅠ.

'GIT' 카테고리의 다른 글

GIT 04. Git stash와 git  (0) 2019.12.30
GIT 03. Merge & Rebase  (0) 2019.12.30
GIT 02. GIT 브랜치  (0) 2019.12.30
GIT 01. GIT 한번에 이해하기  (0) 2019.12.30

2019.08.01 git stash와 git에 대해서

(TIL은 스스로 이해한 것을 바탕으로 정리한 것으로 오류가 있을 수 있습니다)

# 질문에 답하기

  1. git

  • git에 대해서 잘못 알고 있었던 부분들이 좀 있었던 것 같다. 그동안 크게 협업을 할 일도 없었고, 크게 브랜치를 섞어가면서 쓸 일도 없었고, git은 그저 소스코드를 관리해주는 용도로만 생각했다. 음 내가 생각한 git은 github(원격저장소)에 가깝다고 하는 게 맞을 것 같다.

잘못된 브랜치에서의 작업

  • 하나의 브랜치에서 한개의 작업을 한다. 그리고 이것에 대해서 너무나도 쉽게 잊어버렸다. ㅎㅎ
  • 가장 첫 번째 작업을 하나의 브랜치에서 작업을 했다. 그리고 commit와 push까지 완료하였다.
  • 하지만 나는 새로운 브랜치를 만들지 않고, 현재의 브랜치에서 또 작업을 진행했다....
  • 평소 같았으면 또 commit과 push를 했을테지만 여기는 회사다 ㅠㅠ
  • 당황한 나는 새로운 브랜치로 옴겨가려고 하였다. 그리고 git checkout master 명령으로 master브랜치로 가려고 하니, 에러 메시지가 발생하였다.

8E426D7E-4E84-4705-ACBC-1EF7209FE1BC

  • 이 메시지를 보고 신나게 checkout -- <파일>을 입력하였다.
  • 그리고 branch를 이동하였다.
  • 근데 다시 작업하던 브랜치로 이동하였을 때 그동안 내가 해놓은 코드들은 모두 사라졌다....
  • 무슨 일????? ㅠㅠㅠㅠ

git은 형상관리를 해준다.

  • 이게 무슨 일인가 당황해하고 있는 나에게 사수분께서 설명해주셨다.
  • git은 형상관리를 하기 때문에 소스의 변화를 끊임없이 감지하고 있고, 위에 git checkout -- <파일>을 진행함으로서 내가 그동안 작업한 것을 모두 되돌린다는 의미이다. 왜냐하면 git commit을 해주지 않았기 때문이다. git add 와 git commit을 통해서 local에 내가 진행했던 코드들에 대해서 저장을 했어야 했는데 하지 않았기 떄문이다 ㅠㅠ.
  • 또 추가적으로 알게 된 것은 이렇게 잘못된 브랜치에서 작업했을 경우 git stash라는 명령어를 활용할 수 있다는 것이다.

git stash

  • git stash는 내가 브랜치에서 작업하다가 다른 branch로 옴겨야 하는 경우가 생겼을 때 commit하지 않고 잠시 작업하던 것을 보관하고 다른 branch로 넘어가는 것이다.
  • 나는 그동안 당연히 !!! 너무나 당연히 git stash처럼 된다고 생각했다. 내가 작업했던 중에 다른 브랜치로 이동해도 내 화면에는 그대로 내가 작업하던 것들이 남아 있으리라 생각했다.
  • 하지만 git은 브랜치 단위로 관리되고 각 branch마다 정말 소스코드가 관리되고 있었다. 즉 각 브랜치로 이동할 때 마다 내 화면에도 소스코드가 모두 변한다는 것이다. 그 동안 진행하였던 프로젝트는 크지 않아 크게 느끼지 않았는데 정말 브랜치를 이동해보니 각각의 코드 상황이 달랐다.
  • 따라서 만약에 해당 상황이 발생하면 git stash를 기억하자

git stash 명령어

  • git stash : 하던 작업을 저장하고 가장 최근 commit상태로 만든다.(임시저장)
  • 해당 브랜치 이동
  • git stash pop 또는 git stash apply : 저장되어 있는 작업 중 가장 최근 stash를 가져와서 적용
    • git stash pop은 stash list에 남지 않고 stash apply는 stash list에 남는다.
  • git stash list : stash 목록을 본다.

'GIT' 카테고리의 다른 글

GIT 05. git으로 보는 소스코드 관리  (0) 2019.12.30
GIT 03. Merge & Rebase  (0) 2019.12.30
GIT 02. GIT 브랜치  (0) 2019.12.30
GIT 01. GIT 한번에 이해하기  (0) 2019.12.30

2019.07.29 MERGE & REBASE

(TIL은 스스로 이해한 것을 바탕으로 정리한 것으로 오류가 있을 수 있습니다)

# 질문에 답하기

  1. git rebase란?

  • 깃에서 작업을 위해 master에서 새로운 branch를 따서 작업을 할 때, 협업상황에서 다른 사람이 master에 commit하는 상황이 발생하게 된다. 그런 경우 현재 내가 작업하고 있는 master는 현재의 master와는 다른 상황이 발생하게 된다. 이 경우 rebase를 통해 이때까지 commit된 상태의 최상단으로 현재 내가 작업하고 있는 master를 옴기는 것을 rebase라고 한다.

merge 와 rebase

  • merge 와 rebase 의 경우 모두 git의 코드를 합치는 방법인데 탕수육의 부먹과 찍먹과 같이 서로 추구하는 방향에 따라서 다르게 사용한다고 하였다.
  • 각각의 장단점에 대해서 살펴보자.

merging의 장점

  • 이해하기 쉽다.
  • 원래 브랜치의 컨텍스트를 유지한다.
  • 브랜치 별로 커밋을 분리해서 유지해준다.
  • 원래 브랜치의 커밋들은 변경되지 않고 계속 유지되어 다른 개발자들의 작업과 공유대는 것에 대해 신경 쓸 필요가 없다.

merging의 단점

  • 모든 사람들이 같은 브랜치에서 작업하기 때문에 머지해야 할 때는 merge가 커밋 히스토리상으로 전혀 유용하지 않고 어지럽기만 하다.

rebase 장점

  • 단순한 히스토리
  • 여러 개발자들이 같은 브랜치를 공유할 때 커밋을 합치는 가장 직관적이고 깔끔한 방법

rebase 단점

  • 충돌상황에서 다소 복잡하다. 커밋 순서대로 rebase를 하는데, 각 커밋마다 충돌해소를 순서대로 해주어야 한다. SourceTree가 가이드하기는 하지만, 역시 복잡한 것은 사실이다.
  • 해당 커밋들을 다른 곳에 푸시한 적이 있다면 히스토리를 다시 쓰는 것에 부작용이 발생한다. Mercurial에서는 간단히 푸시를 할 수 없다. git에서는 push할 수 있으나 나 혼자 쓰는 리모트 브랜치에서만 가능하다. 만약 다른 사람이 그 브랜치를 체크아웃 받은 후 내가 리베이스 한다면 꽤 혼란스럽게 될 것이다.

결론

  • rebase와 merging 모두 각자의 가치가 있어서 상황에 따라 다르게 사용해야 한다.

Git Merging 과 Rebase 의 상황별 사용법 – ElegantCoder

'GIT' 카테고리의 다른 글

GIT 05. git으로 보는 소스코드 관리  (0) 2019.12.30
GIT 04. Git stash와 git  (0) 2019.12.30
GIT 02. GIT 브랜치  (0) 2019.12.30
GIT 01. GIT 한번에 이해하기  (0) 2019.12.30

2019.04.10 TIL

(TIL은 스스로 이해한 것을 바탕으로 정리한 것으로 오류가 있을 수 있습니다)

# 질문에 답하기

  1. 원격 저장소

원격 저장소는 소스코드와 버전을 백업 및 관리하고, 다른 사람과의 협업이 가능하도록 도와주는 기능이다.

  • 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        # 새로은 브랜치로 이동
스크린샷 2019-04-10 오전 11 26 01

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
스크린샷 2019-04-10 오전 11 31 07

마스터에서 merge 해주기

git checkout master        #마스터 브랜치로 이동
git branch                        #실제 이동 상태 확인
git merge feat/loop            # feat/loop를 마스터 브랜치로 merge
git status                            #현재 git 상태확인
git push origin master           # origin master로 전송
AC062E9B-7327-4645-8C2C-8A1DC56AC96D

브런치 지우기

우리가 실제로 작업 할 때 기능 개발이 완벽히 끝났을 때는 브랜치가 남아 있으면 안된다.

git branch -D <브랜치 이름>

우리가 개발하는 모든 부분은 DEV이라는 브런치를 따서 만들고
master에는 고객들이 쓰는 상용화 된 것만 놔둔다. 우리는 항상 master를 쓸 일이 잘 있지 않을 것이다.

master를 지워도 타임스탬프로 돌아가면 된다.
뭔가 이유 없는 테이블은 없다. DB를 훔쳐보면 안된다.

git flow strategy

참고 : 티몬의 개발이야기 : 네이버 블로그

스크린샷 2019-04-10 오후 12 20 02
  • 메인 공간은 사용자만 쓰는 것으로 놔둬야 한다.
  • git flow를 통해서 브랜치 관리를 쉽게 사용할 수 있다.
  • git-flow : git-flow cheatsheet
  • git init 이후에 바로 git flow init 으로 git flow 도 쓸 것이라고 해준다.
  • git flow init을 설정까지 하고 나면 develop가 알아서 생성되고 들어가준다.
스크린샷 2019-04-10 오후 12 20 32
  • 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 해줘야 한다.

89512A50-75B9-4255-BEEB-EF7AAB1C7277

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은 작업하면서 최신 버전을 가져올 때
사용한다고 생각하시면 좋을 것 같습니다.

'GIT' 카테고리의 다른 글

GIT 05. git으로 보는 소스코드 관리  (0) 2019.12.30
GIT 04. Git stash와 git  (0) 2019.12.30
GIT 03. Merge & Rebase  (0) 2019.12.30
GIT 01. GIT 한번에 이해하기  (0) 2019.12.30

2019.04.04 TIL

(TIL은 스스로 이해한 것을 바탕으로 정리한 것으로 오류가 있을 수 있습니다)

# 질문에 답하기

  1. 깃의 흐름에 대해 이야기해보세요
git process
  • 알면 좋은 것
    • 깃허브 - 깃을 기반으로한 소스코드 버전관리
    • 빅버킷 - 5인 이하의 팀에서 비공개 저장소가 무료
    • 깃랩 - 로컬에 사설 저장소를 만들고 이용할 수 있도록 해준다.

목적 : git remote에 보내기 위해 송장을 완성한다.

git init : 택배 부치기로 마음 먹음

  • index와 local reprository가 생겨나게 된다. 내가 앞으로 git으로 버전관리를 시작하겠다.

git init도 지우고 싶다고 하면 :

  1. ls - al에서 .git이 있는 것을 지워준다.
  2. rm -rf .git

무조건 상위에 있는 git을 따라가기 때문에 가장 상위에서 git을 하게 되면 난리난다. 따라서 내가 정말 관리하고 싶은 것만 해야 한다. 이 실수를 한번 했었기 때문에 절대 하면 안된다.

git status — > 현재 깃의 상태를 확인한다.

git config —global 을 했었기 때문에 등록이 되어있다.

보내는 사람은 git config로 설정해준다. (한번만 해주면 자동등록되어 있다)

  • git config —global user.name “byeonguk kim”
  • git config —global user.email gang0406@naver.com

받는 사람에 대한 설정은 모두 git remote로 한다.

git remote 관련된 것들 확인 : git remote help

  • 받는 사람 주소 추가 : git remote add 별명 주소

  • 주소가 길기 때문에 보통 origin이라는 별명을 쓴다. 오늘은 cat
    git remote add 별명 주소

  • 실제 주소 확인:

    • git remote get-url cat 하면 실제주소 확인
  • 설정된 주소 삭제:

    • git remote remove cat

ADD 택배보내기

  • 보낼 제품 고르기

    • git add hello.py
  • 모든 제품 보내기

    • git add -A
    • git add .
  • 제품 잘 들어갔나 확인해보기

    • git status

COMMIT: 받는 사람에게 편지 첨부하기

  • git commit -m “제목 : 엔터 + 내용 "

  • git commit —>vim 이 실행됨

  • 제목 적기 (제목은 항상 클리어하게 나와야 한다- 제목만 보고도 이 당시에 무엇을 했는지 알 수 있도록 한다)

    • feat : 제목 수정
    • doc: 도큐먼트
    • fix: 파일 수정
  • 내용 적기 : 제목과 2줄 간격을 띄우고 내용 적기

  • 다시 normal 모드(esc)로 가서 :wq (저장하고 나가기)

  • 이까지 하면 local repository에 쌓이게 된다.

  • 파일 생성 및 vim으로 바로 들어가기 : touch hello.py && vi hello.py

  • tip: 꼭 동작이 되는 것을 보내야 한다. 왜냐하면 다른 사람이 보고 이상하다고 생각할 수 있기 때문이다.
    따라서 커밋을 한다는 것은 꼭 동작하는 코드를 올려줘야 한다.

  • tip

commit에 관련해서는
파이썬에서는 마지막 엘리먼트의 ,를 놔두고 쓰면 장점이 있다.
파이썬의 컬렉션을 쓸 때는 마지막에 ,를 붙여 놓고 쓴다.
그리고 엔터를 치고 나열한다.

리스트 또는 딕셔너리는

li = [1,2,3,4,]가 아니라.
===>
li = [
1,
2,
3,
4,
]

dic = {
“a” : 1,
“b” : 2,
“c” : 3,
“d” : 4,
}

하는게 좋다.

일렬로 적어 놓으면 새롭게 지우고 새롭게 추가하게 나온다.

PUSH: 우체국으로 넘겨주기(온라인)

내가 살고 있는 우체국에 꼭 넘겨줘야한다.
딱 한번만 진행하면 된다.
내가 보낼려고 하는 우체국과 받는 우체국이 같다고 알려줘야 한다.

git push -u origin master(깃허브의 별명을 넣어주면 된다.)

한번 이후에는
git push origin master (git push를 할 수 있지만 명시적으로 표시해줘야한다.)

vim의 모드

  1. normal — 켜자마자 나오는 모드
  2. insert mode —> normal에서 i를 눌러야 한다. esc는 해제
  3. visual mode —> 블록 설정 normal 에서 v를 눌러야 한다.
  4. 항상 명령은 normal에서 수행 shift + : ==> 메뉴바
    1. 빠져나가기 :q
    2. 저장하기 : wq (저장하고 나가기)
    3. 좌우이동 : hjkl 만들기

이 주소지에 몇가지를 담아놓고 clone을 해오는 것(반대로 우체국에서 가지고 오기)

특정 폴더에서 git clone https://github.com/fabl1106/first-cloned-repo.git 레파지토리 주소

ls -al을 해보면 깃허브에 있는 것을 로컬로 가지고 온 것을 알 수 있다.

LICENSE : MIT license 자유롭게 쓰세요

  • GNU GPL : gpl을 따르거나, 라이센스를 풀거나 해라.

README.md : 생성한 페이지의 메인 페이지

#Custom

gitignore : 환경 설정을 한다. 무시하게 만든다. 환경 설정을 한다.

vim 으로 접속하면 수정할 수 있다.

hidden/ #hidden 디렉토리에 있는 모든 파일을 무시한다.
.java #java로 생성된 파일을 무시한다.
.DS_Store #mac에서는 꼭 하면 좋다.
hell.
#hell이라는 이름으로 생성된 모든 확장자 파일을 삭제해라

  • 별개의 작업은 각각의 박스에 담아서 commit을 해준다.
  • 먼저 git add를 한개씩 해준다.
  • stage가 있으면 개발 커밋이 가능해진다.
  • local repository 오프라인 개발이 가능하게 해준다.

방법은 2가지이다.

  1. git init해서 commit 해놓고 나중에 repository를 만들고 commit
  2. 먼저 repository를 만들어놓고 시작한다.

'GIT' 카테고리의 다른 글

GIT 05. git으로 보는 소스코드 관리  (0) 2019.12.30
GIT 04. Git stash와 git  (0) 2019.12.30
GIT 03. Merge & Rebase  (0) 2019.12.30
GIT 02. GIT 브랜치  (0) 2019.12.30

+ Recent posts