neck392

cherry-pick 명령어는 commit을 하나의 branch로 합친다는 점에서 merge와 동작 방식이 유사하지만 다른 branch의 모든 commit 내용이 아닌 특정 commit만 적용한다는 점에서 차이가 있다. 구체적으로는 긴급 버그 픽스에 대한 commit만을 다른 branch들에 적용할 때 사용될 수 있다. cherry-pick 협업 프로젝트를 진행하다보면 어떤 branch의 모든 commit 내용을 merge하지 않고 특정 commit 들만 선택적으로 main branch에 merge해야하는 일이 생길 수 있다. cherry-pick 명령어를 사용하면 현재 작업 공간 branch에 다른 branch의 commit 내용을 반영하여 새로운 commit을 생성한다. 예를 들어, 위 그림에서처럼 ..

Commit된 내용을 되돌리거나 수정하고 싶을 때 revert 혹은 reset 명령어를 사용할 수 있다. 마찬가지로 각 명령어의 수행 방식(용도)은 다르며 목적에 알맞게 명령어를 사용해야 한다. revert revert는 현재의 작업 공간을 일부 유지하면서 과거의 특정 commit만을 되돌리며 과거 시점의 commit으로 돌아가는 것에 대하여 변경 이력을 남긴다. 즉, commit을 되돌리는 것에 대한 새로운 commit을 생성하며 commit history에 기록된다.revert 명령어를 사용하면 협업 프로젝트에서 이미 remote repository에 push 된 commit에 대하여 commit history를 유지하면서 복구할 수 있다.  // commit 되돌리기git revert // 마지막 ..

Merge를 수행할 때는 항상 conflict를 고려해야 한다. branch에서 각기 다른 부분을 수정하고 merge하는 경우(Fast-forward merge)에는 문제가 없으나 같은 코드에 대하여 변경 사항이 있는 경우 각 branch가 참조하는 commit을 기준으로 자동 merge(3-way Merge)한다. 즉, 2개의 변경 사항을 합쳐 하나의 새로운 병합 commit이 생성된다.  Types of MergeFast-forward Merge3-way Mergegit에서는 자체적으로 merge를 할 때 유동적으로 해결하는 기능이 있으며 conflict가 일어난 코드의 부분마다 사용자가 직관적으로 파악하여 해결할 수 있는 기능 또한 갖추어져 있다. Conflict그러나 2개의 commit이 하나의 ..

branch를 나누어 작업한 이후에 결과물(변경 사항)을 합치는 것을 병합(merge)이라 한다.branch를 통하여 작업 공간을 분리한 이후에 분리된 공간에서의 서로 다른 혹은 각 코드들을 융합한다. 각 branch에서 작업한 내용을 합치는 명령어로는 merge와 rebase가 있다. 두개의 branch를 하나로 합친다는 점에서 동작 방식은 매우 유사하지만 commit history 생성 결과가 달라진다는 것에서 큰 차이가 있으며 사용하는 용도 또한 다르다.rebase는 해당 작업을 base로 만들기 때문에 협업 프로젝트에서는 신중하게 진행해야 한다. merge 협업을 위하여 작업 공간을 branch를 통하여 분리한 이후에 작업한 내용을 합치는 명령어이다. rebase와는 다르게 각 branch마다 c..

branch는 분리된 작업 공간을 말한다. 해당 명령어로 현재 작업 공간의 데이터를 기반으로 분기하여 새롭고 분리된 작업 공간을 생성할 수 있다. branch를 나누어 작업하면 conflict를 해소하는데 도움이 된다. 사용자들 마다 각각의 branch에서 작업하고 main branch로 merge하는 방식이 일반적이다. 작업자 간의 작업 효율성을 위해서는 branch를 목적에 맞게 생성 및 분리하여 작업하고, 목적 달성 시 바로 main branch에 merge하는 것이 좋다. 또한, 작업 branch와 배포할 목적을 가진 branch를 나누어 관리할 수도 있다.branchbranch는 코드의 특점 시점을 기준으로 분기하여 독립적으로 각각의 commit 내용을 기록한다. merge 전까지는 다른 bra..

"git pull"과 "git fetch" 두 명령어 모두 remote repository의 변경 사항들을 local로 가져오지만 동작 방식에 있어서 차이가 있으며 사용하는 용도 또한 다르다.pull : remote repository를 local로 가져와 변경 사항들을 현재 branch에 즉시 mergefetch : remote repository를 local로 가져오지만 적용하지 않고 변경 사항들을 확인, 이후 수동 merge 시 pull과 동일pull = fetch + merge pullfetch + merge를 즉시 수행한다. 변경 사항들이 merge를 통하여 local repository에 commit된다. remote에서의 변경 사항들을 현재 branch(checkout된 branch)에 바로..

"git push" 명령어를 사용하여 local에 commit된 변경 사항들을 remote repository에 최종적으로 업로드하기 위해서는 "git add"명령어를 사용하여 작업 내용을 stage area에 등록한 뒤에 "git commit" 명령어를 사용하는 과정이 선행되어야 한다. 이후에 앞서 말했던 것 처럼 "git push" 명령어를 사용하여 최종적으로 remote repository에 업로드한다."git push" 명령어는 현재 branch에 적용되며 다른 branch 내용을 push하기 위해서는 해당 branch로 이동하거나 이를 명시해야 한다. 만약 새로운 remote repository에 연결한 이후에 처음 push한다면 -u 옵션을 사용하여 해당 branch를 로컬의 기본 branch..

add새 파일을 생성하여 Untracked 상태에서 Stage area에 등록하여 Staged 상태로 바꾸거나commit한 이후에 수정된 Modified 상태의 파일을 Stage area에 등록하여 Staged 상태로 바꾸기 위한 명령어는 다음과 같다. 추가적으로 삭제한 파일에 대해서도 변경 사항을 repository에 저장하기 위해서 stage area에 등록하는 과정이 필요하다.// stage area 등록 명령어git add // working directory에 존재하는 모든 파일에 대한 변경 사항을 등록git add .// 특정 디렉토리 및 하위 디렉토리, 파일들을 등록git add /"git add" 명령어는 단순히 변경 사항을 stage area에 등록만 하기 때문에 이후에 "git comm..

Git에서 각 파일들의 상태는 작업 영역에서의 변경 상황에 따라 변화한다.Working directory에 존재하는 파일들은 아래와 같은 상태들로 분류할 수 있다.Untracked : 새로 생성된 파일이며 버전 관리 이전의 상태이다.Staged : "git add"를 사용하여 stage area에 추가된 상태이며 다음 commit에 포함된다.Unmodified : 가장 최근 커밋 이후 파일에 아무 수정 사항이 없는 상태이다.Modified : 커밋된 파일이 새로 수정되었지만 아직 "git add" 명령어로 stage area에 등록 전 상태이다.여기서 Staged 상태의 파일은 2가지 상황으로 분류할 수 있다.Untracked 상태의 파일이 "git add" 명령어로 Staged 된 상황Modified ..

Workflow// local repository 생성 명령어git initGit은 단순히 위 명령어로 local repository를 생성하고 파일을 생성 혹은 수정한 뒤 "CTRL+S"를 누른 모든 파일들이 바로 repository에 업로드(적용)되지 않는다. 각 파일들을 각각의 영역에 순차적으로 등록한 뒤에 최종적으로 repository에 업로드하는 명령어를 입력해야 하며 이에 따라 파일들의 상태도 변화한다. "git init"을 수행한 작업 공간을 working directory 혹은 working tree라고 부른다.working directory와 최종적으로 업로드되는 repository 사이에 index라고도 하는 stage area라는 공간이 존재하며 working directory에서 s..