들어가기 앞서.
분산버전 롼리시스템은 다른사람과의 협업을 염두에두고 만들어진 툴입니다. 결국 원격저장소와 로컬 저장소 사이를 얼마나 효율적으로 관리하느냐가 관건입니다. Git에서는 원격저장소와 소통하기 위한 기능을 제공하고있습니다.
GIT 명령어를 알아봅시다.
git clone: 원격 저장소의 모든 내용을 로컬저장소에 복사합니다.
git remote: 로컬저장소를 특정 원격 저장소와 연결합니다.
git push: 로컬 저장소의 내용을 보내거나 로컬 저장소의 변경사항을 원격 저장소로 보냅니다.
git fetch: 로컬저장소와 원격 저장소의 변경사항이 다를때 이를 대조하고 git merge 명령어와 함께 최신 데이터를 반영하거나 충돌문제등을 해결합니다.
git pull: git remote 명령을 통해 서로 연결된 원격저장소의 최신내용을 로컬 저장소로 가져오면서 병합합니다. gir push와 반대 성격의 명령입니다.
Git Clone: 원격저장소의 내용을 로컬 저장소로 가져옵니다.
클론을 정의하자면 다음과 같습니다.
1. 내가 생성한 원격 저장소를 내컴퓨터와 연결해서 데이터를 복사하는 작업.
2. 포크한 원격 저장소를 내 컴퓨터와 연결해서 데이터를 복사하는 작업.
앞선 포스팅에서 만들었던 http 주소를 가져옵니다.
그리고 앞서 블로그에서 설치했던 GIT BASH를 실행 해주십다.
$ mkdir git_remote
$ cd git_remote
그리고 clone 명령을 해서 땡겨옵니다.
$ git clone https://github.com/pjh2174/myTistoryExam.git
$ cd myTistoryExam
$ git status
status 명령을 치면, 현재 아무것도 커밋되어있지않고, clean한 디렉토리임을 알 수 있습니다.
Git remote: 로컬저장소와 원격저장소를 연결합니다.
앞부분에선 cloen을 통해 생성했던 원격저장소를 로컬저장소로 파일을 복사했습니다. 하지만 뭔가 모순된점이 있을 수 도 있는데요.
만약 유저가 이미 로컬에서 작업했던 내용이 있는 상태였다면, 원격저장소에있는걸 clone할필요없이 바로 연결해서 올려야하는 절차가 필요할 수도있습니니다. 그렇기때문에 일단 깃허브에서 원격 저장소를 임의로 생성해봅니다.
$ git remote add origin https://github.com/pjh2174/myRemoteExam.git
저는 이전블로그에 hello.py 가있는 브랜치로 접근하여 위의 명령어를 쳤습니다.
원격 저장소와 연결되었는지 호가인하려면 아래와 같이 명령을 치도록합니다.
$ git remote -v
git push: 로컬 작업 내역을 원격 저장소에 올립니다.
이제 원격저장소와 로컬 저장소가 연결되었습니다. 이젠 원격저장소에 자신의 결과물을 업로드 해야할 차례입니다. git push라는 명령어를 사용하면 수월하게 진행하실 수 있습니다.
$git push
음 거절당하게 될겁니다. 어느 원격 저장소로 발행할 것인지, 로컬의 어느 브랜치에 푸시할 것인지 명시하지 않았기 때문입니다.
$git push origin --all
명령어를 자세히 분석해보겠습니다.
$ git push 원격저장소별칭 로컬브랜치이름
위에서 실행한 -all은 origin 저장소에 로컬의 모든 브랜치를 푸시하는겁니다. git은 원격 저장소에 로컬 저장소의 브랜치와 같은 이름의 브랜치가 있다면 해당 브랜치를 변경하고 없다면 새브랜치를 원격 저장소에 만듭니다. 단 주의할점은, 같은 이름의 브랜치가 있는데 서로의 내역이 다르다면 푸시를 거부하게 됩니다.
아무튼 명령을 수행하면 깃허브 로그인창이뜨게되고, 아이디와 비번을 입력합니다. 성공적으로 업로드가 수행되어집니다.
성공적으로 올라온것을 확인하실 수 있습니다.
원격저장소에 파일을 하나 추가한후 다시 내용을 푸시해보도록하겠습니다.
$ cat >> README.md
remote repository of myRemoteExam
$ git add README.md
$ git commit -m "remote repository add a README.md files"
자 다시한번 push해보겠습니다. 원격저장소 별칭(origin)과 master 브랜치에 push push 해보겠습니다.
$ git push origin master
역시 깃허브에 반영된것을 확인하실 수 있습니다. 추가된모습을 보실수 있으세요.
혹은 README.md 파일을 다른 브랜치에도 추가하고 싶다면, 로컬저장소에서 git push origin master 명령을 실행하기전에
로컬 저장소를 병합한 후, git push origin -all 형태로 명령을 실행하셔도 됩니다.
.
git fetch와 git pull: 원격저장소와 로컬 저장소의 간격 메꿉니다.
원격 저장소의 commit내역들을 Local 저장소로 가져와 병합하는 방법은 git fetch와 git pull 크게 두가지가 있습니다.
git pull 명령은 원격 저장소의 정보를 가져오면 자동으로 로컬 브랜치에 병합까지 수행하는 것입니다. 자동으로 병합되기때문에 어떤 점들이 변했는지 알아보기가 힘들 수 있습니다. 그러므로 git fetch를 사용하길 권고합니다.
git fetch와 git pull을 이용해보기위해 실습순서를 아래와 같이 진행할 것입니다.
1. 원격저장소, github에서 파일 수정합니다.
2. 로컬저장소에서도 같은파일 수정합니다.
3. push 시도와 실패합니다.
4. fetch 실시합니다.
5. 병합시도합니다.
6. 푸시 재시도를 할것입니다.
7. 원격저장소에서 제대로되었는지 확인할 것입니다.
github로 가서, hello.py 파일을 변경합니다. (원격저장소에서 commit 한다는 의미입니다.)
자이제 로컬저장소에서도 hello.py를 수정해봅시다.
그리고 아래와 같이 로컬에서 커밋해버립니다.
$ git commit -a -m "hello.py modified in local"
그리고 push를 원격저장소에 해봅니다.
$ git push origin master master 로컬 브랜치의 내용을 origin 원격저장소에 push하겠다.
하지만 오류를 내면서 git pull 명령을 힌트로 알려줍니다만 별로 유용하지않습니다.
우리는 git fetch를 사용할것입니다.
$ git fetch
$ git status
뭐 큰이상 없는것같습니다.
$ git branch -a
위의 명령을 치면 현재 어떤 브랜치가 있는지 알 수 있습니다. 모든 로컬저장소와 원격 저장소의 브랜치정보를 볼 수 있습니다.
$ git merge origin/master
위의 명령을 치면, 충돌이 발생했다고 출력합니다.
이제 충돌을 해결해봅시다.
git diff 브랜치이름 명령을 이용해봅시다. git diff는 로컬저장소의 브랜치와 원격 브랜치 저장소 사이에 어떤 차이점이 있는지 미리 알아보는 명령입니다.
만약 git pull명령을 이용했다면 페치와 병합을 자동으로 수행해버려서 어떤 변경사항이있는지 알기가 매우어려워집니다.
그리고 이제 로컬에서 원하는 방향으로 다시 수정해봅시다. conflict을 해결하는 방향으로요!.
그리고 다음 명령과 같이 커밋합니다.
$ git commit -a -m "conflict resolved github"
$ git push origin master
이제 제대로 병합된것을 확인하실수있습니다.
또한, insights -> graphs -> Network를 누르시면, 지금까지 작업과정을 확인하실 수 있습니다.
만약 위의 과정에서 git pull origin master 이런식으로 명령어를 쳤다면, 변경내용을 가져오고 자동으로 병합해버립니다. 그러므로 그상태에서 git commit 과 git merge명령을 실행해도 이미 작업할 것이 없다는 메세지를 확인하실 수 있습니다.
추천드리자면, fetch를 통해 원격저장소의 커밋을 가져오고 로컬저장소에서 이를 확인한 다음 수동으로 병합하는 방법을 가장 추천드립니다.
'개발 Support > GIT' 카테고리의 다른 글
git revert, reset, checkout head -- filename (0) | 2017.07.15 |
---|---|
Git 명령어, 태그(tag) 붙이기, 마지막 커밋(commit) 수정하기 (0) | 2017.07.15 |
원격저장소와 GitHub (0) | 2017.07.09 |
로컬 저장소 git 기본 및 실습 (1) | 2017.07.09 |
윈도우 GIT 설치 (0) | 2017.07.08 |