[Git] Git 사용법 및 터미널 명령어 정리

Dico·2020년 10월 8일
30

[Git]

목록 보기
2/3
post-thumbnail

Basic 터미널 명령어


작업위치

  • pwd
    Print working directory; 현재 작업 위치 알려줌.

  • ls
    list files; 현재의 directory의 모든 파일들을 보여줌.

  • cd ..
    상위 디렉토리로 이동.

  • cd ~
    사용자의 홈디렉토리(/Users/hannah)로 감.

  • cd 디렉토리명
    change directory; 원하는 디렉토리로 이동; 다만 건너뛸 수는 없음. 한 칸씩 단계적으로 들어가야 함.

디렉토리 / 폴더

  • mkdir 디렉토리명
    make directory; 새로운 directory 생성.

  • rm –rf 디렉토리명
    디렉토리 삭제. 디렉토리와 디렉토리 하위의 모든 파일까지 삭제.

  • cp -R <sourcedir> <destdir>
    디렉토리 복사.
    Sourcedir: 카피하고 싶은 폴더명, destdir: 옮기고싶은 폴더명.
    검색키워드# mac terminal commands copy directory

파일

  • cat 파일명
    파일의 contents를 보여줌.

  • touch .파일명
    파일 만들기.
    Ex) touch .DS_Store (DS_Store라는 파일 만들기)

  • echo "파일내용" > 파일명
    내용과 함께 새로운 파일 만들기.
    Ex) echo "project test" > test.html ('project test'라는 내용이 있는 test.html 파일을 생성)

  • 파일명 .gitignore
    무시해야할 소스파일 만들기. 소스파일 버전관리.

  • ls -al | grep .파일명
    특정 파일 불러오기. 찾고 싶은 파일이 있을 때.
    Ex) ls -al | grep .gitconfig (gitconfig파일 찾기)

etc.

  • ctrl + L
    터미널 화면 clear (화면이 너무 복잡할 때).

터미널로 Git 관리하기


status

git status

레포지토리의 상태를 보여주는 명령어.
현재 브랜치, 원격 브랜치, 현재 추적중인 파일, 변경된 파일목록 등이 표시됨.
폴더를 만들어서 git status를 하게 되면 나오는 내용⬆️
On branch master: 현재 브랜치는 'master'라는 뜻.
No commits yet: 아직 commit한 내용은 없음.

Staging area로 들어갈 준비가 된 파일: index.html
추가되지 않은 파일(git add가 되지 않은 파일) : hello.html
add되지 않은 파일은 commit이 될 수 없기 때문에 지금 상태로 commit을 하게 되면 여전히 working directory에 남아있게 된다.

이렇게 현재상태를 확인하면 된다!!!



add

add는 Working directory의 파일을 staging area로 옮기는 명령어.

git add [파일경로] *명령어에 대괄호[]는 입력하지 않음

명시된 파일만 staging area로 추가.
Ex)git add index.html : index.html 파일만 staging area로 추가.

git add .

추가해야될 파일이 다수인 경우, 현재 디렉토리 밑에 있는 추가되지 않은 모든 파일을 staging area에 한번에 추가.

git add -i

대략 위와 같은 모습.
여러가지 명령 프롬프트가 나오게 함. 원하는 액션에 맞는 번호를 바로 입력하면 됨. 다른 사람들과 공동작업을 할 때 특히 이렇게 하는 게 좋음.



remove

git rm –cached [파일경로]

staging directory에 추가된 파일을 다시 working directory로 내려보내는 명령어.
git status를 입력했을 때 나오는 화면.
괄호 안의 comment처럼 git rm –cached index.html 하게 되면 staging area 에서 다시 workind directory로 내려보내게 된다.

git rm -r --cached .

현재 staging directory에 있는 모든 파일을 한꺼번에 다시 workind directory로 내리기.



commit

Staging 영역에 있는 파일을 repository에 저장하는 명령어.

git commit

입력해야할 커밋메시지가 긴 경우에 사용. 줄 바꿀이나 띄어쓰기가 가능. 이 명령어를 입력하면 디폴트 에디터가 출력됨. 에디터에서 메시지를 입력한 후 저장(esc + :wq)하면 커밋이 됨.

이 명령어를 입력하면 밑의 사진처럼 editor(vim)창이 출력이 됨.
(만약 출력 안되고 modified 어쩌고하는 화면만 보일 경우 git commit –a 입력하면 아래 화면이 나옴)

여기서 맨 윗줄에 넣고 싶은 메시지(여기서는 add index.html)를 입력하고 esc키를 눌러서 맨 밑줄로 이동한 다음,
:wq 를 입력함. 저장 후 나간다는 명령어.
이렇게 몇 개의 파일/줄이 추가되거나 삭제되었는지 알려준다.

git commit –m "커밋 메시지"

m은 메시지의 약자. 타이틀정도로 간략하게 메시지를 입력하는 경우에 사용.

git commit -a–m "커밋 메시지"

working directory에 있는 파일들이 staging area를 거쳐서 커밋되는 것이 일반적이지만, 이 명령으로 staging area를 거치지 않고 바로 커밋할 수 있게 됨.

<커밋이 가능한 경우>

git의 경우, 리포지토리 영역에 있는 파일이라도 한번 수정을 하게 되면 다시 working directory형태로 내려오게 됨.
이 경우에는 수정을 하고 바로 이 명령문을 통해 커밋을 할 수 있는 것.

예를들어,

현재 커밋이 완료된 index.html 이라는 파일이 있는 상태에서
echo "<html> </html>" > index.html로 index.html파일 내용을 변경하고 (아무 내용이 없었던 파일에 html태그를 추가한 것)
git status로 상태를 조회하면 아래처럼 modified 된 파일이 있다고 알려줌.
이 파일의 경우, 한번 커밋이 되었던 파일이기 때문에 staging area를 거치지 않고 바로 커밋을 진행할 수 있음.
이 화면이 뜨면 git commit –a –m "Added html tags" 라고 입력해서 커밋을 진행할 수 있게됨.


<커밋이 불가능한 경우>

이 명령어를 쓸 수 있는 건, 한 번이라도 staging area를 거쳤던 파일에 한해서이다!
새로운 파일을 생성했다면 git commit –a-m "커밋메시지"를 한다고 해도 그 대상에 포함되지 않음.

만일 staging area를 거치지않은 파일을 commit하려 한다면
nothing added to commit but untracked files present
라는 메세지로 커밋된 것은 없지만 staging area에 있지 않은 untracked files가 있다고 알려줌.



log

저장소에 있는 commit 이력을 조회하는 명령어.

git log

현재 브랜치의 커밋이력을 디테일하게 볼 수 있음. 타이틀 메시지, 컨텐츠 메시지, 누가커밋 했는지 등 전반적인 정보를 준다.
git commit 으로 제목 + 내용까지 상세하게 기록한 커밋은 아래처럼 내용까지 보여짐조회가 끝나면 'q로 화면나가기

git log --oneline

말 그대로 한줄(oneline으로)로 간단하게 보여달라는 명령어. 커밋이력 중 커밋 ID, 타이틀 메시지(에디터로 커밋했을 때 첫번째 줄에 있는 정보/ 혹은 -m뒤에 따라오는 정보)만 조회.

git log --oneline --decorate --graph --all

모든 브랜치의 커밋이력을 조회하게 됨. 브랜치가 한 개라면 단순하게 한 줄로 표시가 됨.

브랜치가 여러 개인 경우에 적합. (사진은 master에서만 작업했기 때문에 이렇게 보여짐)
--oneline : 한 줄로 간단하게
--decorate : 어떤 브랜치인지 --all을 빼고 입력하면 master를 포함해 모든 브랜치 내용을 볼 수 있음
(더 자세한 예시는 하단의 checkout 부분에 有)

git log -- [파일경로]    ❗️띄어쓰기 주의❗️

특정 파일의 변경 커밋내용만 조회. 위 화면은 git log -- index.html로 출력된 결과.



diff

다른 커밋과 working directory를 비교하는 명령어.
-표시는 삭제된 부분, +표시는 더해진 부분을 나타냄.

git diff

현재 브랜치의 마지막 커밋과 working directory의 차이점 비교.highlight된 부분처럼 어떤 부분이 달라졌는지 알려줌.

git diff [Commit ID]     *명령어에 대괄호[]는 입력하지 않음

특정 커밋과의 차이점 비교.
(명령어에 대괄호[]는 입력하지 않음)
예를 들어 사진처럼 id No.0f97c10을 비교해본다고 하면 이 명령은 아래와 같이 모든 파일의 커밋 정보를 다 알려줌.만약에 특정 커밋과 특정 파일만을 비교하고 싶다면 파일 경로를 같이 입력해주기.
(아래 명령어처럼)

git diff [Commit ID] -- [파일 경로]

특정 커밋의 특정 파일이 스냅샷이 찍힌 시점과 현재 working directory의 파일 내용이 어떻게 다른 지 비교.

  • 입력 예시:
  • 결과:


branch

브랜치 생성, 수정, 삭제를 하는 명령어.

git branch

브랜치 목록 조회. 위 화면은 'develop'이라는 브랜치와 'master' 브랜치가 있는 상태.
브랜치명 앞에 * 이 붙어있는 곳이 현재 위치.

git branch [브랜치명]

브랜치 생성.'git_branch' 라는 디렉토리 생성.

git init

특정 디렉토리를 git repository(master)로 지정하기.
cd git_branch로 git_branch 디렉토리 내부로 옮겨간 후에git init을 하게되면,
해당 디렉토리를 git repository로 만듦과 동시에 master가 생성된다. 이 때 ❗️주의할 점❗️
아래 화면처럼 아무런 커밋을 하지 않은 상태에서 브랜치를 만들려고 하면 오류가 난다!!
⬆️git log로 커밋내역을 조회했을 때 어떤 commit도 되지 않은 상태임을 확인할 수 있음.
이 상태에서 'develop'이라는 브랜치를 생성하려고 하면 나오는 메세지: fatal: Not a valid object name: 'master'

git branch -d [브랜치명]

브랜치 삭제. 'develop' 브랜치 삭제.
git branch로 모든 브랜치를 확인해보면 남은건 'master'브랜치 뿐.

git branch -m [oldName][newName]

브랜치 이름변경.
oldName: 현재 브랜치명
newName: 변경할 브랜치명
⬆️'develop'브랜치를 'test'로 변경.
git branch로 확인해보면 'test' 로 정상변경 됨.

git checkout -b [브랜치명]

브랜치 생성과 동시에 만들어진 브랜치로 바로 옮겨가는 명령어.



checkout

워킹 디렉토리의 소스를 특정 커밋으로 변경하는 명령어. 쉽게 말하면 내가 사용할 브랜치를 지정하는 행위.

git checkout [브랜치명]

특정 브랜치로 워킹 디렉토리 변경. 브랜치 이동하기. ⬆️checkout 전 상태 : master 브랜치에 있음(*이 앞에 붙은 브랜치가 현재 위치).

⬆️develop 브랜치로 현재 위치 변경(명령어: git checkout develop). develop 브랜치로 옮겨온 상태.
nothing to commit, working tree clean : develop 브랜치를 만들고 나서 소스(파일)수정을 전혀 하지 않았기 때문에 master랑 develop은 완전히 똑같은 상태(똑같이 커밋되지않은 random.html을 하나씩 가지고 있는 상태)임을 나타냄. ⬆️develop브랜치의 random.html파일에 태그 추가(소스 변경) 후 master로 checkout.
이 상태는 아직 add & commit을 하지 않은 상태이기 때문에 이 상태 그대로 master브랜치로 random.html이 옮겨짐. master브랜치로 가서 cat random.html으로 파일 본문 보게 되면 수정한 상태가 그대로 남아있음(여기도 add & commit은 되지않음).
이 상태에서 add & commit하면 master 브랜치에만 커밋이 됨.
develop 브랜치에는 처음 생성된 상태 그대로 보존되어 있음.

즉, 브랜치가 생성될 시점의 그 모습 그대로 유지가 된다. 생성된 이후에 부모 브랜치에서 어떤 것을 수정한다고 해도 자식 브랜치의 내용이 바뀌지는 않는 것!! 그래서 작업을 할 때는 어느 브랜치의 워킹디렉토리에서 작업을 했는지 반드시 기억해야한다!!!

만일 어느 브랜치에서 작업했는지 기억이 나지 않을 때는 git log --graph –-oneline –-decorate –-all로 모든 브랜치의 변경된 사항 조회해 볼 수 있음.

다른 예로,
master의 자식브랜치 중 하나인 release 브랜치에서 about.html이라는 파일을 만들고 add&commit을 한 후,
master에 다시 가서 ls로 모든 파일 목록 확인해보면 master에서는 about.html파일을 찾을 수 없다.
처음에 만든 index.html만 보여짐. ⬆️git log --graph --oneline --decorate --all로 그래프를 보면 그래프 상에서 master브랜치가 가장 밑에 있기 때문에 위에 위치한 release브랜치에서 만든 파일들이 master에서 보여지지 않는 것! 같은 원리로 develop브랜치에서도 about.html이 보이지 않음.

그래서,

⭐️ 파일을 만들거나 수정할 때 주의할 점 ⭐️
✔️ 현재 내가 작업하고 있는 브랜치가 어디인지 git branch로 꼭 확인하기!!
✔️ 엉뚱한 디렉토리에 작업파일 저장되지 않도록 주의하기

git checkout [Commit ID]

특정 커밋으로 워킹 디렉토리 변경.
커밋이 완료된 상태에서 특정 커밋으로 가고 싶을 때는, git log --oneline으로 Commit ID를 확인해서 옮겨가면 된다.
⬆️지금 master브랜치에 있는 index.html파일은 저렇게 태그가 추가 되어있는 모습.
만약에 그 전 커밋된 cc97215로 가고 싶다면 git checkout cc97215로 옮겨갈 수 있음 현재는 cc97215로 옮겨온 상태.
여기에서 다시 cat index.html로 파일 내용을 확인하면 Index.html에 아무 내용도 없음.
즉, cc97215이라는 커밋에는 index.html에 아무것도 없었던 상태.
하지만 또 다시 master로 돌아가면, ⬆️이렇게 추가가 되어있는 걸 확인할 수 있음.

git checkout [Commit ID] -- [파일경로]

특정 파일을 해당 브랜치 또는 커밋 상태로 변경.위 예제에서 보면 master브랜치의 index.html파일에는 태그들이 추가가 되어 있는 상태.
예를 들어, 만약에 7800fa1라는 커밋이 잘못된 커밋이라 다시 cc97215상태(태그가 없는 상태)로 되돌리고 싶다면,
Commit ID -- 파일명 으로 변경하기 ⬆️변경 후에는 이렇게 index.html이 태그 추가 전 상태로 돌아가서 아무것도 없는 걸 확인 할 수 있음.



merge

다른 두개의 소스를 병합하는 명령어.

git merge [브랜치명]

Git에서는 병합하는 방법이 2가지 있음.
1) rebase - 이력을 다듬어야 할 때. Git의 flow를 정확히 이해해야 사용할 수가 있다.
2) merge - 단순히 명령만 입력하면 병합이 됨.

예를 들어 develop브랜치를 master로 병합한다고 할 때,
1. 제일 먼저 git checkout master로 옮겨가고,
2. git merge develop을 하게 되면 develop이 master에 병합이 됨.

⭐️CONFLICT 주의⭐️

merge가 항상 잘 되는 것은 아님!!!
다른 브랜치에 같은 파일이 다른 내용으로 있으면 충돌하기 때문에 merge가 되지 않음!! 사용자가 저장을 원하는 버전을 수동으로 지정해줘야 함!
이렇게 자동으로 merge되지 않는 부분을 "CONFLICT"라고 함. 따라서 git status로 진행 중간중간 상태확인하는 습관이 필요함. conflict 시에는 아래처럼 경고 메시지가 나옴.
같은 부분을 서로 다르게 수정했을 때 나오는 conflict 화면:이 때 git status로 상세내용을 살펴보면 아래와 같이 보여짐:이럴때는 vim 파일명으로 충돌된 파일에 들어가서 충돌되는 부분 확인: develop브랜치에 있는 부분이 틀렸다고 가정하고 hightlight되어 있는 부분들을 모두 삭제 이렇게 필요없는 부분 모두 지운후에 :wq로 다시 저장 그리고 다시 git add & git commit으로 커밋을 해주면 완벽하게 고쳐짐. 수정을 완료한 후,
git log –-decorate –-graph 로 그래프 형태를 조회해보면, 화살표가 develop브랜치에서 master로 merge되는 모습을 확인할 수 있음❗️



vim

터미널에서 파일 내용(본문)을 수정하는 명령어.

vim [파일경로]

(내용 추가 후) esc + :wq 저장

파일이 있는 곳으로 가서 위 명령어 입력하면 밑 화면처럼 수정할 수 있는 vim화면으로 넘어감. ⬇️vim index.html한 모습. 추가할 내용 적어 넣고 저장은 esc키 + :wq 로!



remote add

로컬 repository를 원격 repository와 연동을 하려면 로컬 저장소에 원격 저장소 URL을 등록해줘야 한다.
즉, 로컬 저장소에 원격 저장소 URL을 등록해서 연동하는 명령어.

git remote add [alias별칭][gitURL] *alias는 별명을 만드는 명령어. 명령어를 단축시키기 위한 별칭을 만드는 것.

Ex. remote add origin https://github.com/ha3158987/repository-testing

보통 alias별칭은 default인 'origin' 그대로 쓰는 경우가 제일 많지만 바꾸고 싶다면 위 명령어를 입력하면서 alias별칭 자리에 원하는 이름을 적어넣으면 된다!

  1. 버전관리를 하고자 하는 프로젝트의 디렉토리를 만든 후, git init으로 initialize 하기
  2. 그리고 바로 git remote add 별칭 git리포지토리url 로 추가
  3. 그 다음에 git remote –v로 조회하면 밑 화면처럼 alias이름, git repository url 순으로 연결이 된 게 보여짐.


fetch & pull

원격 repository에 있는 내용을 로컬 repository로 다운로드 하는 명령어.

git fetch [alias별칭][브랜치명]

Ex. git fetch origin

  1. 먼저 git remote -v로 로컬 repository와 원격 repository의 연동현황을 조회하고,
  2. git fetch github으로 다운로드 해오기

참고로 fetch명령어는 working directory에 변경을 주지는 않음.
반면, pull은 fetch와 같은 동작을 수행하지만 원격저장소의 내용을 로컬 저장소로 받고, 자동으로 merge 까지 수행함(fetch + merge의 효과). Working directory에 바로 반영됨.

git pull [alias별칭][브랜치명]

Ex. git pull origin

이렇게되면 로컬에 만들지 않은 파일들(예를 들면 README파일이나 License 파일 등)도 merge 하면서 같이 저장이 된다❗️



push

로컬 repository의 내용을 원격 repository로 업로드 하는 명령어.

git push -u [alias별칭][브랜치명]

Ex. git push –u origin master
(origin이라는 repository에 master브랜치의 현재 소스를 올리고자 할 때)

리포지토리 생성 후 나오는 화면 중에 아래 화면에 나온 부분이 기존에 있는 리포지토리를 업데이트 하는 가이드라인 ⬇️

정상적으로 push가 완료 되면 아래 화면처럼 보여짐.



clone

공개된 원격 저장소에서 다운로드를 하는 명령어.

git clone [url]

Ex. git clone http://github어쩌고
단순히 복제한다고 생각하면 된다.


Reference

본 포스팅은
권오성님의 '누구나 쉽게 배우는 Git(깃) & Github(깃허브)' 강좌 내용을 기반으로 하였습니다.

링크: https://www.udemy.com/course/how_to_start_git_and_github/

profile
프린이의 코묻은 코드가 쌓이는 공간

1개의 댓글

comment-user-thumbnail
2023년 1월 10일

많은 정보 얻고가요~ 감사합니다!

답글 달기