깃

Git에서 작업 되돌리기 git reset git revert 두 가지 방법 존재 Git 리셋(reset) git reset 은 브랜치로 하여금 예전의 커밋을 가리키도록 이동시키는 방식으로 변경 내용을 되돌린다. ("히스토리"를 고쳐 쓴다.") git reset 은 마치 애초에 커밋하지 않은 것처럼 예전 커밋으로 브랜치를 옮기는 것 git reset HEAD~1 Git 리버트(revert) 로컬 브랜치의 경우 리셋(reset)을 잘 쓸 수 있지만, "히스토리를 고쳐쓴다"는 점 때문에 다른 사람이 작업하는 리모트 브랜치에는 쓸 수 없음. 변경분을 되돌리고 이 되돌린 내용을 다른 사람들과 공유하기 위해서는, git revert를 사용해야함 git revert HEAD 로컬 브랜치의 경우 리셋(reset)을 ..

브랜치 강제로 옮기기 -f 옵션을 이용해서 브랜치를 특정 커밋에 직접적으로 재지정 할 수 있음 git branch -f master HEAD~3 강제로 master 브랜치를 HEAD에서 세번 뒤로 옮겨라 => bugFix와 master가 같은 커밋을 바라보고 있었지만, master 브랜치가 HEAD에서 세번 뒤로 옮겨감

Git의 상대 참조 한번에 한 커밋 위로 움직이는 ^ 한번에 여러 커밋 위로 올라가는 ~ Git의 상대 참조 master^ ⇒ master 브랜치의 부모와 같은 의미 master^^ ⇒ master의 조부모(부모의 부모)를 의미 git checkout master^ 를 하면 위와 같은 상태가 된다.

프로젝트를 표현하는 커밋 트리(commit tree)에서 이동할 수 있는 여러가지 방법을 알아보자. 알아야할 용어 HEAD HEAD는 현재 체크아웃된 커밋을 가리킴 (현재 작업중인 커밋) HEAD는 항상 작업트리의 가장 최근 커밋을 가리키며, 작업트리에 변화를 주는 git 명령어들은 대부분 HEAD를 변경하는것으로 시작함 일반적으로 HEAD는 브랜치 이름을 가리키며, 커밋을 하게되면 bugFix의 상태가 바뀌고 이 변경은 HEAD를 통해서 확인이 가능함 HEAD 분리하기 HEAD를 분리한다는 것은 HEAD를 브랜치 대신 커밋에 붙이는 것을 의미 HEAD → master → C1 git checkout C1 HEAD → C1

브랜치끼리의 작업을 접목하는 두 번째 방법은 리베이스(rebase)이다. 리베이스는 기본적으로 커밋들을 모아서 복사한 뒤, 다른 곳에 떨궈 놓는 것이다. (리베이스를 하면 커밋들의 흐름을 보기 좋게 한 줄로 만들 수 있다는 장점이 있음) bugFix 브랜치에서 git rebase master 명령어 실행 후 C3 커밋은 어딘가에 남아있고(흐려진 영역), C3'는 master 위에 올려 놓은 복사본이다. git checkout master git rebase bugFix master 브랜치에서 bugFix쪽으로 리베이스를 하게 되면 아래와 같이 된다.

두 별도의 브랜치를 합치는 몇가지 방법을 알아볼 텐데, 처움으로 살펴볼 방법이 merge이다. Git의 합치기(merge)는 두 개의 부모(parent)를 가리키는 특별한 커밋을 만들어 낸다. 두 개의 부모가 있는 커밋이라는 것은 "한 부모의 모든 작업내역과 나머지 부모의 모든 작업, 그리고 그 두 부모의 모든 부모들의 작업내역을 포함한다"라는 의미가 있다. 만약에 bugFix란 브랜치가 C2를, master 브랜치가 C3를 가리키고 있는 상태에서 위 그림과같이 만드려면 아래와 같은 명령어가 필요하다. git checkout master // master 브랜치로 체크아웃 git merge bugFix // bugFix 브랜치와 병합(merge)

Git 스테이징단계 이해Git은 다른 형상 관리시스템과 다르게 소스 코드를 직접 추가하거나 변경하지 않더라도 이를 인지하지 못하며 Git add 명령을 통해서만 인식할 수 있다. => Git의 형상 관리가 3가지 영역으로 진행되기 때문(출처 : http://devstory.ibksplatform.com/2017/09/git-1-git-git.html)워킹 디렉터리 : 소스 코드를 작업하는 영역으로 코드를 추가, 수정, 삭제한느 작업이 이루어지는 영역을 의미스테이징 영역 : 워킹 디렉터리에 Git add 명령을 실행하면 파일들은 Git의 스테이징 영역으로 이동하며 이를 통해 소스 코드의 상태 정보를 확인할 수 있다.저장소 영역 : 스테이징 영역에 있는 소스 코드에 Git commit 명령을 실행하면 최종적..

local에서 commit 후 remote repository로 push를 하는 과정에서 에러가 났다.에러로그메시지는 아래와 같다.Updates were rejected because the remote contains work that you do not have locally.(무척당황했었음..) 구글링 결과 에러의 이유는 아래와 같았다.=> gitHub 레파지토리에서 README.md를 생성한적이 있는데, 이 파일때문에 에러가 난 것이다.When you created your repository on GitHub, you created a README.md, which is a new commit.your local repository doesn't know about this commit yet...

Git으로 형상 관리하기 기본용어 이해커밋하는 단위에는 다음과 같은 내용이 포함되어 있다.스냅샷(snapshot)git에서 커밋할 때마다 발생하며 커밋한 시점의 형상관리 상태를 의미. 버전이라는 의미도 내포하고 있다.트리(Tree)파일과 디렉터리의 구조 정보를 저장하고 있다. 일반적으로 파일 시스템이 트리구조를 가지고 있기 때문에 형상 관리 역시 트리 형태로 스냅샷을 저장한다.저작자(Author)git에서 관리하고 있는 파일 혹은 디렉터리를 최초로 생성한 사람의 정보이다.커미터(Committer)최초 파일이 저장소에 반영되면 저작자와 커미터가 동일하지만 이후 해당 파일을 다른 사람이 수정하게 되면 커미터가 변경된다. 저작자는 파일을 생성한 사람. 커미터는 파일을 수정한 사람커밋 메시지(Commit Mes..

형상관리를 해야하는 이유실수, 고의로 파일을 삭제시, 복구할 방법이 없음하나의 파일을 여러 사람이 동시에 작업 불가이전 데이터로 복구 불가 형상관리의 장점소스코드 변경 이력 관리프로젝트 팀원 및 관계자들이 서로 공유 가능장애 혹은 기능상 필요할 때 이전 버전으로 복구 가능동일한 소스 코드를 공유해서 개발 가능, 버전 충돌 문제 관리 가능 요즘 형상 관리 도구에서는 동시 작업을 위한 처리 방식으로 Copy-Modify-Merge 방식을 사용한다.=> 다른 개발자가 소스 코드에 접근 하지 못하도록 Lock을 거는 방식이 아니고, 수정을 원하는 개발자가 소스 코드를 다운로드해서 수정한 다음 형상 관리에 커밋을 하되 버전에 충돌이 생길 경우 머지 명령을 통합해서 이를 해결하는 방식이다.다른 개발자의 수정 작업이..