#Shell
Shell에 명령을 입력할 수 있는 프로그램 (Shell이 커널과 소통)
#Shell의 종류
- Bourne Shell
- Bash
- 간혹 면접에서 물어보는 경우가 있다 ..
- Z Shell (즤 쉘~)
#CLI VS GUI
CLI 환경 .. GUI 환경 ..
- Command Line Interface
- Graphical User Interface
- MacOS를 키면 .. 나타나는 것들
- 2가지 환경의 장/단점이 있다.
- GUI의 경우, 갱신이 되지 않는 경우가 있다. (그래서 많이 사용하는 환경에서만 지원)
- CLI는 거의 풀스택으로 지원되므로 많은 기능이 존재
- 그래서 필요에 따라서 CLI/GUI를 사용 (무조건 어떤 것이 좋다, 안좋다 라고 할 수 없다.)
- Xcode도 CLI 환경에서 제어할 수 있다. (GUI상으로 지원하지 않는 기능이 있기 때문)
#경로
절대 경로 (Absolute PATH)
- root 디렉토리를 기준으로 하는 경로
(*root : 시스템이 설치 되어 있는 최상위 경로)
- 시스템은 절대 경로를 기준으로 파악
- 예) /Users/hue/Desktop/sesac
- home Directory ( ~ )
여러 사용자가 로그인할 수 있으므로 해당 유저를 기준으로 접근할 수 있는 경로를 의미
상대 경로 (Relative PATH)
/Users/hue/Desktop/sesac
/Users/hue/Desktop/sesac
Command line 명령어
pwd
- print working directory
- 현재 디렉토리 경로 확인
cd
- change directory
- cd 디렉토리
ls (List)
커멘드 라인 명령어에서 - 또는 -- 을 통해서 옵션을 줄 수 있다.
- ls - a
- 숨김 파일까지 다 볼 수 있는 옵션
- ls -l
- ls -al
mkdir
- make directory
- 현재 디렉토리에 디렉토리 생성
이런 식으로 현재 위치를 확인하고 디렉토리 위치를 이동할 수 있다.
위치로 이동한 다음에 tab을 치면 그 안에 있는 폴더로 자동 완성이 되면서 이동할 수 있다.
프로젝트 파일(SSAC-Memo)안으로 이동해서 ls를 누르면 안에 들어있는 파일을 볼 수 있는데 .git 또는 .gitignore와 같이 숨김 파일을 보고 싶다면 ls -a 옵션을 통해서 볼 수 있다.
touch
- 빈 파일을 생성
- ex) touch .gitignore
echo
- 문자열이나 변수를 출력
- ex) echo $shell
- 자주 사용하는 용법
- echo pods/ > .gitignore
- 덮어쓰기
- echo pods/ >> .gitignore
- 추가로 넣기
- echo pods/ > .gitignore
cat (catenate)
- cat 파일명
- ex) cat .gitignore
rm (remove)
- 파일이나 디렉토리 삭제
- rm 파일명
- rm -r 디렉토리명
- rm -rf 디렉토리명
- r로 지워지지 않는 파일 (권한이 없어서) 등을 지울 수 있다.
그외
- clear
- xed
- sudo (최고 권한으로 실행)
- history
- history -c : 명령어 내역을 모두 삭제할 수 있다.
- curl : URL 확인 가능
- open
실습을 해보자
#파일을 하나 만들고 git과 연결해보자
#현재 누가 깃을 관리하는가?
so yeon이라는 이름과 alicesysy@swu.ac.kr 이메일을 갖고 있는 유저가 관리한다.
git 관리를 누가 하고 있는지 등에 대한 정보를 확인할 수 있다. (로컬/원격 모두 확인 가능)
#파일 생성/수정 > 커밋
파일을 생성하면 main 브랜치 부분에서 컬러 변화가 나타난다.
(새로운 변화가 있기 때문에)
git status의 단축어인 gst를 입력하면 어떤 상태인지 보여준다.
위에서 생성한 a.swift 파일은 현재 untracked 상태지만, 커밋을 하기 위해서는 staging 영역으로 올려야 한다.
git add . 명령을 통해서 올릴 수 있다.
(*만약 기본 브랜치가 main이 아닌 master로 설정이 되어 있다면, git config --global init.defaultBranch "main" 라고 입력해서 바꿔줄 수 있다.)
제대로 올렸다면 위와 같이 상태를 확인했을 때 staging 영역으로 올라온 것을 볼 수 있다.
커밋을 하면 staging area이 다시 갱신되므로 +문자가 사라지고 색상도 변하는 것을 확인할 수 있다.
git log 명령어를 통해서 위와 같이 작업/커밋 내역을 확인할 수 있다.
(위의 창에서 나오고 싶다면 q를 누르면 된다.)
몇가지 작업을 더 하고 .. git log로 내역을 확인해보자.
지금까지 한 작업 내역을 볼 수 있다.
amend 명령어를 통해서 마지막 커밋 내역의 메시지를 변경할 수 있다.
3st -> 33st로 바꿀 수 있다. ⬇️
기존 파일에 대해 수정을 할 수 있다.
수정을 한 뒤에 커밋 내역의 마지막을 바꿀 수 있다.
위에서 33st으로 메시지를 입력해서 커밋한 다음, 작업을 더 하고 33st+1로 커밋을 할 수 있다.
작업을 다 하지 않았을 때, 작업 저장용으로 커밋을 하고 --amend를 통해서 작업을 마저 하고 커밋할 수 있다.
현재 이 상황 .. 일 때 .. 만약 c 파일과 d 파일을 작업한 내용이 필요가 없다면? 이전 시점으로 돌아가야 한다면?
#과거 시점으로 돌아가기
reset으로 돌아가야 한다 !!!
먼저 시점을 알아야 하므로 commit id를 보자.
위에서 1st으로 돌아가야 하므로 메시지 앞의 커밋 id를 복사한 다음에 hard 옵션으로 돌아가자.
그리고 내역을 보면
그 시점으로 돌아간 것을 볼 수 있다.
그런데 .. 만약 .. 다시 d까지 작업한 시점으로 돌아가야 한다면 ????
reflog 명령어를 사용하면 된다 !!!!!!
reflog로 내역을 보고 돌아가고 싶은 특정 시점을 찾아서 다시 reset --hard로 돌아가면 된다.
여기까지 작업을 git log 명령어로 살펴 보면
이렇게 다시 돌아온 것을 볼 수 있다.
#git stash (임시저장소)
물론 다채롭지만 ..
몇가지 작업을 해보자.
d파일과 c파일을 수정해보자.
수정된 것을 확인할 수 있다.
이 때, 만약 다른 작업을 하고 나서 >> 위 작업을 하면 좋다고 판단이 되면 ??
stash를 할 수 있다.
그러면 위에서 작업한 d.swift 파일과 c.swift 파일을 다른 곳에 잠시 임시저장 한 것이다.
어디에 저장이 되는가?
stash list로 확인할 수 있다.
명령어를 치면 새로운 창이 나오고 위와 같이 앞서 stash한 작업이 들어가 있는 것을 확인할 수 있다.
다시 갖고 오고 싶다면?
git stash pop을 통해서 stash에 들어간 작업 내용을 갖고 올 수 있다.
#Aborting
git이 알아서 최근 커밋을 기준으로 파일에 반영한 것이다.
하나의 파일에 대해서 동시에 작업을 해서 생긴 작업이므로 commit을 해주면 된다.
#git stash pop / git stash apply
- git stash pop
- git stash apply
새로운 작업을 하나 하고 stash를 해보자.
stash 하고 list로 stash 기록을 보면 아래와 같다.
pop을 하고 다시 리스트를 살펴보면
기록 내역에서 사라진 것을 볼 수 있다.
반면에 stash apply를 하게 되면
작업이 다시 불러와도 기록 내역에 남아 있는 것을 확인할 수 있다.
브랜치 생성
abc라는 브랜치를 생성했다.
내 브랜치 리스트를 보고 싶다면
git bracnh 명령어를 입력하면 된다.
위에서 생성한 브랜치로 이동해보자.
브랜치가 바뀐 것을 볼 수 있다. (main > abc)
바뀐 브랜치에서 작업을 하자. (aaa를 두번 입력했다.)
그리고 다시 main으로 이동해서 파일을 보면 위에서 작업한 내용이 없는 것을 볼 수 있다.
(당연함. 브랜치가 다르니까.)
다시 메인으로 와서 새로운 sokyte 브랜치를 만들어보자
메인에서 브랜치를 만들었기 때문에 메인의 내용이 계승된 것을 볼 수 있다.
바뀐 브랜치에서 작업을 하고 커밋을 하자.
그리고 git log로 내역을 확인하면 아래와 같다.
다시 메인으로 이동해보자. 그리고 작업을 확인하면 초기 작업 상태로 남아 있는 것을 볼 수 있다.
그리고 앞서 작업한 abc 브랜치와 sokyte 브랜치 중 작업을 하나 선택해서 머지를 해야 한다.
머지에서 권장하는 방향성은 메인에서 브랜치를 갖고와서 머지를 하는 것이 좋다. (결과적으로는 같지만)
메인에서 sokyte 브랜치를 머지하면 위와 같다.
*Fast-forward merge
head가 움직이면서 머지를 한다.
main에서 sokyte 브랜치까지 머지한 작업은 위와 같다.
그래서 위와 같이 헤드가 메인, sokyte 브랜치를 가르키고 있는 것을 알 수 있다.
여기서 abc 브랜치를 머지해보자.
우하하!! 컨플릭트!!
위의 코드에서 맞는 부분만 골라서 수정하면 된다.
(이 과정이 컨플릭트를 해결하는 과정이다.)
그리고 저장을 한뒤, 다시 터미널로 돌아온다.
수정을 했기 때문에 add . 로 다시 staging에 넣어주고 커밋을 하면 된다.
위의 과정은 3-way commit으로 이 머지 방법은 필연적으로 머지 커밋이 생긴다.
그리고 log 내역을 보면
메인을 두고, sokyte와 abc 브랜치를 지울지 안지울지 선택하면 된다.
먼저 sokyte 브랜치를 지우면
branch -d를 통해서 지우고 브랜치 리스트에서도 지워진 것을 확인할 수 있다.
'Git' 카테고리의 다른 글
[Git] Rebase란? (0) | 2022.10.27 |
---|---|
[Git] push한 commit message 수정 (1) | 2022.10.11 |
[Git] Reset (0) | 2022.10.04 |
[Git] Branch 이해하기 (0) | 2022.09.30 |
[Git] Git을 배워보자. (0) | 2022.09.30 |