nemo's dev memos

보호되어 있는 글입니다.

보호되어 있는 글입니다.

Git 에서 특정 한 브랜치에서 다른 브랜치로 합치는 방법으로는 두 가지가 있다. #1) Merge #2) Rebase - Rebase를 하든지, Merge를 하든지 "최종 결과물은 같고 커밋 히스토리만 다르다는 것이 중요하다!! #1 Merge - $git merge 명령어를 사용 - Merge 의 경우, 두 브랜치의 최종결과만을 가지고 합친다. - 이외 Merge는 브랜치 포스팅 참조 - [Merge 과정] * 아직 커밋하지 않은 파일이 Checkout 할 브랜치와 충돌 나면 브랜치를 변경할 수 없으므로 워킹 디렉토리 정리 후 Merge작업을 시작한다. 1) $ git checkout : 다른 브랜치(B) 내용을 병합할 브랜치(A)로 이동 2) $ git merge : 다른 브랜치(B)를 병합할 브랜..

Remote 저장소에 '로컬 수정사항/로컬 브랜치' 올리기 : $ git push : 로컬의 브랜치(LocalBranchName)를 Remote 서버로 전송 - 로컬의 브랜치를 서버로 전송하려면 쓰기 권한이 있는 리모트 저장소에 Push 해야 한다. - $ git commit 과 $git push 비교 : Git은 local repository가 있기 때문에, Git 에서의 commit은 local repository에 저장되는것을 의미하고, 이 커밋사항을 Git remote repository에 저장하려면 push를 해주어야 한다. 1. 로컬 브랜치의 이름과 리모트 서버의 브랜치 이름이 다를 때 : $ git push origin : - 리모트 저장소에 로컬의 브랜치(LocalBranchName) 이름..

리모트 Refs (Remote References) 일단, "Refs"란?? - Git은 모든 'history'를 'Key-Value format'으로 관리한다. ㄴ> 'Key'는 'SHA-1로 만들어진 40자리 해시값'이나 이를 기억하기 어렵기 때문에 "쉬운 이름의 파일"에 해시값이 저장한다. 이런 파일들을 "References"라고 하며, 약자로 "Refs"라고한다. - Git에서 "Refs"는 '.git/refs'에 저장된다. ㄴ> '.git/refs/heads' 디렉토리 내에는 main와 branch파일들이 있다. - Git에서 "어떤 특정한 작업을 가르키는 Refs"를 "branch"라고 한다. 리모트 Refs (Remote references) 란? : 리모트 저장소에 있는 포인터인 레퍼런스...

workflow에 따라 Git의 브랜치를 2개로 나누어 살펴볼 수 있다. 1. Long-Running 브랜치 : 개발을 진행하고 안정화할 브랜치를 추가 후 안정화가 됐을 때 '안정 브랜치(ex 'main 브랜치')'로 Merge할 브랜치 = 즉, main 브랜치에 merge되지 않은 활성화되어 있는 개발용 브랜치 - 이 브랜치는 언젠가 안정 상태가 되겠지만, 항상 안정 상태를 유지해야 하는 것이 아니며, 테스트를 거쳐서 안정적이라고 판단되면 main 브랜치에 Merge 한다▼ 즉, 배포했거나 배포할 코드만 main 브랜치에 Merge 해서 안정 버전의 코드만 main 브랜치에 둔다. - ex) 토픽 브랜치(앞서 살펴본 addQnA 브랜치 같은 짧은 호흡 브랜치)에도 적용할 수 있는데, 해당 토픽을 처리하..

충돌(CONFLICT)의 기초 "충돌(CONFLICT)이 발생했다" = Merge하는 두 브랜치에서 같은 파일의 한 부분을 동시에 수정하고 Merge하면, Git은 해당 부분을 Merge 하지 못하는(=Merge가 실패) 경우 "충돌이 발생"했다고 말한다. - 충돌이 발생하면 $ git merge 명령어에서 아래와 같은 충돌 메시지 출력한다. $ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. - 3-Way Merge 시 충돌이 발생하면 Merge 하지 못하므로 Merge 커밋이..

브랜치 삭제 : $ git branch -d - 해당 브랜치를 삭제한다. 특정 브랜치 생성해 작업 후 이를 다른 브랜치로 병합(=합치기=merge)해야할 때 '브랜치 병합'이 필요하다. 브랜치 병합(=merge=합치기=머지) : ① $ git checkout 명령 후, ② $ git merge 명령 실행한다! - ① 다른 브랜치(B) 내용을 병합할 브랜치(A)로 이동 후 (checkout), ② 다른 브랜치(B)를 병합할 브랜치(A)에 합친다. (merge) $ git checkout A $ git merge B - ※ ① 주의) "아직 커밋하지 않은 파일이 Checkout 할 브랜치와 충돌 나면 브랜치를 변경할 수 없다." 이렇게 말해도 이해 잘 안 간다. 일단 예제를 보는 게 더 이해가 쉽다! Exa..

그림을 그려서 넣고 싶은데 계속 손으로 만든 발그림이 나온다...ㅠㅠ Android Studio가 지원하는 커밋 되돌리기 방법 3가지 1) 'Undo Commit...' 2) 'Revert Commit' 3) 'Reset Current Branch to Here' ※ Undo, Rever, Reset 모두 로컬 커밋만 복원되므로 로컬 복원사항을 'Push하지 않는 이상' 원격 브랜치와 히스토리에는 변화없다. ※ 이미 원격에 Push한 커밋사항은 항상 Revert로 되돌려야 한다. ( ∵ Reset 적용 상태에선 push가 안되며 강제옵션있으나 위험함!! 다른 사람 작업환경이 꼬일 수도 있다 ㄷㄷ) [↓ 하기 ⓑ' 적용 방법 공통 부분] : 모두 스튜디오 하단 툴에서 'Git' 선택 > 'Git'툴 상단에..

ProGit를 찬찬히 따라 공부하는 것도 좋지만 하다보니 막상 사용해야하는 소스 파일, 브랜치 설정 및 충돌과 그 해결을 내가 임의로 만들어서라도 직접 경험해 봐야 한다는 생각이 들었다 (백문이불여일타'란 말처럼! 재미질 것 같은 사심도 있고:-)) 특히, 내가 사용하는 IDE인 Android Studio에서의 Git 사용은 GitPro에 없기에 내가 간단한 예제들이라도 만들어 시험해보고자 한다. 일단 Git Status를 테스타하는 예제부터~ Android Studio에서 프로젝트 파일들의 Git 상태 변경하기 Example Case) 아래와 같은 에러가 발생하며 원인과 대책은 아래와 같다. 아래 대책(ⓐ,ⓑ)을 작업하며 Android Studio에서 Git 상태 변경하고자 한다. - 원인 : '.gi..

브랜치 목록 : $ git branch - 로컬 저장소의 모든 브랜치 목록을 보여준다. ('*' 표시가 붙은 것이 현재 작업하는 브랜치) - ex1) 커니코틀린 샘플예제 브랜치를 clone해 온 로컬에서 'java' 브랜치 생성한 경우 $ git branch * java master - '-a' 옵션 : 원격 브랜치를 포함한 모든 브랜치 목록을 확인 $ git branch -a ㄴ> ex2) ex1에서 커니코틀린 샘플예제의 원격 브랜치까지 모두 조회 시 $ git branch -a * java master remotes/origin/HEAD -> origin/master remotes/origin/arch-components-lifecycle remotes/origin/arch-components-roo..

Git 브랜치(Branch) 란? - 개발할 때에 여러 사람이 동일한 소스코드를 기반으로 서로 다른 작업을 할 때에는 각각 다른 버전의 코드가 만들어 질 수 밖에 없는데 각각의 다른 버전의 코드를 지원하기 위해 '커밋 사이를 가볍게 이동할 수 있는 어떤 포인터' = '브랜치'를 사용한다. - Git에서는 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 어떤 작업을 진행하기 위한 것이 '브랜치' 즉, "'새로운 버전의 소스 코드'의 마지막 커밋을 가리키는 포인터 같은 것" - '포인터'적인 개념보다 "'새 버전의 소스 코드'를 전체를 일컫는 말"로 사용되는 것 같다~ - 커밋이 추가되면 같이 이동한다. (= 특정 버전 프로젝트(소스 코드)의 마지막..

Git의 저장소(Repository) 란? - 사전적 의미로 '저장소(Repository)'란? : 파일이나 폴더를 저장해 두는 곳 "Git의 저장소(Repository)" : Git이 관리하는 저장소 - 단순히 프로젝트나 소스 코드만이 아닌 다양한 버전과 "브랜치(Branch)"들이 존재 - 하위에 '.git' 디렉터리가 생성됨 - 파일을 수정, 커밋하고 프로젝트의 이력관리 및 공유 등 Git의 기능 사용 가능한 장소 - 파일이 변경 이력 별로 구분되어 저장된다. - [종류] : 원격 저장소와 로컬 저장소 두 종류이다. 1. 원격 저장소 (Remote Repository) : 원격 서버에서 있는 저장소 (여러 명이 공통으로 사용가능=협업) 2. 로컬 저장소 (Local Repository) : 만들었거..

보호되어 있는 글입니다.

Git Alias (= Git 별칭) : Git의 명령을 전부 입력하는 것이 귀찮다면 git config 를 사용하여 각 명령의 Alias을 만들어 사용할 수 있다. - 이미 있는 명령을 편리하고 새로운 명령으로 만들어 사용할 수 있다. - '!' 를 제일 앞에 추가하면 Git이 아닌 외부 명령어도 실행할 수 있다. ㄴ> 커스텀 스크립트를 만들어서 사용할 때 매우 유용 ㄴ> ex) git visual 이라고 입력하면 gitk 가 실행되도록 alias 설정하기 $ git config --global alias.visual '!gitk' Git Alias 만들기 : $ git config --global alias. ㄴ> ex1) $ git commit 대신 $ git ci 로 커밋할 수 있다. $ git ..

Git의 'Tag'(태그)란? : 커밋을 참조하기 쉽도록 알기 쉬운 이름을 붙이는 것을 말한다. - 보통 릴리즈할 때 사용한다 (v1.0, 등) - Git Repository를 clone 하거나 Pull을 하면 모든 태그 정보도 함께 가져온다. - 한 번 붙인 태그는 브랜치처럼 위치가 이동하지 않고 고정됩니다. 1. Tag 종류 : 일반 태그(Lightweight tag), 주석 태그(Annotated tag) 1. 일반 태그(Lightweight tag) : 특정 커밋에 대한 포인터 ㄴ> '태그명(=이름)'만 붙여 저장되는 태그 ㄴ> 파일에 커밋 체크섬을 저장하는 것뿐이다. 다른 정보는 저장하지 않는다. ㄴ> cf) '브랜치'와 비슷하지만 브랜치처럼 가리키는 지점을 최신 커밋으로 이동시키지 않는다. 2..

Git Repository란? (=원격 레포지토리, 리모트 저장소, 원격 저장소) : 인터넷이나 네트워크 어딘가에 있는 저장소를 말한다. ㄴ>※ 원격 저장소라 하더라도 로컬 시스템에 위치할 수도 있다. (사실 같은 로컬 시스템에 존재할 수도 있다.) 'remote' 라는 이름은 반드시 저장소가 네트워크나 인터넷을 통해 어딘가 멀리 떨어져 있어야만 한다는 것을 의미하지 않는다. 물론 일반적인 원격 저장소와 마찬가지로 Push, Pull 등의 기능은 동일하게 사용한다. - 다른 사람들과 함께 일한다는 것은 '리모트 저장소를 관리'하면서 데이터를 거기에 Push 하고 Pull 하는 것 ㄴ> '리모트 저장소를 관리'한다' : 저장소를 추가, 삭제하는 것뿐만 아니라 브랜치를 관리하고 추적할지 말지 등을 관리 내용..

※ Git은 커밋하지 않고 잃어버린 것은 절대로 되돌릴 수 없다. Git 되돌리기(Undo) : (재커밋, Staged->Unstaged, Modified->Unmodified) - ※ 매우 주의 ※ : 한 번 되돌리면 복구할 수 없기에 주의해야 한다. Git을 사용하면 우리가 저지른 실수는 대부분 복구할 수 있지만 되돌린 것은 복구할 수 없다. CASE1) 커밋 후 바로 재커밋하기 : $ git commit -amend ㄴ> 방금 커밋한 사항에 대해 바로 수정작업이 필요할 때, 수정작업을 하고 Staging Area에 추가 후 $ git commit --amend 명령을 사용하면 재커밋된다. ㄴ> 마지막으로 커밋하고 나서 수정한 것이 없다면(=커밋하자마자 바로 이 명령을 실행하는 경우) 이전에 한 커밋..

Git 히스토리 조회하기 : $ git log - 저장소의 커밋 히스토리를 시간순으로 보여준다. 즉, 가장 최근의 커밋이 가장 먼저 나온다. - 각 커밋의 SHA-1 체크섬, 브랜치, 저자 이름, 저자 이메일, 커밋한 날짜, 커밋 메시지를 보여준다. - Ex▼) $ git log commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon Date: Sat Mar 15 16:40:33 2008 -0700 re..

Git 파일 커밋하기 : $ git commit - Unstaged 상태의 파일은 커밋되지 않는다 (= $ git add 명령으로 추가하지 않은 파일은 커밋되지 않는다.) - 명령어 실행하면 Git 설정에 지정된 편집기가 실행되고, 아래 ex 와 같은 텍스트가 자동으로 포함된다 이후, 내용을 저장하고 편집기를 종료하면 입력된 내용(#로 시작하는 내용을 제외한)으로 새 커밋을 하나 완성한다. - commit명령어 실행 후 몇 가지 정보를 출력하는데 커밋한 브랜치, 체크섬값, 수정 파일 갯수, 삭제or추가 라인 등을 알려준다. $ git commit -a -m 'added new benchmarks' [master 83e38c7] added new benchmarks 1 file changed, 5 inse..

파일 변경 내용을 git 명령어로도 볼 수도 있지만, 사실 상용제품이 한 눈에 비교가능한 좋은 인터페이스를 제공한다 ㅎㅎ... Git 파일의 변경 내용 보기 : $ git diff (=Staged와 Unstaged 상태의 변경 내용을 보기) - stage되어 커밋가능한 상태의 파일의 수정내용을 확인할 떄 $ git diff 명령어를 사용한다. - $ git status vs $ git diff 차이 $ git status 파일이 변경됐다는 사실(파일상태) 확인 $ git diff 파일의 어떤 내용이 변경됐는지 확인 $ git diff 명령어 1. Working Directory의 파일과 Staging Area의 파일 비교 : $ git diff ㄴ> 수정했지만 아직 staged 상태가 아닌 파일이 비교대..

Git 파일 무시하기 (ignore) - git은 Untracked파일까지 관리하므로 git이 아예 신경조차 쓰지 않을 파일들을 설정할 때 사용 +) log, tmp, pid 같은 디렉토리나, 자동으로 생성하는 문서 같은 것들도 추가할 수 있다. - '.gitignore'파일을 만들고 그 안에 무시할 파일 패턴을 적는다. ㄴ> 보통 처음에 만들어 두는 것이 편리 ㄴ> 하나의 `.gitignore 파일을 최상위 디렉토리에 하나 두고 모든 하위 디렉토리에까지 적용시키는 방식으로 주로 사용 (하나만 두는 것이 아니라 하위 디렉토리에도 추가로 둘 수도 있다.) ㄴ> https://github.com/github/gitignore 사이트에서 적당한 예제를 찾을 수 있다. ㄴ> '.gitignore' 파일 ex1)..

Git 에서 파일 상태 ◀ [관련 상세 포스팅] - 우리가 작업하는 Working Directory의 모든 파일은 크게 Tracked(관리대상임)와 Untracked(관리대상이 아님)로 나뉜다. 이 중 'Tracked 파일'만 파일 상태를 가진다. 파일 상태의 종류 3가지 더보기 1. Unmodified상태 : 마지막 커밋 이후 아직 아무것도 수정하지 않은 파일의 상태 ㄴ> 처음 저장소를 Clone 하면 모든 파일은 Tracked이면서 Unmodified 상태 2. Modified상태 : Unmodified 상태 파일을 수정하면 Git은 알아서 그 파일을 Modified 상태로 인식 3. Staged상태 : Modified상태 파일을 "Staging Area에 추가"하면 Staged 상태 ㄴ> Stage..

(svn사용자인 내가 Git의 파일 관리 장소나 파일의 분류, 파일의 상태의 용어들이 정말 헷갈린다ㅠㅠ 그래서 본 포스팅에서 정리하고자 한다.) Git Repository (= git 저장소) - 'git이 관리하는 파일이나 폴더를 저장 장소' - 파일을 수정, 커밋하고 프로젝트의 이력관리 및 공유 등 git의 기능 사용 가능 공간. - 하위에 '.git' 디렉터리가 생성된 디렉터리 1. 원격 저장소(Remote Repository) : 원격에 존재해 clone가능한 저장소 >> 주로 "(내가 clone해 가져오는) 협업 플젝 원본의 저장소" 2. 로컬 저장소(Local Repository) : 내 PC에 위치한 git 설정된 디렉토리 (원격에 등록했으면 원격 ..

일단 저장소(Repository) 란? : 말그대로 파일이나 폴더를 저장해 두는 곳 그럼 Git 저장소 (= Git Repository)란? : 'git이 관리하는 저장소'로 파일이 변경 이력 별로 구분되어 저장되며 다양한 git의 관리 기능이 지원된다. Git Repository 종류 2가지 - Git은 원격 저장소와 로컬 저장소 두 종류의 저장소를 제공한다. (저장소는 꼭 두 종류 중 하나가 아니라 두 종류 다 일 수도 있을 것으로 보인다.) 1) 원격 저장소(Remote Repository) : 파일이 원격 저장소 전용 서버에서 관리되며 여러 사람이 함께 공유하기 위한 저장소 (주로 "(내가 clone해 가져오는) 협업 플젝 원본의 저장소") 2) 로컬 저장소(Local Repository) : 내..

1. Git 의 초기 설정 - Git을 설치하고 나면 Git의 사용 환경을 적절하게 설정해 주어야 한다. 환경 설정은 한 컴퓨터에서 한 번만 하면 되며 Git을 업그레이드해도 유지된다. 2. Git 설정 파일 3가지 1. /etc/gitconfig 파일 : 시스템의 모든 사용자와 모든 저장소에 적용되는 설정이다. >> git config --system 옵션으로 이 파일을 읽고 쓸 수 있다. >> 이 파일은 시스템 전체 설정파일이기 때문에 수정하려면 시스템의 관리자 권한이 필요함 2. ~/.gitconfig, ~/.config/git/config 파일: 특정 사용자(즉 현재 사용자)에게만 적용되는 설정이다. >> git config --global 옵션으로 이 파일을 읽고 쓸 수 있다. >> 특정 사용자..

Git 의 3가지 상태 (= Git이 관리하는 파일들의 3가지 상태) (★★ 반드시 짚고 넘어가야 할 부분) 1. Committed 상태 : 데이터가 로컬 데이터베이스에 안전하게 저장된 상태 2. Modified 상태 : 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않은 상태 3. Staged 상태 : 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태 Git의 동작 (이해하기 쉬운 'git-scm.com'의) Git동작 이미지 : https://git-scm.com/book/en/v2/images/areas.png 1. '워킹 트리(Working tree)'에서 파일을 수정(modify)한다. 2. 'Staging Area'에 파일을 Stage해서 커밋할 스냅샷을 만든다. (모든 파일을 추가할 수도..

Git 이 뭐야? 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템(DVCS)이다. 즉, 스코드를 효과적으로 관리하기 위해 개발된 '분산형 버전 관리 시스템'. # 분산 버전 관리 시스템(DVCS) ?? 각 개발자가 중앙 서버에 접속하지 않은 상태에서도 코드 작업을 할 수 있는 특징이 있는 "소프트웨어 버전 관리 시스템(VCS)"방법 중 하나. - DVCS 종류 더보기 1) 로컬 버전 관리 (=Local VCS) : 간단한 데이터베이스를 사용해서 "파일의 변경 정보"를 관리 ▶ 대표 Ex) VCS 도구 중에 RCS(Revision Control System)는 Patch Set(파일에서 변경되는 부분)을 특별한 형식의 파일로 저장 & 일..