GIT 사용법 총정리

■GIT■

●필수 리눅스 명령어●
(터미널: git bash(윈도우), terminal, iterm(맥os), vscode)
TIP. 데스크탑의 폴더를 더블 클릭해서 들어간 것과 같은 효과.

1. pwd(prind working directory)
   a. directory는 쉽게 말해 folder 즉, ‘저장소’라 보면 된다.
   b. “현재 내가 작업하고 있는 폴더를 보여줘”
   c. ~표시: Home경로. Desktop(바탕화면)이라는 디렉토리 보다 더 상위에 있는 폴더.
   / Users/shy 와 같은 것으로 생각하면 됨.

2. ls(list)
   a. "현재 위치 해 있는 디렉토리 안에 있는 폴더 & 파일 내역을 보여줘.“

3. ls -a(list -all)
   a. ”숨겨진 파일(보통 .으로 시작)도 모두 보여 줘.”
   b. 일반인들은 볼 필요가 없는 컴퓨터 자체 설정파일, 폴더 등.

4. cd 폴더명(change directory)
   a. "(ls 명령어에서 확인된)폴더로 이동"
   b. cd만 치면 다시 home directory로 되돌아가 진다.
   c. cd.. : "한 단계 위의 폴더로 이동해줘"
   d. cd 폴더명/폴더명 : “한 번에 더 깊이 들어가기”

5. mkdir 폴더명 (make directory)
   a. "현재 경로에서 “폴더”를 생성해줘"

6. touch 파일명
   a. "현재 경로에서 “파일” 생성해줘"
   b. 정확히는 파일의 생성뿐만 아니라, 날짜와 시간을 변경하는 명령어

TIP. Clear : 터미널이 전부 지워진다.

●Git＆Github의 개념●

1. Git: 코드 변경점 기록 (버전 관리 도구: 소프트웨어의 변경사항을 체계적으로 추적,통제)
   a. 고민점: 파일, 폴더 복사 없이 변경 기록 가능한 시스템이 없을까?
   b. 하나의 폴더 내에서 코드의 변경점을 기록하기 위해 사용

• 단계별로 기록을 해놓아서, 에러 발생 시 과거의 코드 기록으로 쉽게 돌아가기 가능

2. Github: 백업과 공유, 협업 가능한 온라인 코드 저장소
   a. 클라우드에 온라인으로 백업로드하는 것과 비슷 -> 팀원들과 공유, 협업도 가능

●Git 필수 명령어●

0. github repository의 명령어 코드 terminal에 붙여넣기 + 협력자(collaborator) 등록

• 모든 코드변경 요소는 최초 생성자의 이 repository 단 하나의 파일에만 저장된다.
  (push가 생성자입장에서는 덮어쓰기이지만, 협력자입장에서는 파일추가이다. 따라서, 생성자는 추가된 파일을 pull 해준 후, push해주어야 충돌이 일어나지 않는다. 만약 push를 바로 할경우 협력자의 코드가 무시된 채 파일이 추가될 것이다.)
• 새로고침하면 화면 바뀔 것임.
• git remote add origin <github 주소>
  : git push "github 주소" 브랜치명을 쓰면 코드가 매우 길어진다.
  -> 그 해당 주소를 origin이라는 이름으로 변환하는 것이다.
• git branch -M main
  : 기본 브랜지가 처음에는 master로 설정되어 있는데 이를 main으로 바꿔준다.(노예제도적 억양)
• git push -u origin main
  : “git push”만 입력해도 git push origin main이 입력되도록 한다.
  -협력자 등록: settings -> add people

1. git init: git repository를 내 컴퓨터에 생성. 해당 폴더에서 코드 변경점을 추적, 기록.

• 코드 관리를 시작하는 명령어 즉, 변경점을 기록하겠다.
• initialize: 초기화하다, 초기 세팅하다.
• 프로젝트 시작 전 딱 한번만 입력하면 됨(여러 번 입력해도 문제되진 않음)
• ☆변경 기록을 해줘야 할 정확한 프로젝트 폴더(경로)에 입력해야 함☆
  (잘못하면 데스크탑 전체 파일, 폴더가 다 기록됨)
• 해당 폴더 우클릭 후, git bash here 클릭하면 git bash가 정확한 그 폴더에 맞게 터미널이 열림.(윈도우 기준) -> 다시 리눅스 명령어 pwd하여 정확한 폴더 위치인지 확인
• 잘보면 .git이 생성됨을 알 수 있음. 즉, 숨겨진 폴더.

2. git branch 브랜치이름: 브랜치(복사본) 생성

• 수정은 하되 원래 파일은 그대로 두고 싶을 때, 보통 파일을 복사하여 복사본을 만든다. 그러나, 파일 자체를 만들게 될 경우, 용량과 시간 문제가 발생하기에, git hub에서는 복사본 개념(파일 복사본은 아니다)으로 ‘branch’를 제공한다.

3. git branch: 생성된 브랜치 종류 확인

• *: 현재 내가 위치해 있는 브랜치
• 키보드 q를 눌러 빠져나오기

4. git switch 브랜치이름 / git checkout 브랜치이름: 브랜치 이동

• 어떤 것이 수정되었는지 직접 이동해서 확인가능
• switch는 최근에 만들어진 명령어. checkout은 실은 이동뿐만 아니라, 커밋, 복구 등 통용적으로 쓰여서, switch를 따로 만듦.
• Q. 협력자로 등록된 다른 사람의 코드 파일 브랜치에 접근할 수도 있나?

5. git switch -c 브랜치이름 / git checkout -b 브랜치이름: 브랜치 생성 & 이동

• c: creat / b: branch

6. git switch 최종브랜치이름 -> git merge 합칠브랜치이름: 브랜치 합치기

• 하위 브랜치에서 수정한 것을 main 브랜치 즉, 최종 브랜치에 합친다.(한 곳에 합쳐 기술 공유, 협업)
• 즉, 최종브랜치에 가서 합치고 싶은 브랜치를 끌고 오는 것이다.

7. git add 파일명: 저장 전 파일 지정하여 working directory에서 staging area에 올림

• git add (띄우고). : 점(.)은 현재 나의 경로의 모든 변경된 사항을 말함. 즉, 프로젝트의 변경사항을 한 번에 지정가능

※ Please tell who you are 에러 발생
1. git config --global user.name 유저네임
2. git config --global user.email 유저이메일

8. git commit -m “메세지 작성”: 실제로 repository에 저장

• 메세지 부분은 무슨 코드 짰는지 자세히 적으면 log 확인 시 유용하다.

9. git status: 저장 여부 확인(어떤 파일이 변경되었는지 등 변경 상태 확인) (모든파일)

• modified 붉은색 표시: 코드의 변경은 있지만 지정, 저장을 하지 않은 파일
• modified 초록색 표시: add는 되어 있으나, 저장은 안되어 있다.
• nothing to commit:　저장할 것이 없다

10. git log: 저장 내역 확인 (저장된 것만)

• 커밋 메시지로 코드 변경점 추측 가능
• commit 뒤에 있는 commit ID를 통해 git diff(코드 변경 확인), git reset(과거로 돌아가기 기능/이경우 git push -f 이용) 사용가능
• end가 뜰 경우, q를 누르면 빠져나와 진다.

11. git push origin 브랜치명(<main): 추가로 수정된 코드 브랜치(githun repository)에 업로드하여 백업하기

• 그냥 git push 명령어는 main에 곧바로 연결된다는 것에 주의하라.

• 기능브랜치에 한하여만 가능하고, 바로 윗단계의 브랜치에 push할 수는 없다.

• 만약 그렇게 할 경우, 이런 경고문이 뜬다.
  fatal: The current branch modify has no upstream branch.
  To push the current branch and set the remote as upstream, use

  git push --set-upstream origin modify

To have this happen automatically for branches without a tracking
upstream, see 'push.autoSetupRemote' in 'git help config'.

12. git clone github 주소 .: 파일 전체를 다운로드

• 코드 파일을 통으로 들고옴. 파일이 아예 없을 때 처음만 해주면 됨.
• 깃허브 레포지토리에서 github 주소 복사
• 띄어쓰기 후 맨 뒤에 점(.) 붙여야, 경로가 달라지지 않는다.
  ㄴ 이 경우, 폴더가 아예 새로 만들어진다. 그럼, 다시 폴더에 들어간 후에 명령을 쳐야하는 번거로움이 생긴다.
  (폴더를 이미 만들었다면 .붙이고, 폴더가 없다면 .없애기)

13. git pull origin 브랜치: 코드 변경사항 다운로드

• 다른 개발자가 이미 push 한 상태에서, 만약 팀장이 바로 push를 할경우 자신의 변경사항만 덮어 씌워지게 되는데, 이 경우 그 다른 개발자와 충돌이 발생한다. (물론 git에서 push가 못일어나게 rejected를 주긴 한다.)
• 따라서, push 하기 전에 변경사항을 먼저 pull 해서, 다른 개발자와 코드를 동등하게 맞추고 나서, 수정을 가한 후 push를 해주어야 하는 것이다. 또는 pull request의 코드 리뷰를 통해 함께 수정을 가해줄 수 있다. 이렇게 하면, github에 하나의 파일에 코드를 맞출 수 있다.
• 충돌: 같은 파일의 같은 위치에 코드가 변경되었을 때
  ㄴ명령어를 가져왔는데 코드가 이상해졌을 때: merge conflict in -> fix conflicts
  ㄴcurrent change VS incoming change

※ 처음할 때 나오는 경고문
git config pull.rebase false #merge > 일단 이것만 복붙하면 된다. rebase 지금은 글쎄?
git config pu..rebase true ＃rebase
git config pull.ff only #fast-forward only

※ vim 에디터가 뜰 경우
esc -> : -> wq -> enter

TIP. push, pull은 팀원간의 협의하에 최소한의 기능단위에서 해주는 것이 좋다.
또한, 충돌을 막기 위해 수시로 pull하며 미리 테스트해두는 것이 좋다.

14. git log 후 commit ID 복사 -> git reset --hard ID : 이전 커밋상태로 이동

15. push -f :강제 푸쉬
    : bb가 커밋된 상태에서 이를 지우고 싶어 리셋하여 이전 커밋상태로 이동 후, 로컬에서 바로 푸쉬(cc)를 할 경우, 깃허브 상에 이미 다른 커밋 기록(bb)이 남아있기 때문에 커밋이 겹쳐서(bb&cc) 바록 푸쉬가 안된다. 이경우, 강제로(force) 푸쉬해 덮어 씌울 수 있지만, 이전 기록(bb)이 아예 사라진다는 단점이 있다.

16. git reflog
    : 위와 같은 과정을 통해 로그상 사라진 커밋까지도 보여 주는 더욱 구체적인 커밋 로그창을 띄어준다. 이를 다시 복사한 후 reset 해준다.

※ push & pull request
push는 ‘로컬’의 기능 브랜치를 깃허브에 올리는 것이며, pull request는 깃허브상에서‘만’ 그 올려진 것들을 그 상위 브랜치인 dev브랜치 혹은 main 브랜치에 합치는 것이다.
다시말해, push는 단순히 깃허브에 올리는 것이고 곧바로 상위 브랜치에 합쳐지지는 않는다. pull request는 push된 코드를 상위 브랜치와 머지하는 것이다.
그렇기에, push를 눌렀을 때 pull 하라고 경고문이 뜨는 것은 자신이 만든 기능branch에 한하여만 뜨는 것이고, dev branch는 애초에 push가 되지도 않는다. 한단계 건너뛰어서 바로 dev로 push하여 합치는 것은 안되고 코드 리뷰를 통해 깃허브상에서 merget되는 것이다. 물론 dev내용을 pull해오는 것은 가능하다.

※ pull request: 깃허브 내 merge 기능 (base기준으로 merge됨)

• 결국은 서로 다른 컴퓨터상의 사람들끼리 ‘협업’을 하고, 그 사람들의 branch들을 끌고 와야 하기 때문에, merge 명령어 보다는 터미널이 아닌, 온라인 저장소인 guithub상에서 모두가 볼 수 있게 올려서 “코드리뷰” 후 합치는 것이 더 이득이 될 때가 있다.
• pull: 당겨서 합치는 것(>merge) + requese: 요청하다= 합쳐도 될까요?
• 사용법
  : 우선 수정을 가한 해당 브랜치를 깃허브에 push해준다. -> 깃허브내 'compare & pull requese' 버튼을 누른다 -> base: 최종 브랜치 / compare: 합쳐질 기능 브랜치 -> creat pull request 누르기 -> 우측 상단에서 riviewr 추가 -> file changed에서 코드 변경점 및 리뷰 확인 -> merge pull request 누르면 merge가 된다. (단, 충돌되었을 경우, 버튼 활성화가 안되어 있다.)
  ->　confirm merge 누르기
  -> 내 로컬상에서 합쳐진 것은 아니고, github내 main branch에서만 합쳐진 것.
  -> 그러므로, 내 로컬 main branch로 이동 후, 해당 branch pull해오기

• 정리: 브랜치 생성 및 이동(branch) ->　기능 개발 및 코드 저장(add,commit) -> 코드 업로드(push 및 pull request 생성 -> github에서 merge -> pull 하여 로컬에도 반영

※ 실전 응용
＊ 일반적으로 main 브랜치는 배포용으로 활용된다. 만약 이 main 브랜치에 곧바로 합칠경우 다음과 같은 문제가 발생한다. 우선, 완벽하게 기능을 개발해야 머지가 가능하다. 그러나 이 경우 다 만드는데 오래 걸리며 또한, 다른 사람들끼리 각각 만들고 머지했을 때, 버그가 생겼을 경우, 버그가 발생한 지점이 정확히 어디인지 확인하기가 힘들 수 있다.
＊ 이를 해결하기 위해, 일반적으로 개발용 branch 즉, dev branch를 따로 만들어 놓는다.
그리하여, 기능 브랜치에서 기능을 만든 후, main에 바로 합치지 않고, develop에서 합쳐 테스트를 한 후 완성된 결과물을 배포용에 합친다.
Main branch: 배포용
develop branch: 테스트용
기능 branch: 기능 개발용
＊두번째로, 각각은 깃허브 코드리뷰상 문제가 없어도 막상 합치게 되었을 때는 충돌이 발생할 수 있다. 층돌된 걸 배포했을 경우, 이 오류있는 코드를 협력자들이 pull하게 될 수도 있다. (사실, 실제로 이를 막기 위해 github상에서 충돌날경우 merge pull request 가 활성화가 안된다.)
＊ 이를 해결하기 위해, dev브랜치에 있는 타인의 코드를 내 로컬 브랜치에 pull하여 로컬에서 먼저 테스트하여 충돌을 미리 해결해 놓는다.

※ feature 단위에서 백업용으로 hotfix브랜치에 merge해주는 것도 좋다. 스토리보드로 코드를 연결하게 되면 빌드시 xml 코드로 바뀌어서 조금만 잘못건드리면 충돌이 생겨서 이를 방지하기 위해 백업을 만들어 두면 좋다.

※ 단계
1. 팀장: 초기 코드 작성 및 gitgub 업로드
: 폴더 생성 및 초기 코드 작성 -> git init, add, commit -＞ git repository 생성
-> git push(github에 업로드)
2. 팀장: dev 브랜치 생성
: git switch -c dev(로컬에서 dev 브랜치 생성) -> git push origin dev 하여 git hub에 반영(github에서 바로 만들 수도 있음) -
3. 팀장: dev 브랜치를 default로 생성하여 최종브랜치 변경
: settings -> default branch -> 변경
4. 팀원들 collaborator로 등록
5. 팀원: git clone하기
6. 전체: 기능 브랜치 생성 및 기능 개발 후 업로드
： git branch -c feature/signup -> git push origin feature/signup
(이때, dev branch는 pull request를 받은 기능 브랜치가 합쳐지는 장소이기 때문에, dev에 바로 push하는 것이 아니다. 또한 main과 dev는 그 브랜치를 최초로 만든 팀장에게만 권한이 있기에, 마음대로 push할 수도 없다.)
7. 전체: pull request 생성 (dev에 합쳐도 될까요?)
8. 전체: 리뷰 요청하기
9. 전체: 코드 리뷰어는 file changed 항목에서 코드 리뷰해주기
: + 버튼 눌러 start review & finish review
10. 전체: 합치기 전 내 로컬에서 충돌 해결 및 테스트
: 기능브랜치에서 git pull origin dev -> 수정 후, 다시 push하고 깃허브에서 merge
11. 전체: 추가기능구현
: dev 브랜치로 이동 후 pull 하여 내 로컬의 dev에도 변경사항 반영
12. 반복..