git clone <url>

로컬에 없는 저장소를 가져온다.

깃허브의 공개 저장소에 있는 것들은 모두 클론이 가능하다. 단, 푸시는 불가능하다.

그리고 거의 대부분의 경우에 깃허브가 쓰일 뿐이지 깃허브만 가능한것이 아니다. git clone 명령어도 github와 관계가 없다.

* SSH키 설정 및 깃허브에 등록하기 (Windows 기준)

깃허브 가입이 완료된다면 SSH키를 설정해야한다. 그래야 매번 로그인을 하지 않고도 인증할 수 있기 때문이다.

SSH키가 있으면 그걸 사용하면 되고 없다면 터미널 명령어로 생성시켜 주어야 한다.

$ ssh-keygen -t ed25519 -C <email>
> Generating public/private ALGORITHM key pair.

암호 설정까지 끝내고 생성을 완료했다면 SSH 에이전트를 실행시켜서 키를 추가시켜 준다.

$ eval "$(ssh-agent -s)"
> Agent pid ****

$ ssh-add ~/.ssh/id_ed25519
> Identity added: /c/User/../.ssh/id_ed25519 (email)

깃허브에서 SSH키를 등록하기 위해 공개키를 복사 한다.

$ clip < ~/.ssh/id_ed25519.pub

깃허브의 Setting - [Access] 의 SSH and GPG keys 페이지로 이동해서 "New SSH key" 를 클릭해서 복사한 키를 입력하고 제목을 정해주면 완료된다.

과정이 번거롭지만 디바이스별로 딱 한번만 등록해두면 다시는 할 필요가 없다.

* 로컬에 기존 저장소가 있는 경우

1. 깃허브에서 새 저장소를 만든다.
2. 로컬 저장소에서 원격을 만든다.
3. 푸시한다.

* 아직 작업을 시작하지 않은 경우

1. 깃허브에서 새 저장소를 만든다.
2. 클론한다.
3. 푸시한다.

remote는 깃에게 알려줄 url에 이름을 붙인것이다.

git push <remote> <branch>

깃에게 대상 저장소 및 푸시할 브랜치를 알려준다.

git push origin main 은 정말 흔하게 사용하는 명령어이다.

원격 유무를 포함한 정보를 확인한 후에 push를 실행하면 아무것도 없던 저장소에 파일들이 추가된다.

로컬에서 작업하던것을 깃허브에 올린것이기 때문에 로컬에서 작업했던 브랜치의 이력들이 모두 올라간다.

현재는 main 브랜치만 푸시했기 때문에 main 브랜치만 존재한다.

git push <remote> <local-branch>:<remote-branch>

기본적인 푸시는 로컬 브랜치가 원격 저장소에 존재하지 않으면 새로 생성하고 그 이후에는 같은 브랜치에 푸시되는 방식이다. 즉, 로컬 A브랜치를 원격 저장소의 A브랜치로 푸시하는 것이다.

여기서 로컬 브랜치와 원격 저장소의 브랜치를 다르게 설정할 수 있다. 로컬 A브랜치를 원격 저장소의 B브랜치로 푸시할 수 있다는 것이다.

일반적으로 자주 사용되는 명령어는 아니다.

git push -u <remote> <branch>

upstream의 약어이다. 로컬 브랜치를 원격 브랜치에 연결시킨다.

# local의 main을 origin의 main에 연결한다
$ git push -u origin main

연결시키고 난 뒤에는 git push 명령어 만으로도 푸시가 가능해진다.

보통은 main 브랜치를 처음 푸시할 때 사용한다.

로컬 브랜치와 깃허브의 브랜치는 다르다는 것을 인지해야한다.

git checkout <commit-hash>

HEAD를 해당 커밋으로 이동시킨다. 명령어 실행 시 HEAD가 분리된 상태라는 메시지가 출력된다.

브랜치는 언제나 해당 브랜치의 최근 커밋을 가리키고 HEAD는 그 브랜치를 가리키게 된다. 일반적으로 HEAD는 커밋이 아닌 특정 브랜치를 참조하게 된다.

하지만 해당 명령어를 통해서 HEAD가 특정 커밋을 참조하도록 바꾼다. 원래 브랜치를 참조하던것이 커밋을 참조하게 되었으므로 분리된 상태가 된 것이다.

이를 통해 이전 커밋을 참조할 수 있다.

다시 브랜치로 돌아가려면 switch 명령어로 돌아가면 된다. "git switch -" 입력 시 현재 브랜치의 최상단으로 이동한다.

HEAD가 분리된 상태에서도 브랜치를 새로 생성시킬 수 있다.

과거의 커밋으로 돌아가서 프로토타입 작성 등의 새로운 작업을 시작할 때 매우 유용하게 사용할 수 있을 것 같다.

git checkout HEAD <file-name>

커밋 참조를 이용해서 작업 영역의 변경 사항을 한번에 초기화 하는 방법이다.

무언가 열심히 작업을 하다가 문제가 생기거나 마음에 안들어서 초기화 할때 사용하면 된다.

파일 이름을 적어주면 해당 파일만 마지막 커밋 내용으로 덮어씌워진다.

HEAD 대신 -- 을 입력해도 된다.

git restore

checkout이 너무 많은 기능을 수행하기 때문에 독립시켜 만든 명령어이다.

git checkout HEAD <file-name> == git restore <file-name> 이다.

git restore --source <commit-hash> <file-name> : 특정 커밋의 파일로 변경한다.

git restore --staged <file-name> : 스테이지에 등록된 파일을 다시 작업 영역으로 되돌린다.

git restore 명령어는 git status에서 사용법을 알려주기도 한다.

git reset

저장소를 특정 커밋으로 재설정한다.

일반 재설정과 하드 재설정이 존재한다.

일반 재설정 / git reset <commit-hash>

위와 같이 잘못된 커밋이 존재할 경우 해당 명령어로 커밋만 삭제할 수 있다.

"커밋만" 삭제한다는 점을 주의해야한다. 변경된 사항은 여전히 작업 영역에 남아있다.

HEAD부터 <commit-hash> 직전까지의 범위를 모두 삭제한다.

 

잘못된 브랜치에서 커밋을 했을 때 유용하게 사용할 수 있다.

커밋을 삭제하고 남아있는 변경사항을 정상적인 브랜치에서 다시 커밋을 하면 된다.

 

 

하드 재설정 / git reset --hard <commit-hash>

--hard 플래그 하나가 추가된 형태이다. 커밋을 삭제하는것은 동일하지만 작업의 변경사항까지 모두 삭제한다.

일반 재설정 이후 restore로 작업 영역의 변경사항을 취소한것과 마찬가지이다.

reset은 브랜치 기준으로 작동한다.

git revert <commit-hash>

reset과 기능이 매우 유사하다. reset은 커밋을 제거하고 브랜치 포인터를 뒤로 이동시키는 반면에 revert는 새로운 커밋을 만들어서 이전 커밋의 변경 사항을 취소한다.

결과적으로 커밋을 취소(되돌리는것)하는것은 동일하지만 커밋을 삭제하느냐 남겨두느냐의 차이가 있다.

병합 커밋을 실행할때처럼 명령어 실행 시 충돌을 처리해야 할 수도 있다.

revert를 사용하는 이유는 협업 때문이다.

설령 잘못된 커밋이더라도 다른 사람들이 작업하고 있는 커밋이라면 reset으로 커밋을 제거했을 때, 다른 사람들이 가지고 있는 기록을 취소하는 것이기 때문에 심각한 문제가 발생될 수 있다.

커밋 실수를 했을 때 다른 사람들과 공유되지 않았다는 것이 확실할때는 reset을 사용하는 것이 좋고 다른 사람들과 공유중인것이 확인됐을 때는 revert를 사용해야 한다.

요약

• git restore : 작업 영역의 수정 사항이나 스테이징을 취소한다.
• git reset : 커밋을 취소한다. (커밋 삭제)
• git revert : 커밋을 복구한다. (새로운 커밋 생성)

reset과 revert는 결과는 동일하지만 과정이 다르다.

git stash (=git stash save)

커밋되지 않은 변경사항을 저장하고 변경사항들을 모두 초기화시킨다.

내용이 삭제되는것이 아니라 스태시에 저장된 상태이다.

git stash pop

스태시에 저장된 가장 최근 목록을 가져오고 삭제한다.

git stash apply

방식은 pop과 동일하다. 단, 스태시가 삭제되지 않고 남기때문에 여러 브랜치에서 동일한 내용을 적용할 수 있다.

git stash list

스태시는 여러개 등록이 가능하다.

스태시 아이디를 통해서 특정 스태시를 적용시킬 수 있다.

스태시를 적용하고 바로 다른 스태시를 적용하려고 하면 위와 같이 에러가 발생한다.

작업 내용이 덮어씌워지기 때문에 에러가 발생하고 병합 되기전에 커밋이나 스태시를 하라고 한다.

git stash drop

특정 스태시를 삭제시킬 수 있다.

git stash clear

모든 스태시를 삭제한다.

git diff

스테이지에 등록되지 않은 작업 영역의 변경사항을 모두 나열한다.

a는 커밋된 파일, b는 작업 영역의 파일이다.

git diff HEAD

마지막 커밋이 실행된 이후의 변경사항을 모두 나열한다.

마지막 커밋 이후 변경 사항을 스테이지에 올리지 않은 상태라면 git diff, git diff HEAD 둘다 같은 결과를 출력한다.

하지만 변경 사항을 스테이지에 올린다면 git diff는 아무것도 출력되지 않지만 git diff HEAD는 결과가 출력된다.

git diff --staged (--cached)

스테이지에 등록된 변경사항만을 나열한다.

git diff branch1 branch2 (branch1..branch2)

두 브랜치를 비교하여 변경사항을 모두 나열한다.

a, b는 브랜치 입력 순서에 따라 매칭된다. 위와 같은 경우는 a는 branch1, b는 branch2이다.

git diff commit1 commit2 (commit1..commit2)

두 커밋을 비교하여 변경사항을 모두 나열한다.

마찬가지로 a, b는 커밋 입력 순서에 따라 매칭된다.

* HEAD는 단순히 마지막 커밋을 가리키는 레퍼런스이다. 그래서 git diff HEAD HEAD~1 실행시 마지막 커밋과 그 부모커밋을 비교하는 명령어가 된다.

git diff <file-name1> <file-name2> <..>
git diff --staged <file-name>
git diff HEAD <file-name>
git diff branch1..branch2 <file-name>
git diff commit1..commit2 <file-name>

위와 같이 특정 파일에 대한 변경사항만 확인할 수도 있다. 동시에 여러 개의 파일도 가능하다.

Composites 노드

높은 우선순위의 자식 노드부터 순차적으로 실행된다.

• Selector: 자식 노드 중 하나라도 실행 성공시 성공한 것으로 본다. 옆의 노드들은 더 이상 실행되지 않는다.
• Sequence: 자식 노드 중 하나라도 실행 실패시 실패한 것으로 본다. 옆의 노드들은 더 이상 실행되지 않는다.
• Simple Parallel: 이름 그대로 단순 병렬 노드이다. 전체 노드 트리와 동시에 하나의 태스크를 실행시킨다.

Decorators 노드

조건절이라고도 한다. if의 개념과 같다. 컴포짓이나 태스크노드에 붙여서 실행 여부를 정의할 수 있다.

Services 노드

Tasks 노드

AI의 이동이나 블랙보드의 값 조정등의 작업을 한다.

Tasks 노드를 C++ 커스텀으로 만들시에는 공개 종속성 모듈에 "GameplayTasks"를 포함시켜 주어야 한다.

커스텀 노드를 만들었다면 ExecuteTask를 구현하면 된다.

매개변수 OwnerComp를 통해 블랙보드와 AIController에 접근할 수 있다.

EBTNodeResult::Type을 반환함으로써 성공/실패 유무를 반환한다.