[GitGithub] 깃, 깃허브 제대로 배우기(2)

yoon052·2023년 4월 2일
0

GitGithub

목록 보기
2/3
post-thumbnail
  • tip

⇒ 터미널에서 방향키 위 버튼을 누르면 이전의 명령어들을 확인할 수 있음

⇒ master에서

(노랑색) 변경되었으나 아직 커밋되지 않았음 ↔ (녹색) 커밋됨

표시는 모두를 의미한다. ex) .txt

git 명령어

  • git status → 현재 파일들의 상태들을 확인할 수 있음

마스터 브랜치 위에 있고, 아직 커밋은 안했음. untracked 상태의 파일 3개가 있음

  • git add → untracked 상태의 파일을 working directory 에서 staging area 로 옮겨줌

ex ) git add a.txt → a.txt 를 working directory 의 untracked 에서 staging area 로 옮김

txt 를 통해 b.txt 와 c.txt 도 staging area 로 옮겨짐


git rm —cached * ⇒ staging area의 파일들을 모두 working directory 로 옮기는 명령어

*와 . 의 미묘한 차이가 존재한다.

전체 파일을 추가할 때는 를 사용하면 편리하게 전체가 추가된다. →

만약 a,b,c 파일을 * 로 추가한 후, a가 삭제된다고 할때 . 를 통해 git add . 를 사용하면 b,c가 추가된다. → .

  • gitignore → git에 올리고 싶지 않은 것들을 gitignore에 저장

  • git status -h → git status 에 대한 옵션들을 -h(help) 를 통해서 확인가능

    git status 에 옵션 없이 적용되었을 때는 git status —long 이 적용됨 (default)


  • git status -s → -s(short) 로 간단한 버전으로 확인.

A : c.txt , style.css 라는 파일이 추가 되었고, staging area 에 위치하는 것을 간단하게 확인가능

?? : 아직 tracking 이 되지 않은 gitignore 는 working directory 에만 존재

AM : c.txt 는 staging area 에 추가되었고, working directory 에는 수정되었음

⇒ 간단히 status 확인하고 싶으면 -s 옵션을 사용하고, 더 상세하게 확인하고 싶으면 git status 사용


  • git diff → 정확히 어떤 파일이 수정되었는지 확인할 때 사용 (파일 비교)

옵션이 없다면 working directory 에 있는 파일들만 비교함

ex ) 상단의 이미지에서 a(이전버전)/c.txt 와 b(현재버전)/c.txt 을 비교하는 화면임을 알 수 있음

“ -1 (이전 파일) 에서 +1 (첫번째 줄) 부터 , 2(두번째 줄) 까지 확인하시오 “ 라는 의미

+add → “파일에 무엇인가가 추가되었다” 라는 의미


cat 을 통해 c.txt 의 내용을 확인함


hello world! 와 add 가 내용으로 있는데, hello world! 는 staging area 에, add는 working directory에 있음 → git diff 는 working directory 에 있는 파일들만 확인하기 때문에 add만 보였던 것임

  • git diff —staged → staging area 에 있는 내용들도 확인가능
  • git diff —cachedgit diff —staged와 동의어로 사용. staging area = cache
  • git diff -h → -h(help) 를 통해 git diff 의 옵션들을 확인가능
  • git difftool → vscode 로 확인가능
  • git difftool —staged → vscode 로 staging area 에 있는 내용들까지 확인가능

  • git commit

git log 를 통해 커밋 내용(m) 을 확인가능. 보통 git commit 단독으로 사용하지는 않음

git commit -m “first commit” 이런 식으로 옵션을 붙여서 명령어를 사용

  • commit 팁

깃 히스토리(history)는 버전별로 관리하는 것이 장점. 히스토리에 모든 내용을 한 번에 넣기보다는, 작은 단위로 나눠서, 히스토리에 저장하는 것이 좋음. 의미가 있는 이름을 지정해 커밋을 하는 것이 추후 히스토리 리뷰할 때 편리. 의미가 있는 이름은 기능별로 세분화된 기능 관련 동사를 붙이는 것이 보통 관례임

커밋은 너무 커도 문제지만, 너무 작아도 문제. 어느 정도 의미있는 단위로 나누는 것은 실제 프로젝트를 하면서 알아갈 수 있음.

  • UI, sorcetree로 commit 하기

UI 의 기본 형태를 보면 좌측 아래위로 staged, unstaged files 로 나뉘어져 있음

해당 파일을 선택을 통해 아래위로 보낼 수 있음

라인별로 단락별로 stage 설정을 할 수 있고, 하단에 커밋 메시지를 작성후 커밋 버튼을 실행하면 커밋

다른 탭에 history 를 확인하면, 여태까지 커밋한 기록이 남아있어 확인가능

profile
개발자 지망생

0개의 댓글