Git 명령어 정리

1.  초기세팅

• 이름 설정 : git config --global user.name "이름"
• 이메일 설정 : git config --global user.email "이메일”

2.  로컬레포지토리 관련

- git init : git 저장소를 생성 / 버전 관리를 위한 정보 생성 → 새로운 디렉토리를 만들고 그 폴더에서 git init을 쓰게 되면 깃 명령어를 쓸 수 있도록 세팅이 된다.

- git status : git 상태를 확인하는 명령어

- git add : 파일 수정 이력 기록 준비 → 수정사항을 스테이징 하는 명령어

• git add 파일이름 : 특정 파일만 이력을 남기고 싶을 때
• git add . : 현재 위치한 폴더의 변경된 파일 전체의 이력을 남기고 싶을 때.

- git commit : 파일 수정 이력을 기록 → 수정사항을 커밋하는 명령어

• git commit -m “메세지” : 커밋 메세지를 한 줄로 추가해 커밋하는 명령어
• git commit : 여러줄로 메시지를 남기고 커밋하는 명령어

- git log : 커밋 이력을 확인하는 명령어

- git checkout <commit-hash> : commit-hash를 git log 에서 보이는 커밋의 실제 hash값으로 대체하면 해당 커밋 시점의 코드로 되돌릴 수 있다.

- git push : 로컬 레포지토리에 있는 코드를 원격 레포지토리(깃헙)에 업로드하는 명령어

- git push origin(원격레포지토리 별명) [브랜치 이름] : origin 원격 레포지토리에 새로운 브랜치를 만들고 코드를 올린다. 작업중인 로컬 브랜치가 원격에 있으면 git push만 해도 된다.

- git pull origin main(or master) : 원격 레포지토리의 메인에 있는 내용을 내 메인(or 마스터)브랜치로 pull한다. 따라서 나는 이 작업을 하려면 메인 브랜치로 이동해 있어야 한다.

3. 브랜치 관련

- git branch <new-branch-name> : 새로운 브랜치를 생성하는 명령어

- git checkout <branch-name> : 원하는 브랜치로 이동하는 명령어

- git checkout -b <new-branch-name> : 새로운 브랜치를 생성하고 해당 브랜치로 이동하는 명령어

- git branch : 프로젝트에 존재하는 브랜치를 확인할 수 있는 명령어

- git merge <branch-name> : 다른 브랜치를 현재의 브랜치와 병합하는 명령어

→ 이건 github 들어가서 풀리퀘스트 하는 것이 나을 듯?

- git branch -d <branch-name> : 브랜치를 삭제하는 명령어.

4. GitHub 사용법

Common Workflow : 내 로컬 Repository를 GitHub에 push하기

• 로컬에서 add/commit한다.
• github으로 이동 후 새 repository를 생성한다
• 나의 로컬 repository를 github repository와 연결한다.(remote추가)

→ git remote add origin [깃헙레포지토리 주소] : 로컬 repository와 github repsitory를 연결

→ git push origin master : 커밋한 로컬 레포를 깃헙 레포의 브랜치로 푸쉬하는 명령어

 

📌 일반적인 스테이징 → 커밋 → 푸쉬 방법

1. git add 파일이름 또는 전체 스테이징시 ‘ . ’

2. git commit -m "Change greeting"(한줄 코멘트)

→ 여러줄 코멘트는 git commit

3. git push origin master(브랜치 이름)

 

📌 깃헙에 있는 레포를 로컬 레포로 클론하는 명령어

→ git clone <github-repo-link>

 

📌 기타

• Ignoring files : staging area에 추가하고 싶지 않거나 git에서 관리하지 않아도 되는 파일은 .gitignore 파일을 프로젝트 폴더에 성생해주면 된다. 그 안에 해당하는 파일명과 폴더명을 나열하면 된다. ( 각 파일, 폴더가 새로운 줄에 입력되어야 한다.)

 

예시
.DS_*
.log
logs
**/.backup.*
**/.back.
node_modules
bower_components

📌 깃헙 레포지토리 관련

- git remote add origin [깃헙레포지토리 주소]

- git branch  -b <new-branch-name>

- 로컬에서 폴더 만들고 그 폴더에서 깃 명령어를 쓰기 위해서 git init

- 이력을 남기기 위해서 스테이징 → git add

- 진짜 이력을 남기기 위해서 → git commit

- 코드를 깃헙에 올리는거 → git push origin main : 오리진을 메인에 푸쉬한다. 오리진은 지금 내가 만든 브랜치의 별명이다.

 

 

5. 이미 올린 Pull request 수정하기

1. Review 받은 내용 수정 후 git add하기

2. git commit --amend를 통해 최신 commit 덮어쓰기

3. git push -f origin branch-name

 

위 과정을 진행하면 수정한 부분이 자동으로 PR에 반영이 되므로 다시 PR을 하지 않아도 된다!

- 출처 : https://kimtaehyun98.tistory.com/119

 

=> commit --amend는 멘토님께서 비추천 하셨다. 어찌 됐든 수정한 내역을 남기는 것이 올바르다는 말씀.

본래의 목적은 commit message를 변경하기 위함이므로, 코드가 바뀌지 않았을 때에 한해 사용하는 것이 좋을 것 같다는 생각.

 

6. 커밋 메시지 가이드라인

- 참고 : https://webruden.tistory.com/486

📖 멀티라인 커밋 작성 방법

1. git commit → 에디터 열림
2. 에디터에서 아래 template에 맞춰 커밋 메세지 작성
3. :wq 로 저장

✅ 분류

• Add - 레이아웃 / 기능 추가
• Remove - 내용 삭제 (폴더 / 파일 삭제)
• Modify - 수정 (JSON 데이터 포맷 변경 / 버튼 색깔 변경 / 폰트 변경)
• Fix - 버그/오류 해결
• Refactor - 코드 리팩토링 (멘토 리뷰 반영 / 스스로 리팩토링 / 중복 코드 제거 / 불필요 코드 제거 / 성능 개선)
• Docs - 문서에 관련된 수정작업(README.md 등)

🧾 Template

분류: 한줄 제목
- 구현내용 detail
- 구현내용 detail

 

📌 예시 1 - Add

Front-end

Add: 이미지 슬라이더 추가
- 메인페이지 이미지 슬라이더 구현
- 3초 간격으로 자동으로 넘어가는 기능 구현

Back-end

Add: User app 생성 및 회원가입 엔드포인트 추가
- 유저 앱을 만들고, 유저 모델 클래스 생성
- 회원가입 엔드포인트 구현

 

📌 예시 2 - Remove

Front-end

Remove: 불필요 컴포넌트 삭제
- MyPage 가 더 이상 필요없어짐에 따라 파일 삭제

Back-end

Remove: data csv 파일 삭제
- 크롤링 결과 저장한 csv이 git에 잘못 올라와 해당 파일 삭제

 

📌 예시 3 - Fix

Front-end

Fix: 스크롤 버그 수정
- 스크롤시 Navbar 사라지는 버그 확인 후 수정

Back-end

Fix: 상품 정보 입력시 필수 정보인 상품 사진 url 예외처리
- 필수 입력 값인 image url이 body에 담겨있지 않을 때 key error 오류 처리
- Return되는 오류 메시지 수정 (500 error -> 400 key error with 'image_url')

 

 

7. Git에서 Conflict(충돌) 해결하기

git으로 작업 하다가, 현재 브랜치에서 다른 브랜치로 머지할 경우 conflict가 발견할 때가 있다.

특히 프로젝트를 하면서 다른 사람들과 협업을 하고 있어서 main 브랜치에 변경된 내용으로 인한 conflict,

또는 PR에 대한 merge권한이 나에게 없어서, pr 후 다른 작업 도중 관리자가 pr을 merge하여, merge된 내용을 pull 또는 merge로 당겨올 때 conflict가 생길 수 있다.

 

즉, 두 브랜치의 동일한 파일에 상반된 내용이 있을 때 충돌(conflict)가 발생한다.

이럴 때는 두 가지 중 어떤 내용을 머지의 결과로 해야할지 git은 모르기 때문에 사용자가 결정해주어야 한다.

 

이 때, 사용자가 할 수 있는 action은 크게 2가지 인데,

1. 일단은 merge or pull을 취소하고 원래 상태로 돌아온다.

2. conflict를 해결하고 merge를 완료한다.

 

아마 대부분 2번을 선택하고 진행하고자 할 것이다.

 

충돌이 발생한 지점(파일)의 작업이력을 보고

원래 브랜치의 내용으로 merge 하고자 한다면, 가져온 브랜치의 내용을 삭제하고

가져온 브랜치의 내용으로 merge 하고자 한다면, 원래 브랜치의 내용을 삭제한다.

또는 두 내용 모두 삭제하고 머지의 결과로 원하는 새로운 내용을 입력해도 된다.

 

충돌된 내용을 수정한 후 git add, commit하면 된다.

-참고 : https://blog.naver.com/PostView.naver?blogId=codeitofficial&logNo=221938658754&redirect=Dlog&widgetTypeCall=true&directAccess=false 

 

8. pull과 merge의 차이?

- 참고 : https://ssaemo.tistory.com/74

[git] merge, git pull, branch 팁/노하우

 

9. Git add, commit, push 취소하기

- 참고 : https://gmlwjd9405.github.io/2018/05/25/git-add-cancle.html

 

10. Git stash

- 참고 : https://worker-k.tistory.com/entry/git-stash-%EC%82%AC%EC%9A%A9%EB%B2%95-%EA%B9%83-%EC%8A%A4%ED%83%9C%EC%8B%9C%EB%8A%94-%EC%96%B4%EB%96%A4%EC%83%81%ED%99%A9%EC%97%90%EC%84%9C-%ED%95%84%EC%9A%94%ED%95%A0%EA%B9%8C-branch-commit%EC%9D%98-%EA%B0%9C%EB%85%90%EA%B3%BC-%EB%8B%A8%EC%9C%84

 

- 참고 : https://www.lainyzine.com/ko/article/git-stash-usage-saving-changes-without-commit/

 

git stash 명령어는 혼자일 때 보다 팀 프로젝트를 할 때 많이 사용하게 된다.

 

branch, 브랜치는 원래 작업 내용 하나당 하나의 브랜치를 만들고 그 이슈가 해결되면 메인에 머지하여 그 기능을 다하면 삭제하는 방식으로 관리한다.

 

commit, 커밋은 '논리적으로 구성되며 일관성이 유지되는 최대한 짝게 쪼개야 한다.' 협업할 때 함께 협업하는 사람들이 커밋을 보고 명료하게 이해될 수 있도록, 그리고 추적이 용이하도록 1개의 commit에는 1개의 변경단위만 포함되어야 한다는 말이다. 즉, 우리가 위에서 보았던 커밋 분류를 혼재해서 사용하는 것은 바람직하지 않다는 것이다. (Add와 remove를 함께 하는 작업이 예를들면 바람직하지 않다고 할 수 있겠다)

 

stash

그런데, 프로젝트를 하다보면 동시다발적으로 처리할 일들이 생긴다. 작업 중 갑작스럽게 다른 기능의 버그를 처리해야 한다거나 우선순위가 앞선 일들을 먼저 처리해야 하는 경우가 생긴다. 그럴 때는 다른 이슈에 관련된 branch를 만들고 checkout 해야한다. 그러나, 다른 branch로 checkout 하려면 반드시, 꼭 commit을 해야한다. 그런데 마무리하지도 않은 작업을 commit, push하는 것은 위의 설명에 의해 올바르지 못하다. 그래서 임시 저장 용도로 사용하는 것이 stash이다.

- git stash : 변경내용 임시 저장하기

- git stash list : stash 했던 내용 보기

- git stash apply : 가장 최근의 stash 가지고 오기

- git stash apply stash@{1} :  특정 stash 가지고 오기 (stash 명은 stash list 참고)

- git stash drop : 가장 최근 stash 지우기

- git stash drop stash@{1} : 특정 stash 지우기 (stash 명은 stash list 참고)

- git stash clear : 한번에 stash 모두 지우기

- git stash pop : 가장 최근 stash를 적용하고 동시에 stack에서 지워줌 (apply + drop)

- git stash pop stash@{1} : 특정 stash를 적용하고 동시에 stack에서 지워줌 (apply + drop _ stack 명은 stack list 참고)

- git stash save stash이름 : stash를 원하는 이름으로 저장하기

stash list는 아래 이미지 처럼 바로 전 commit 메시지와 index만 보인다. 그래서 나중에 스텍이 쌓여잇으면 이 스텍이 무슨 작업을 stash한 것인지 알 수 없으므로 이름을 저장해주면 효율적이라고 한다.