위시랜이 해보니

원격 브랜치의 이해 Git을 사용한 협업에서 서버 저장소에 대해 알아보았습니다. 우리는 브랜치를 공부하면서 브랜치를 만들고 병합하는 등의 작업을 통해 브랜치 운용을 어떻게 할 수 있는지 학습했습니다. Git으로 버전 관리를 하면서 master 브랜치는 안정적인 코드를 유지하는 브랜치로 하고 추가 작업을 진행할 때는 브랜치를 생성해 작업해서 배포 시 master 브랜치로 병합하는 방식으로 하는 것이 보통입니다. 이와 같이 브랜치 작업도 원격 브랜치를 두고 협업을 할 수 있습니다. 로컬 저장소의 서버(원격) 저장소로 GitHub를 사용했듯이 서버(원격) 저장소에도 브랜치를 생성할 수 있으며, 서버(원격) 저장소에 생성한 브랜치를 원격 브랜치라고 합니다. 로컬에 Git 저장소를 만들었다고 서버에 저장소가 자동..

서버(원격) 저장소에서 내려받기 서버 저장소의 내용을 내려받는 방법은 크게 3가지가 있으며, 그 방법과 차이를 간략히 얘기하면 다음과 같습니다. Clone (클론) - 서버(원격) 저장소의 내용을 전부 그대로 로컬로 복제. Pull (풀) - 로컬 저장소와 다른 사항에 대해서만 내려받아 병합(merge)까지 수행함. Fetch (패치) - 로컬 저장소와 다른 사항에 대해서만 내려받고 병합(merge)은 하지 않음. ■ Fetch 서버 저장소의 내용을 내려받는 또 하나의 방법은 패치(fetch)가 있습니다. pull과 fetch의 차이점은 자동으로 병합(merge)까지 하느냐/하지 않느냐입니다. pull과 fetch는 실행하게 되면 Git의 임시 공간으로 내려받습니다. 내려받는 것까지는 두 명령어가 동일합..

서버(원격) 저장소에서 내려받기 서버 저장소의 내용을 내려받는 방법은 크게 3가지가 있으며, 그 방법과 차이를 간략히 얘기하면 다음과 같습니다. Clone (클론) - 서버(원격) 저장소의 내용을 전부 그대로 로컬로 복제. Pull (풀) - 로컬 저장소와 다른 사항에 대해서만 내려받아 병합(merge)까지 수행함. Fetch (패치) - 로컬 저장소와 다른 사항에 대해서만 내려받고 병합(merge)은 하지 않음. ■ Pull clone 이 서버 저장소를 그대로 복제하는 방식으로 내려받는 다면, 로컬 저장소와 다른 업데이트된 내용만을 로컬 저장소로 내려받을 필요가 있습니다. 이때 사용하는 명령어가 pull입니다. push가 서버로 업로드(전송) 하는 것이었다면, 반대로 서버 저장소의 업데이트된 내용을 로..

서버(원격) 저장소에서 내려받기 서버 저장소의 내용을 내려받는 방법은 크게 3가지가 있으며, 그 방법과 차이를 간략히 얘기하면 다음과 같습니다. Clone (클론) - 서버(원격) 저장소의 내용을 전부 그대로 로컬로 복제. Pull (풀) - 로컬 저장소와 다른 사항에 대해서만 내려받아 병합(merge)까지 수행함. Fetch (패치) - 로컬 저장소와 다른 사항에 대해서만 내려받고 병합(merge)은 하지 않음. ■ Clone 먼저, 서버(원격) 저장소의 내용을 전부 그대로 로컬로 복제할 수 있는 명령어로 clone이 있습니다. 앞서 서버(GitHub)에 저장소만 만들어 두고, push 명령어로 로컬 저장소의 내용을 처음으로 서버(원격) 저장소로 전송하는 것이었다면, clone은 반대로 로컬에 아무것도..

서버(원격) 저장소로 전송(push) 할 때 유의할 점 아직 서버(원격) 저장소로부터 내려받는 방법 중 하나인 pull에 대해서 얘기하진 않았지만, 이전 포스팅에서 서버로 전송 시 오류 상황에 대해 얘기했었기에 정리 차원에서 미리 짚어두고자 합니다. [Git_43] 로컬 저장소의 커밋을 리셋(reset) 후 전송(push) 하기 로컬 저장소의 커밋을 리셋(reset) 후 전송(push) 하기 - 강제 전송 제목 그대로 로컬 저장소에서 작업하면서 실행했던 커밋을 리셋한 이후에 서버(원격) 저장소로 전송(push)하면 어떻게 될까요? 이 wishlan.tistory.com pull(내려받기)을 실행하면 서버 저장소의 내용을 로컬 저장소로 내려 받은 후 로컬 저장소의 내용과 병합(merge)이 자동으로 실행됩..

로컬 저장소의 커밋을 리셋(reset) 후 전송(push) 하기 - 강제 전송 제목 그대로 로컬 저장소에서 작업하면서 실행했던 커밋을 리셋한 이후에 서버(원격) 저장소로 전송(push)하면 어떻게 될까요? 이런 경우는 흔하진 않겠지만, 경험할 수 있는 경우이기에 언급하고자 합니다. 본 예를 통해 Push를 할 수 없는 상황과 서버 저장소를 이용할 경우 커밋에 대한 리셋(reset)과 리버트(revert)에 대해 한번쯤 생각해 보기 바랍니다. 실습을 통해 확인해 보겠습니다. [상황 1]부터 [상황 4]까지 차근차근 따라 해 보기 바랍니다. 지금까지 상태는 서버(원격) 저장소(remoterepo)와 로컬 저장소(remoterepo)를 연결한 상태입니다. 똑같이 master라는 브랜치 하나만을 가지고 있는 상..

서버(원격) 저장소 - 전송하기 (git push) push 위 그림에서도 알 수 있듯이 로컬 저장소의 커밋을 서버 저장소로 전송하는 명령어는 push를 사용합니다. 앞서 $ git remote -v 를 통해 등록된 서버 저장소의 정보를 확인하였습니다. 위 결과와 같이 연결된 원격(서버) 저장소 목록을 보면 origin이라는 서버 저장소 이름과 서버 저장소의 URL, 그리고 fetch와 push로 구분되어 확인이 됩니다. origin https://github.com/shiri0/remoterepo.git (push)와 같이 push가 가능한 서버 저장소가 등록된 것을 확인할 수 있습니다. push 명령은 다음과 같이 사용할 수 있습니다. # 로컬 저장소의 커밋을 서버 저장소로 전송하기 $ git pus..

서버(원격) 저장소 - 정보 삭제하기 (remote rm) 우리는 앞서 서버(원격) 저장소를 만들고 등록(로컬 저장소와 연결) 해 봤습니다. [Git_40] 서버(원격) 저장소 만들기, 서버(원격) 저장소 연결하기 (ft.GitHub-깃헙) GitHub 저장소 확인 앞서 우리는 GitHub에 회원가입을 하고 저장소까지 만들어 봤습니다. https://github.com 에 다시 접속해 보겠습니다. GitHub: Let’s build from here GitHub is where over 100 million developers shape the wishlan.tistory.com 로컬 저장소에는 서버 저장소를 여러 개 등록할 수 있습니다. 원격(서버) 저장소와 관련한 CLI 명령어는 remote 입니다...

GitHub 저장소 확인 앞서 우리는 GitHub에 회원가입을 하고 저장소까지 만들어 봤습니다. https://github.com 에 다시 접속해 보겠습니다. GitHub: Let’s build from here GitHub is where over 100 million developers shape the future of software, together. Contribute to the open source community, manage your Git repositories, review code like a pro, track bugs and fea... github.com 가입했던 정보로 로그인을 하면 다음과 같이 첫 화면 왼쪽 편에 자신이 만들었던 저장소 목록을 확인할 수 있습니다. 저장소..

서버(원격) 저장소 이해하기 지금까지 확인해 본 내용의 대부분은 Git의 기본에 초점을 맞췄습니다. 그리고 로컬 저장소를 기반으로 혼자서 작업을 할 경우에 해당한다고 할 수 있습니다. 이제는 다른 사람과 협업을 Git으로 어떻게 할 수 있는지를 살펴보고자 합니다. 협업을 위해서는 여러 사람이 함께 사용할 저장소가 반드시 필요합니다. 여러 사람이 함께 사용할 저장소이므로 공통의 저장소와 각각의 작업자의 PC는 인터넷으로 연결이 되어야 합니다. 사실 Git과 같은 버전 관리 시스템을 사용한다는 것은 혼자서 개발하기보다는 여러 사람과 협업을 하기 위해 사용한다고 봐야 합니다. 또는 혼자서 개발을 한다고 해도 Git을 사용하면 언제 어디서든 필요한 때에 내가 하던 작업을 이어서 할 수 있습니다. 바로 서버(원격..

스태시(stash) 상황 만들기 이제 스태시(stash)를 사용해 보기 위해 그럴만한 상황을 먼저 만들어 보겠습니다. [상황 1] 저장소를 만들고 세 번의 커밋 진행하기 일단 실습을 통해 어떻게 활용할 수 있는지 확인해 보겠습니다. 새로운 폴더 stashrepo 를 만듭니다. $ git init 를 통해 Git 초기화합니다. index.html 파일을 만듭니다. 세 번의 커밋을 진행합니다. 그 결과를 소스트리를 통해 확인한 결과는 다음과 같습니다. * index.html 파일 최종 내용 위 master 내용이 실제 서비스 중인 안정적인 코드라고 가정해 보겠습니다. [상황 2] hotfix 브랜치 만들고 두 번의 커밋 진행하기 이제 새로운 작업을 위해 hotfix 브랜치를 만들고, 수정 작업을 진행합니다...

스태시(Stash) - 개념 처음 학습을 시작하면서 실습을 위해 만들었던 저장소를 다음의 그림을 보면서 상기해 보겠습니다. firstrepo라는 폴더를 만들고 $ git init 를 통해 Git을 초기화함으로 해서 firstrepo 폴더가 Git을 통한 버전관리 영역으로 만들었습니다. 이렇게 만든 Git 영역은 기본이 되는 master 브랜치라는 작업자가 생기게 되고, master를 포함해 추가로 가지가 뻗어 나가듯이 hotfix 브랜치와 bugfix 브랜치를 만들 수 있습니다. 이렇게 만들어진 Git영역(firstrepo 폴더)에서 작업하는 소스들은 워킹 디렉토리에서 작업이 이뤄지는 것이 되고, 스테이지 영역을 통해 커밋할 인덱스를 구성하고, 이렇게 스테이지 영역에 구성한 소스들은 커밋을 통해 저장소에..

리베이스(rebase)로 커밋(commit) 수정하기 리베이스로 커밋 정보를 수정할 수 있습니다. -i 옵션을 이용하는 것이며, 사용법은 다음과 같습니다. # 의 HEAD 커밋으로 리베이스 하기 $ git rebase -i 는 HEAD 포인터를 활용합니다. 가령, 현재 커밋의 이전 커밋, 다시 말해 바로 앞의 커밋 정보를 수정하려면 $ git rebase -i HEAD~라고 입력하면 되겠습니다. -i 옵션은 부터 최근 커밋까지 묶어서 수정 처리할 수 있습니다. 가령, $ git rebase -i HEAD~2라고 하면 이전 커밋 2개를 한 번에 수정할 수 있습니다. 다음은 $ git rebase -i HEAD~2 를 실행한 후의 화면입니다. 맨 상단 두줄에 pick 으로 시작하는 부분을 볼 수 있을 텐데요..

리베이스(rebase) Git에서 브랜치를 생성하고 병합하고, 그 과정에 충돌이 발생했을 때 해결하는 부분들을 학습했습니다. 우리는 브랜치를 다른 브랜치와 합칠 때 병합(merge)을 사용했었습니다. 그런데 Git에서 브랜치를 합치는 방법으로 리베이스(rebase)가 있습니다. 이 리베이스는 커밋의 배치를 조절해서 병합한 결과를 만들어 낸다고 할 수 있습니다. 리베이스(rebase) 이해하기 지난 시간에 리베이스(rebase)를 무작정 사용해 봤습니다. 그럼, 지금까지 실행해 본 리베이스를 되짚어 보겠습니다. 결과적으로 보더라도 리베이스라는 것은 베이스(base)가 되는 커밋을 재(re, 다시) 설정한다는 의미라고 이해할 수 있습니다. 리베이스(rebase) 실행 전의 커밋 이력이 다음과 같았습니다. 여..

리베이스(rebase) Git에서 브랜치를 생성하고 병합하고, 그 과정에 충돌이 발생했을 때 해결하는 부분들을 학습했습니다. 우리는 브랜치를 다른 브랜치와 합칠 때 병합(merge)을 사용했었습니다. 그런데 Git에서 브랜치를 합치는 방법으로 리베이스(rebase)가 있습니다. 이 리베이스는 커밋의 배치를 조절해서 병합한 결과를 만들어 낸다고 할 수 있습니다. 무작정 따라 해 보기 일단 무작정 리베이스를 한번 해보도록 하겠습니다. 다시 실습을 위해 master와 hotfix 브랜치를 commit 5 지점으로 되돌려서 다음의 상태로 만들었습니다. 현재 상태를 그림으로 나타내면 다음과 같습니다. 여기서 hotfix 브랜치에서 filea.html 파일을 수정해 한 번 커밋하고, master 브랜치에서 file..