Achievement Goals
- 상황에 따라 Github의 기능과 Git 명령어를 사용할 수 있다.
=> 하기의 명령어 활용
- Fork
다른 계정의 Remote Repository를 내계정으로 가져올때
- clone
원격 Repository를 내 로컬로 이용할 수 있도록 복사
명령어)
git clone (Repository 주소)
- status
내 로컬로 복사해온 디렉토리 Commit 되기 전 까지의 상태를 표시
Staging area와 Untracked file 목록에 어떤것들이 있는지 확인
ex)
Changes not staged for commit.
(use "git add (file)"..." to update what will be committed)
(use "git restore (file)"..." to discord changed in working directory)
명령어)
git status
- restore
Commit 혹은 staged 되지 않은 변경 사항을 폐기
Work space의 병경 사항을 폐기하고 다시 처음으로 clone 받아 왔던 상태로 돌아감
명령어)
git restore (파일명)
- add
Untracked files를 Staging area로 추가해서 Git의 관리하에 둠
명령어)
git add (파일명) // 파일 하나
git add . // 모든파일을 한번에 추가
- commit
수정 작업이 끝났을때 변경사항을 저장
명령어)
git commit -m 'commit 메세지'
- 통용 또는 상대방이 알기 쉬운 메세지 작성법 추가 복습 -
- reset
local에서 commit 한 내용을 취소 할 때
명령어)
git reset HEAD^
git reset HEAD3 === git reset HAED^^^
- log
현재까지 commit된 내역들을 터미널 창에서 확인할 수 있다.
명령어)
git log
(명령어 후 터미널창 종료 q)
- pull
pull Resquest(PR), 내가 push한 변경사항을 다른사람에게 알리는 것
- push
Local에서 변경, commit 된 사항을 Remote Repository에 업로드
명령어)
git puch (origin(remote Repository)'저장소') (branch)
- init
기존 디렉토리를 Git Respository로 변환
명령어)
git init
- remote add (origin)
나의 Remote Repository에 연결
명령어)
git remote add origin (Repository 주소)
내 local에 pair라는 이름으로 등록
git remote add pair (Remository 주소)
- remote -v
연결된 Remote Repository 확인
명령어)
git remote -v
- Git의 세 가지 영역 및 상태를 이해할 수 있다. (Committed, modified, staged)
-
Committed - Git 디렉터리에 존재하는 파일들
-
modified - Git 디렉터리로부터 워킹 트리에 Checkout 하고 파일을 수정했지만 아직 Staging Area에 추가하지 않은 경우
staged - Git 디렉터리로부터 워킹 트리에 Checkout 하고 파일을 수정하고 Staging Area에 추가했다면 Staged 상태
- Pull
내 commit을 Push하기 전에 페어가 작업해서 본인의 Remote Repository에 올려 놓은 내용을 합치려고 할때
git pull (shortname) (branch)
- Remote Repository를 페어와 공유하며 협업을 할 수 있다.
- 충돌이 발생했을 경우 해결할 수 있다. // 좀 더 충돌상황에 대한 이해도가 필요
Advanced Challenge (optional)
- git repository의 commit되지 않은 변경 사항을 취소할 수 있다.
아직 Remote Repository에 업로드 되지 않고 Local Repository에만 commit 해 놓은 기록이라면 reset 명령어를 통해서 commit 을 취소할 수 있습니다.
-
reset HEAD <'file>
-
checkout -- <'file>
- 협업을 위한 git 개념을 이해할 수 있다. // 어느정도 이해는 하지만 자주 많이 사용해봐야 할 거 같다
- branch, merge의 개념
branch 란?
독립적으로 어떤 작업을 진행하기 위한 개념
필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있다.
merge 란?
git에서 서로 다르게 만든 부분을 병합하기 위해서 사용
소스코드를 합쳐서 테스트도 해보고 시스템에 적용도 해보고 해야한다.
그런 상황에서 브랜치를 합치는 것(병합)을 merge라 한다.
ex) A브랜치에서 B브랜치를 병합한다
git merge B브랜치명
- remote repository에서 origin과 upstream의 차이점
upstream과 downstream
upstream과 downstream은 두 레포간의 관계에 따라 정의되는 상대적인 개념으로 어떤 한 레포가 절대적으로 업스트림이거나 다운스트림이 아니라는 거 같다.
사전적인 의미를 보면 upstream이 상류, downstream이 하류
물이 상류에서 하류로 흐르듯이 원천이 되는 것을 upstream이라고 한다.
내가 내레포에 git을 통하여 git에 올려져 있는 다른 레포 코드를 fork하고 clone 하여 pull, puch 한다면 다른레포 코드가 upstream이고 내 레포는 downstream이다.
하나의 업스트림에 여러 개의 다운스트림이 있을 수 있다.
Origin과 Upstream의 차이
-
Upstream
내가 다른 사람의 레포를 포크해왔을 때에 upstream은 일반적으로 오리지널 레포(다른 사람의 레포)를 의미한다. 즉 내가 OtherRepo를 fork해왔다고 할 때에 이 OtherRepo가 오리지널 레포이고 upstream이 된다. -
Origin
origin은 내 포크를 의미한다. 레포가 클론될 때에 디폴트 리모트는 origin이라고 불린다. 그러니까 내 포크를 myRepo라고 할 때, 클론하면 이것이 내 레포가 origin이 된다. 내가 오리지널 레포의 변화를 추적하고 싶으면 upstream이라는 이름의 리모트를 추가해야 한다.
-해야할 것
git에 대하여 좀 더 익숙해지고 이해하기
충돌이 언제 발생되는지 이해 및 가상 충돌해보기
merge에 대하여 좀 더 세세히 알아 볼것, merge를 통하여 충돌에 대한 부분도 이해가 필요
