일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 29 | 30 |
- Version
- ViewModel
- programmers
- library
- homebrew
- github
- androidstudio
- livedata
- Kotlin
- Jetpack
- ReactiveProgramming
- Room
- leetcode
- sourcetree
- Android
- git
- rxjava
- Database
- Java8
- IntelliJ
- Algorithm
- FRAGMENT
- Java
- Today
- Total
목록git (15)
Learn & Run
목표 Tag가 언제 쓰이는지, 어떻게 쓰이는지에 대해서 알아보도록 합니다. Tag를 생각해보면 무엇인가를 설명해준다는 느낌을 받을 수 있습니다. 예를 들면 어떤 물건이 있을 때 이 물건이 어떤 것인지를 간단하게 또는 자세하게 설명해주는 것이 Tag의 목적이라고 할 수 있습니다. 수많은 버전들이 존재할 때 각 버전들 중에서도 의미있는 버전들이 있을 수 있습니다. 버전관리 시스템에서 Tag는 기록할만한, 기념할만한 버전이 있을 때 기록해주는 기능을 하고 있습니다. 1. Tag를 추가하는 방법에 대해 알아보도록 합니다. 2. 새로운 브랜치를 만들 때 특정한 Tag가 있는 버전으로부터 시작하는 방법을 알아보도록 합니다. 3. 로컬 저장소의 Tag를 원격 저장소에 Push 하기
목표 Stash가 무엇인지 그리고 어떤 기능을 하는지에 대해 알아보도록 합니다. 우리는 종종 어떤 일을 하는 도중에 급한 개선 건에 대한 처리를 요구받을 때가 있습니다. 또한 다른 기능에 대한 버그가 발생하여 하던것을 제쳐두고 그것을 우선적으로 해결하고 싶을때가 있습니다. 이런 경우에 쓰이는 기능에 Stash라는 기능입니다. 1. Stash가 의미하는 것이 무엇인지 알아보도록 합니다. 2. Stash가 쓰이는 구체적인 상황을 예로 들어보겠습니다. 3. Stash를 사용하면서 주의해야할 점이 무엇이 있는지 알아봅니다. Staged files, Unstaged files 둘 다 공존할 때 어떤식으로 Stash에 저장되는지 알아보도록 합니다. Stash file이 포함하고 있는 작업을 변경했을 때 일어나는 충..
목표 Git 명령어 Pull과 Push에 대해 알아보도록 합니다. 이전 포스팅까지 우리는 지금까지 Push라는 작업을 해왔습니다. 그렇다면 Pull은 무엇을 의미할까요? 영어가 의미하는 그대로입니다. Push가 로컬 저장소에서 원격 저장소로 버전을 업로드하는 과정이였다면 Pull은 반대로 원격 저장소에 관리되던 버전을 로컬 저장소로 가져오는 행위를 의미합니다. 1. 우선 두개의 로컬 저장소를 준비해둡니다. 저는 test와 test2 총 두개의 로컬 저장소를 준비해두었습니다. 실제 협업 환경을 위한 구성이라고 생각하시면 좋습니다. 2. test 로컬 저장소에서 Push를 통해 원격 저장소의 버전을 업데이트 합니다. 간단하게 파일을 변경하고 Commit 후에 Push까지 완료합니다. 2. 여기서 test2 ..
목표 저장소를 복제하는 방법에 대해 알아보도록 합니다. 회사에 새로운 직원이 들어왔고, 그 직원은 진행중인 프로젝트를 불러와야한다고 생각해봅니다. 어떻게 가져올까요? 바로, 원격 저장소에 저장되어있는 프로젝트를 로컬 저장소로 불러와야 합니다. 이 때 사용하는 개념이 Clone(복제) 입니다. 1. 로컬 저장소로 택할 폴더를 하나 만들어 줍니다. 저는 바탕화면에 test라는 폴더를 하나 생성해 두었습니다. 2. 아래와 같은 과정을 통해 복제할 test 폴더를 지정해줍니다. 3. test폴더에 복제가 잘 되었는지 확인합니다.
목표 - 원격 저장소를 사용하는 목적에 대해 알아보도록 합니다. - 이 포스팅을 참고하여 오픈 소스 프로젝트를 진행해 보도록 합니다. 로컬에서 큰 프로젝트를 하고 있다고 가정해 봅시다. 하지만 어느 날, 프로젝트를 진행하고 있는 PC가 고장났다던지 의도치 않은 사고로 PC가 부셔졌다던지 다양한 상황이 일어날 수 있습니다. 이러한 상황에 대비하기 위해서 우리는 로컬에 있는 소스 코드를 로컬이 아닌 다른 서버에 저장시켜 놓을 필요성을 느낄 수 있습니다. Git의 세계에서는 여러가지 원격 저장소를 제공하는 서비스들이 있는데, 그중에서 가장 일반적이고 보편적으로 사용하는 것은 Github이라는 서비스입니다. 원격 저장소 뿐만 아니라 사람들이 협업을 하기 위한 다양한 서비스를 제공하기도 합니다. 1. Github..
목표 충돌이란 무엇이고, 어떻게 해결하고, 어떻게 효율적으로 충돌을 피할 수 있고, 예방적인 차원에서 충돌이 덜 일어나게 할 수 있는가에 대해 알아보도록합니다. 브랜치를 나누었을 때, 각자 작업을 할 상황이 생깁니다. 하지만, 서로 같은 곳을 수정했을 경우 버전 관리 프로그램이 자동으로 병합할 수 없을 때 사용자에게 해결방법을 위임하는 경우가 종종 발생합니다. 1. 새로운 브랜치 test2를 추가하기 충돌을 실험하기 위해, 브랜치를 추가해주도록 합니다. 2. 새로 만든 브랜치에서 텍스트 파일 내용 수정하기 master 브랜치의 파일내의 텍스트 파일 내용도 동일하게 변경할 것 입니다. 저는 7번째 줄에 동일하게 작업을 해주도록 하였습니다. 3. master 브랜치로 이동후에 텍스트 내용 변경하기 test2..
목표 이전 포스팅에서 Branch를 왜 사용하여야 하는지와 사용했을 때 어떠한 이점이 있는지 확인해 보았습니다. 이번 포스팅에서는 나눠진 브랜치를 병합해 보도록 합니다. 1. master 브랜치를 더블클릭합니다. (Checkout 한다고 말하는 것과 동일합니다) 2. 현재 master 브랜치가 Checkout된 상태입니다. 가지고 오려는 브랜치는 test 브랜치이기 때문에 test 브랜치에서 우클릭하여 Merge test into master를 클릭합니다. 3. 병합(Merge)후 버전을 확인합니다. 아래와 같이 master 브랜치로 Merge branch 'test'라는 메시지로 Commit된 것을 확인할 수 있습니다. 이번 포스팅을 통해서 파일을 Copy하고 각각 다른 작업을 한 후에 Copy된 파일..
목표 이번 포스팅에서는 Git에서의 브랜치(Branch)의 용어를 이해해보고 사용 이유에 대해서 알아보도록 합니다. 하나의 버전안에서 안정적인 작업과 안정적이지 않은 작업을 동시에 진행하는 도중에, 미래가 불분명하거나 되돌리고 싶은 부분에 대해서 Reset과 Revert을 이용하고 싶은 충동이 들 수 있습니다. 하지만, 생각보다 쉬운 상황은 아닙니다. 프로젝트가 거대해지고 관리하는 파일들이 많다는 가정하에 우리가 되돌리고 싶은 부분만을 오려내는 작업을 하는 것은 쉽지 않습니다. 해결책으로 같은 버전의 프로젝트를 복사하여 안정적인 작업과 안정적이지 않은 작업을 분리해서 하는 것이 좋지 않을까하는 생각이 들 수도 있습니다. 결국, 원본과 카피된 프로젝트에 각각 하고자했던 일들을 잘 마무리 했다고 가정해봅시다..
목표 이전 포스팅에서 다룬 Reset과 마찬가지로 삭제할 때 사용하는 Revert를 사용해보며 이해해보도록 합니다. 1. Revert를 사용하기 전에 다음과 같이 버전들을 준비하기 아래 그림은 Revert했을 때 어떤 것이 달라지는지 확인하기 위한 준비 과정입니다. 2. 최종 Commit에서 Revert하기 Revert하기 위한 방법은 아래 그림과 같습니다. 3. Add First 버전으로 돌아가보기 주의할 점으로는 어떤 특정한 버전으로 돌아가기 위해서 그 중간의 버전들을 스킵하여 Revert를 하게되면 Complict가 발생하기 때문에 순차적으로 취소하길 권장합니다. 아래의 그림들을 통해 순차적으로 취소하는 과정임을 확인합니다. 3. Reset과 Revert 다시 한 번 이해하기 Reset은 선택된 버..
목표 이미 Commit한 버전을 취소해보는 방법을 알아보도록 합니다. 또한 취소할 때의 다양한 옵션이 어떤 차이가 있는지 이해해보도록 합니다. 1. 현재 선택된 버전 이후의 버전, Index, Working Copy 모두 삭제하기 (Hard - discard all working copy changes) 최종 Commit으로 돌아가고 싶은 버전을 선택한 후 Reset버튼을 누른후 Hard옵션을 선택하여 삭제해보도록 합니다. 2. 현재 선택된 버전 이후의 버전과 Index는 삭제하고 Working Copy는 유지하기 (Mixed - keep working copy but reset index) 최종 Commit으로 돌아가고 싶은 버전을 선택한 후 Reset버튼을 누른후 Mixed옵션을 선택하여 삭제해보도록..