일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- Hot Publisher
- Cold Publisher
- RxJava
- 파이썬
- flab
- OS
- 버전관리
- Observable
- Depromeet
- CLI
- CPU Scheduling
- 큐시즘
- 원격 저장소
- github
- Git
- Round Robin
- Hot Publish
- js
- 마블 다이어그램
- spring boot
- 생활코딩
- OOAD
- 에프랩
- time slice
- js 개발자라면 알아야하는 핵심 컨셉
- 자바스크립트
- 건국대학교
- 디프만
- spring
- 멘토링 후기
- Today
- Total
글쓰는 개발자
[Git]Git-CLI 백업 with 생활코딩 - 5.Pull 본문
어느덧 github을 통해 하나의 repository를 업로드하고, 그것을 다른 환경에서 동일하게 동기화하는
작업의 막바지에 다다랐다.
이전 포스팅에서, git clone 명령어를 통해 저장소를 다른 PC에 복제해보았다.
복제된 저장소는 다음과 같이 구성될 것이다.
즉 현재 맨 위의 세 개의 저장소가 모두 동일한 파일 구성을 가지게 되는 것이다.
이제 다른 PC에서도 저장소의 내용을 내려받아 수정할 수 있는 상태가 되었다.
복제된 저장소에서 한참 작업을 하여, 작업 내용을 File4.txt에 저장했다.
Repository의 내용이 변경되었으므로, git status를 통해 working tree를 확인하면 File4가 untracked 상태일 것이다.
이전과 동일한 방식으로, Local Repository에서 먼저 commit하고, 원격 저장소로 push를 해주면 다음과 같은 상황이 될 것이다.
이제 복제된 저장소가 위치한 PC는 종료하여도 상관이 없다. 위의 그림처럼 Remote Repository가 각 Local Repository의 연결점 역할을 하기 때문이다.
다시 원본 저장소가 위치한 PC의 전원을 켜서, Remote Repository의 내용을 내려받기만 하면 복제된 저장소와 동일한
작업 내역에서 다시 작업을 시작할 수 있다.
이때 Remote Repository의 구성을 현재 내가 사용하는 저장소에 내려받을 수 있는 명령어 중 하나가 pull이다.
실행해보자.
내용을 잘 보면 File4.txt를 내려받고 있음을 알 수 있다. 저장소를 확인해보자.
File4를 원격 저장소로부터 성공적으로 받아왔으므로, 다음과 같은 상태가 되었다.
기본적인 git의 동작 방식은 위와 같다. Remote Repository를 가운데 두고, 원하는 위치에 복제한 후에
변경 내역을 push/pull하며 여기저기서 동기화하여 사용하는 형식이다.
사실 pull의 내부 동작을 살펴보면, 앞선 포스팅에서의 clone과 같이 몇개의 preset으로 구성된 명령어들이
한꺼번에 작동되는 형식이다. 이것에 대해서는 git pull vs fetch를 참고하길 바란다.
출처
이로써 기본적인 push/pull을 통한 원격 저장소 사용에 대한 포스팅은 마무리되었다.
그런데, 이러한 기능들을 단지 파일을 동기화하는 목적으로만 사용하기에는 좀 아까운 느낌이 있다.
사실 이렇게만 쓸거라면 구글 클라우드나 네이버 클라우드와 차별점이 크게 없어 보이기도 한다.
git을 조금 더 잘 활용하면, 여러 대의 PC를 소유한 여러 명의 작업자들이 동시에 원격 저장소와 통신하며 협업하는 환경을 구축할 수 있다.
다시 말해서 누군가 일일히 코드를 파일로 넘겨받아 ctrl+c ctrl+v하지 않고, 각자가 따로 개발한 코드를 합병된 코드로 묶어 '버전'으로 관리할 수가 있게 된다는 말이다.
이것은 개발자들의 생산성을 비약적으로 향상시킬 수 있는 크리티컬한 도구가 된다.
하지만 늘 새로운 시스템을 도입하는 것은 trade off가 존재하기 마련이다.
git에서 비롯되는 대부분의 문제 또한 협업하는 과정에서 발생한다. 잘 활용하는게 복잡하기도 하고.
행여나 명령어를 잘 숙지하지 못하면 코드 전체를 날려먹을 수도 있는 위험이 있다.
그럼에도 불구하고 그것이 가져다주는 이익이 다른 모든 것들을 무시할만큼 대단히 크기에, git을 통한 협업 과정은
현시대 개발자들의 필수 요소로 자리잡았다. 다음 포스팅부터는, git을 통해 어떠한 방식으로 개발자들이 협업할 수 있는지 알아보겠다.
'Development > Software Engineering' 카테고리의 다른 글
[협업]개발 학생의 협업 도전기 #2-1.객체지향 개발 방법론(OOAD) : OOP, UP (2) | 2020.07.05 |
---|---|
[협업]개발 학생의 협업 도전기 #1.체계적인 프로젝트 관리 및 문서화 (0) | 2020.03.03 |
[Git]Git-CLI 백업 with 생활코딩 - 4.Clone (0) | 2019.06.23 |
[Git]Git-CLI 백업 with 생활코딩 - 3.push (0) | 2019.06.12 |
[Git]Git-CLI 백업 with 생활코딩 - 2.원격 저장소 연결하기 (0) | 2019.06.09 |