위시랜이 해보니

서버(원격) 저장소로 전송(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..

충돌(Conflict) 해결하기 지난 포스팅에서 충돌이 발생하는 상황을 만들어 봤습니다. [Git_32] 충돌(Conflict) - 충돌이란? & 충돌 상황 만들기 개요(충돌 이란?) 지금까지 Git의 기본적인 사항은 대부분 확인을 해봤습니다. 하지만, 이 외에도 아직도 많은 기능들이 있습니다. 많은 기능들이라기보다 실제 우리가 협업을 하다 보면 발생할 wishlan.tistory.com 이렇듯 충돌이 발생하면 결국 직접 코드를 보고 hotfix에서 수정한 개발자와 master에서 수정한 개발자가 함께 살펴보면서 수동으로 해결해야 합니다. 충돌이 발생한 파일을 열어보면 충돌이 발생한 지점에 Git은 충돌된 코드의 내용을 기호를 포함해 표시해 주고 있습니다. 충돌이 발생한 fileb.html을 열어보면 다..

개요(충돌 이란?) 지금까지 Git의 기본적인 사항은 대부분 확인을 해봤습니다. 하지만, 이 외에도 아직도 많은 기능들이 있습니다. 많은 기능들이라기보다 실제 우리가 협업을 하다 보면 발생할 수 있는 상황들이 다양합니다. 아직도 많은 기능들이 있다는 것은 어찌 보면 우리가 겪을 수 있는 다양한 상황을 해결하기 위해 필요한 것들이라 할 수 있습니다. 우리가 겪을 수 있는 다양한 상황들 중에 대표적인 것이 충돌(Conflict)이 발생하는 경우라 할 수 있겠습니다. 대부분의 충돌은 같은 소스의 같은 위치를 수정한 것이 그 원인인 경우가 많습니다. 앞서 병합(merge)를 실행했을 때도 병합을 문제없이 실행된 결과를 보기 위해서 이러한 경우가 발생하지 않도록 했기에 정상적으로 병합이 잘 이뤄졌습니다. 하지만,..

브랜치(Branch) 삭제 브랜치를 병합한 후에는 병합한 브랜치를 일반적으로 삭제합니다. 앞서도 보셨지만 master도 수정되었는데, 3-way방식으로 병합 후에는 testbranch1에는 master가 수정한 사항은 반영이 되어 있지 않습니다. 그래서 추후 혼선을 없애기 위해서 병합한 후에 브랜치는 삭제하는 것이 일반적입니다. 삭제 후 필요하다면 다시 브랜치를 생성하는 것이 낫습니다. 브랜치 삭제 방법은 branch 명령어에 -d 옵션을 사용합니다. 사용법은 다음과 같습니다. # 브랜치 삭제하기 $ git branch -d 브랜치를 삭제해 보겠습니다. $ git branch -d testbranch1을 실행한 결과는 다음과 같습니다. 정상적으로 삭제되었다면 “Deleted branch testbranc..

브랜치(Branch) 병합(Merge) 브랜치를 사용하는 것은 안정적인 코드에 영향을 주지 않고 분리해 개발을 하기 위해서입니다. 버전 관리 시스템을 어떻게 운용하느냐에 따라 목적이 다를 수 있겠지만, 보통은 다음과 같이 운용합니다. master 브랜치엔 안정된 버전의 소스를 둡니다. 안정된 버전의 소스라는 것은 실제 서비스에 적용되어 있는 버전과 동일한 버전의 소스를 얘기합니다. 그래서 실제 서비스에 배포했거나 배포할 코드만 master 브랜치에 둡니다. 그리고 추가 작업들은 브랜치를 만들어서 진행하고, 테스트까지 완료되면, master와 합치게 됩니다. master와 합친 후 최종 테스트를 거쳐서 실제 서비스에 적용하게 됩니다. 이렇게 생성한 브랜치를 다른 브랜치와 합치는 작업을 병합이라고 합니다. ..