1. Git 시작하기

git init

• 해당 폴더에 빈 레포지토리 생성 (git 버전관리의 시작)

git config user.name "MinhyeongS"

git config user.email "alsuddl25@icloud.com"

• 첫 커밋 하기 전 사용자와 사용자의 이메일 설정

git config alias.[바꿀명령어] '원래 명령어'

git config alias.history 'log --pretty=oneline'

• git log --pretty=oneline 을 git history 로 변경해서 사용

git add 파일명/디렉토리명

• 커밋할 파일을 staging area에 추가
• 디렉토리를 add 할 경우 디렉토리 내의 모든 파일이 staging area에 추가됨

git add .

• 현재 프로젝트 디렉토리 내에서 변경사항이 생긴 모든 파일들을 staging area에 추가

git commit -m "커밋메세지작성"

• 커밋과 동시에 커밋메세지 작성

git commit

• m 옵션 없이 commit할 경우 텍스트편집프로그램에서 Commit Message를 작성해서 남길 수 있음. 복잡하고 긴 커밋 메세지를 남길 수 있다.
• mac - vim 사용됨. i (메세지 편집) -> esc -> :wq 엔터

git status

• 깃이 인식하고 있는 프로젝트 디렉토리의 현재상태를 보여준다.
  

git help [알고 싶은 커맨드 이름]

man git-[알고 싶은 커맨드]

• 사용법 확인하기

2. GitHub

(1) GitHub 시작하기

git remote add origin [GitHub 상 프로젝트 주소]

내 컴퓨터의 로컬 레포지토리와 GitHub의 리모트 레포지토리를 연결하는 첫 번째 작업

• [GitHub 상 프로젝트 주소]가 가리키는 리모트 레포지토리를 origin이라는 이름으로 내 컴퓨터에 등록하겠다는 뜻
• 이 때 다른 이름을 붙여도 되지만 관례상 origin 이 쓰인다.

git push --set-upstream origin [main/브랜치이름]

git push -u origin main

• 로컬 레포지토리의 내용을 처음으로 GitHub의 리모트 레포지토리로 보낼 때!
• 리모트 레포지토리에 main 이라는 이름의 브랜치가 생성되고, 로컬 레포지토리의 main 브랜치가 리모트 레포지토리의 main 브랜치를 tracking 하도록 설정
• 이후 또 로컬 레포지토리 -> GitHub의 리모트 레포지토리 => git push

git clone [프로젝트의 GitHub상 주소]

• 다른 사람의 프로젝트 내 컴퓨터에 가져오기
• 작업 중인 프로젝트 폴더가 아닌 다른 곳에서 저장할 것

(2) remote repository 사용하기

git push

• 로컬 레포지토리의 새로운 커밋을 리모트 레포지토리로 전송

git push -f

• 로컬 레포지토리의 내용으로 리모트 레포지토리의 내용을 밀어버리고 덮어쓰기(force 의 f)
• 혼자 작업하는 경우에만 사용하기!!

git pull

• 리모트 레포지토리의 새로운 커밋을 로컬 레포지토리로 받아오기
• git pull = git fetch + git merge
• 리모트 레포지토리의 브랜치를 검토할 필요 없이 바로 합치고 싶을 때 사용
• 협업 시 자주 발생하는 상황
  
  내가 로컬 레포지토리에서 추가 커밋, 다른 사람이 다르게 커밋한 것을 이미 push해놓은 상태. 이미 리모트 레포지토리에 더 최신 커밋이 있어 push 불가
  

1. 일단 먼저 git pull할 것!
2. 이 때 발생하게 되는 Conflict 해결
3. git add .
4. git commit
5. git push

git fetch

• 리모트 레포지토리에 새로운 커밋이 있을 때 머지하지 않고 일단 가져오기만 하는 것
• 리모트 레포지토리에서 가져온 브랜치의 내용을 머지하기 전에 검토할 필요가 있을 때 사용
  

git revert [취소할 commit ID 4자리]

• 이미 Remote Repository에 올라간 커밋을 취소해야 할 때 사용
• 로컬에서 커맨드 사용
• 해당 커밋을 취소한 상태로 추가 커밋이 생긴다.
• 그 후 git push!
  
• git reset과 비교
  

git revert [commit ID(1)][commit ID(2)]

• (1)의 다음 커밋~(2)커밋까지 한꺼번에 취소
  
• 그 후 git push!

3. Git에서 커밋 다루기

git log

• 커밋 확인하기
  

git log --pretty=oneline

• 커밋 하나당 한 줄로 보여주기 (현재 브랜치만 표시)

git log --pretty=oneline --all

• 커밋 하나당 한 줄로 보여주기 (모든 브랜치 표시 but 브랜치 구분없이 커밋순서대로 보임)

git log --pretty=oneline --all --graph

• 커밋 히스토리가 각 브랜치와의 관계가 잘 드러나도록 그래프 형식으로 출력

git show [commit ID(최소 4글자)]

• 하나의 커밋에 대한 자세한 정보 확인

git show [태그 이름]

• 각 태그와 연결된 커밋 보여줌

git commit --amend

• 가장 최신 커밋 수정
• commit ID 가 변함
  

git diff [이전커밋][이후커밋]

• 두 커밋 간의 차이점 확인. 두 커밋 사이의 변화 조회
• 브랜치 명을 쓰면 브랜치 간의 차이점 조회

git blame [파일명]

• 해당 파일의 내용 한줄한줄이 각각 어떤 커밋에 의해 탄생했는지를 확인

git reset 파일명/디렉토리명

• git add를 취소하는 것
• staging area에서 제거됨.
• 수정된 부분은 변동 없이 그대로 수정되어 있는 상태.
  (이 상태에서 git status를 하면 not staged, modified 상태로 확인됨)

git reset [옵션][HEAD로 설정할 커밋 ID]

git reset --hard e5f7

• HEAD가 해당 커밋을 가리키게 함.
• working directory의 내용도 과거 커밋의 모습으로 돌아감.
• 과거의 커밋으로 git reset을 한다고 그 이후의 커밋들이 삭제되는 게 아니라 계속 남아있다.
• git reset은 과거의 커밋뿐만 아니라 현재 HEAD가 가리키는 커밋 이후의 커밋으로도 할 수 있다.
• reset 옵션들 : --soft, --hard, --mixed
• HEAD^ : 현재 HEAD가 가리키고 있는 커밋의 바로 이전 커밋
• HEAD~x : 현재 HEAD가 가리키는 커밋보다 x단계 전에 있는 커밋
  
  1. HEAD가 특정 커밋을 가리키도록 이동시킴(--soft는 여기까지 수행)
  2. staging area도 특정 커밋처럼 리셋(--mixed는 여기까지 수행)
  3. working directory도 특정 커밋처럼 리셋(--hard는 여기까지 수행)

git reflog

• HEAD가 가리켰던 commit들의 id 확인하기
• git reset 으로 이전 commit으로 갔다가 돌아올 때 git reflog를 통해 commit ID를 확인하여 돌아올 수 있다.

git tag [태그 이름][커밋 아이디]

• 특정 커밋에 태그를 붙임

git tag

• 이 프로젝트 디렉토리에 있는 모든 태그를 조회

git show [태그 이름]

• 각 태그와 연결된 커밋 보여줌

4. Git에서 branch 사용하기

git branch [branch 이름]

• 브랜치 생성
• 로컬에서 branch 생성 후 리모트레포지토리로 처음 보낼 때
  : git push --set-upstream origin [branch 이름]

git branch

• 해당 프로젝트 내의 모든 브랜치 조회

git branch -d [branch 이름]

• 해당 브랜치 삭제

git checkout [branch 이름]

• 해당 브랜치로 이동
• HEAD가 해당 브랜치를 가리키도록 하는 것

git checkout -b [branch 이름]

• 브랜치 생성과 동시에 해당 브랜치로 이동

git checkout [commit ID 4자리]

• HEAD가 직접 해당 커밋을 가리키도록 하는 것. (Detached HEAD 상태)

git merge [branch 이름]

• 현재 브랜치에 해당 브랜치 내용 병합
• Conflict 해결방법
  (1) 컨플릭트가 발생한 파일을 연다.
  (2) 머지의 결과가 되었으면 하는 모습대로 코드 수정
  (3) 커밋

git merge --abort

• Conflict 발생시 머지 취소

5. 실전에서 유용한 커맨드들

git stash

• 작업내용 임시 저장
• working directory에서 작업하던 내용을 깃이 따로 보관(stack)
• 작업하던 내용을 아직 커밋하지 않았는데 branch를 옮겨야 할 경우 작업 내용이 사라지기 때문에 stash 후 이동하면 된다. 쓸데없는 커밋을 만들지 않아도 됨!

git stash list

• 스택에 저장이 잘 됐는지 확인
• stash 가 여러개 있을 경우 가장 최근에 저장한 stash부터 역순으로 목록 보여줌.

git stash apply

• 스택에 있는 내용 working directory로 불러오기
• 가장 마지막에 저장한 stash 를 가져옴
• 꼭 같은 브랜치에서만 적용할 수 있는 것은 아니므로 잘못된 브랜치에서 작업하던 것을 stash하여 다른 브랜치에서 불러올 수도 있다.

git stash [작업내용 ID]

• 가장 최근 stash가 아닌 특정 stash를 가져오고 싶을 경우 사용

git stash drop [작업내용 ID]

• 필요 없는 stash 삭제

git stash pop [작업내용 ID]

• 작업 내용을 적용하면서(현재 working directory로 가져오면서) 동시에 스택에서 제거
• [작업내용 ID]를 인자로 주면, 특정 작업 내용을 적용하면서 스택에서 제거
• [작업내용 ID]를 인자로 주지 않으면, 가장 최근에 한 작업내용을 적용하면서 스택에서 제거

git rebase [branch 이름]

• 깔끔한 커밋 히스토리를 원할 때 사용
  1. git rebase [branch 이름]
  2. Conflict 해결
  3. git add .
  4. git rebase --continue
  

git cherry-pick [불러올 commit ID]

• 테스트 했던 여러가지 커밋들 중에서 필요한 커밋만 불러오고 싶을 경우 사용
• 특정 커밋의 내용만 현재 커밋에 반영
• conflict 해결 후 add, commit

git revert [취소할 commit ID 4자리]

• 이미 Remote Repository에 올라간 커밋을 취소해야 할 때 사용
• 해당 커밋을 취소한 상태로 추가 커밋이 생긴다.
• 그 후 git push!
  
• git reset과 비교
  

git revert [commit ID(1)][commit ID(2)]

• (1)의 다음 커밋~(2)커밋까지 한꺼번에 취소
  
• 그 후 git push!

(참고)sourcetree 튜토리얼 문서

https://support.atlassian.com/bitbucket-cloud/docs/tutorial-learn-bitbucket-with-sourcetree/