Git으로 형상관리 잘 알고 하기

Q. Git을 사용할 때 제일 첫 번째로 해야 하는 것은?

**A. 계정 만들기,,

계정을 갖고있다는 전제로 시작, 없으면 깃허브 웹 접속해서 만들기
(+ git bash도 다운받기) 이 정리는 bash 기준입니다.,,

IDE 내 git 관리 도구나 git desktop 툴의 사용법과 다릅니다.

---

저장소

스토리지라고 불리는 저장소는 두 가지로 나눌 수 있다.
로컬 저장소와 원격 저장소

로컬 저장소는 내가 사용하고 있는 pc나 데스크탑에서 작업 중인 파일이나 폴더 등을 로컬 저장소로 지정하여 사용한다.
원격 저장소는 github 웹 사이트에 올라간 작업 환경이 되겠다.

그럼 왜 Git을 사용하는 것인가?

Git은 형상관리 툴로 협업 시 프로젝트의 변경 사항, 버그, 각종 일어날 수 있는 문제를 방지하고 수정이 용이, 유지보수가 쉽게끔 도와주는 프로그램이자 툴이다. (간단하게 이렇게만 정리)

프로젝트 올리기 전 튜토리얼

먼저 원격 저장소 레포지토리를 개설해야한다.
개설하면 README.md라는 마크다운 파일의 유무에 따라 튜토리얼이 다른데,
이 부분은 튜토리얼대로 따라하면 된다.

따라했을 시, 내 원격저장소에는 README.md 파일 하나가 생성 되었을거고
이제 본격적으로 원격 저장소를 사용할 수 있는 환경이 세팅된 것.
이후 내 로컬 저장소에 git pull origin main(or master) 명령으로
리드미 파일을 병합하고 바로 개발 시작 ~

자주 쓰는 명령어로 git-flow 과정 따라가기

git bash라는 툴이 있다.
리눅스 기반의 명령어로 로컬 저장소에서 원격 저장소로 push 작업이나 다양한 깃 관련 행위들을 git bash 안에서 해결할 수 있다.

git init : 작업하고 있는 디렉토리, 폴더를 로컬 저장소로 만들어주는 명령어이다. .git 폴더가 숨김으로 생성되며 로컬->원격 저장소에 올리기 위한 제일 첫 번째 단계라 할 수 있다.

git remote add origin 원격url :
원격 저장소 url을 바라보게 하는 명령어. 이제 내 로컬에서의 작업 이력을 url에 명시한 저장소로만 올리게 하는 연결선이라 생각하자.

git remote -v : remote된 원격저장소의 목록을 확인하는 명령어. 연결에 이상이 없는지 확인하는 것

git clone 'url' : 말 그대로 클론, 원격 저장소를 복제해서 내 로컬에 붙여넣는 명령어이다. 보통 프로젝트를 시작할때 기본 세팅된 작업물을 깃허브에서 클론 받아 시작하는 경우가 많다.

git status - 현재 스테이지의 상태를 확인하는 명령어

git add - 커밋하기 전에 커밋할 파일을 모아두는, 저장하는 명령어이다.
add를 하기 위해서는 git bash 기준으로 tracked, untracked로 구분되는데 tracked는 add가 된 파일일 것이고, untracked는 아직 add하지 않은 파일이다. 빨간색으로 떠있다면 그 파일들을 커밋하고 싶으면 add하면 됨.

git commit -m "message" - 메시지와 함께 add된 소스를 커밋한다. 원격 저장소에 적재할 내용들을 push 전 단계에서 커밋한 단위로 구분한다.

git push 원격저장소명(origin) 원격브랜치명(main) - 커밋된 내역을 원격 저장소에 담는다.

git fetch - 로컬 환경에서 작업 중 원격 저장소의 최신 변경 이력을 확인하는 명령어이다. 즉 변경사항을 체크"만" 하는 명령어이며 변경된 이력을 로컬 저장소로 가져오지는 않는다.

그럼 가져오려면?

git pull : 원격 저장소의 변경 이력을 확인함과 동시에 변경 사항이 있으면 최신 이력을 로컬에 반영하는 명령어이다.

여기서 협업 시 상황과 혼자 개발하는 상황에서 사용할 명령어는
혼자일 시엔 바로 pull로 자동 병합을 해도 크게 문제되는 일이 적겠지만, 협업 시에서는
fetch를 안 해보고 pull하면 큰일 날 수 있는 상황이 많을 수 있다.
아래 규약 참조해서 사용하기

규약 1 - 원격 저장소가 로컬 저장소보다 더 최신의 커밋이 있을 때에만 내려받는다.

규약 2 - git fetch 이후에 병합하려는 경우, git merge 별칭 브랜치명 으로 현재 로컬을 원격 저장소의 변경 이력(커밋 내용)을 적용한다.

보통 작업 중인 워크스테이션에서는 최소 3개의 프로젝트 복사본이 존재할 것이다.
1. 내가 커밋한 내역이 있는 저장소
2. 아직 작업 중, 수정 중이라 커밋하기 전의 저장소
3. 원격 저장소의 로컬에 캐싱된 복사본 저장소 - 이건 감이 잘 안온다.

브랜치?

브랜치는 나뭇가지의 형태로 작업 영역을 분산할 수 있다고 생각하면 된다.

혼자가 아닌 다른 사람과 협업, 프로젝트를 한다는 상황을 생각해보면
각자 같은 작업 환경에서 원격 저장소에 올릴 때 문제가 발생할 것 같지 않나요?

이러한 점을 방지하기 위해 브랜치를 사용하는 것이다
각자 작업하는 환경을 따로 생성해서 활동하는 것이라 생각해라

명렁어

• git branch 브랜치명 - 현재까지의 커밋을 분기점으로 브랜치명대로 브랜치가 생성되는 명령어.

• git branch 브랜치명 커밋id - 지정한 커밋id에서의 분기점으로 브랜치를 생성, 작업 시 보험으로 지정 커밋id까지의 작업 내역을 남겨놓고 작업 할 수 있는 개념이라 생각하자.

• git branch -v : 갖고 있는 모든 브랜치와 그 브랜치의 커밋id를 볼 수 있는 명령어

• git branch -r : 원격 저장소에 반영되어 있는 모든 브랜치를 확인 할 수 있는 명령어

• git checkout 브랜치명 - 지정 브랜치명으로 이동하는 명령어
  (주의사항!! - 현재 브랜치에서 변경된 작업 이력을 모두 커밋해 놓아야 이동 가능함)
  잘못하면 날아갈 수 있음 -> 삽질 세네시간 할 확률 99.99%)

• git checkout -b 브랜치명 - 브랜치명으로 새로운 브랜치 파고 바로 이동해주는 명령어. 편함

---

업스트림, 다운스트림 설정하기

upstream과 downstream은 명칭적으로 원격과 로컬의 상하관계라 생각하자

-u라는 키워드는 --set-upstream을 의미하는 것으로
원격저장소로 upstream을 설정하면 git push와 git pull만 적어도 사용이 된다. (관계 설정이 되있기 때문에)

초기 로컬 브랜치일 시 :

git push -u 원격저장소명 원격브랜치명
이 개념은 이번에 알게 됐다. 현재 작업 중인 브랜치에서
명령어를 통해 지정한 이름으로 원격 브랜치가 생성되고,
이 원격 브랜치와 로컬 브랜치가 자동으로 업스트림/다운스트림 관계로 설정되는 것. ->
이러면 git push/git pull 만으로도 명령어 사용 가능

기존 로컬 브랜치일 시 :

git branch -u 원격저장소이름/브랜치명

• git branch -vv - 현재 업스트림 관계의 브랜치 목록 확인 명령어

---

브랜치 정책

master :
develop :
feature :
release :
hotfix :

크게 5가지로 구분해서 현업에서 사용한다. 이 부분은 다음에 정리

---

그 밖에

ex) [main -> KDH]
git push orgin KDH (로컬 main -> 원격 KDH 브랜치에 담김)

• git branch -d [브랜치명] - 현재 로컬 브랜치 삭제

• git merge 브랜치명 - 현재 로컬에서 브랜치명의 이력 병합

• git commit --amend : 커밋 메시지 변경

• git config --list - 전체 config를 리스트로 확인

---

위험한 것들

• git reset HEAD 파일명 - 파일의 add를 취소, 파일명 없으면 add 전체 취소
• git reset HEAD^ - 제일 최근 커밋내역 취소 -> add 취소상태로 돌아옴

• --force 설정 들어간 명령어 - 이건 특수한 상황에서 사용해야 해서.. 다른 글 참조해서 사용하기

git push 취소하기(되돌리기) 과정 ..

git reset HEAD^ - 최근 커밋 취소 (커밋 한게 있다면)
git reflog - 브랜치와 head의 지난 몇달간의 커밋 목록 확인
git reset 커밋id - 커밋id 시점으로 작업 환경을 되돌림
git commit -m "" - 되돌아간 상태에서 다시 커밋
git push origin 브랜치명 -f - 다시 푸쉬 -> 강제 병합과 느낌이 비슷..
git clone -b <branch명> <remote_repo 주소> - 원격 특정 브랜치 clone하기

충돌 해결 프로세스

파일명이 같으면 충돌나지만 같은 파일명이어도 수정 부분이 다르다면 발생 x, 수정 부분도 같다면 충돌

최소화 정책

• 작업 시작 전, 최신 변경 이력을 반영한다. (pull)
• 작업 내역을 더 작은 단위로 쪼개어 빈번하게 커밋.
• 브랜치 전략 사용하기

다양한 시뮬레이션

1. 로컬에서 a 브랜치와 b 브랜치가 같은 파일을 건드릴 때

   1. a에서 파일 수정 후 커밋함
   2. b에서 파일 수정 후 커밋함
   3. a로 돌아와서 b와 머지 시도
   4. 충돌남

2. 로컬에서 원격으로 push 하려는데 충돌

push할 때 rejected! 와 함께 브랜치 흐름 나타남. (로컬 -> 원격)
non-fast-forward, .. 등등의 이유
이 원인 대부분은 push 전, 작업 전에 원격 저장소의 최신 상태를 merge하지 않아서다.
git pull - 변경 내용 확인, 필요 시 수정
git commit -a
git push

충돌 내역 확인하기

<<<< HEAD - 충돌 시작 부분, 현재 브랜치 변경 사항
======== - 변경 사항 구분자
->>>>>>>> - 충돌 끝 부분, 병합하려는 브랜치의 변경 사항

a. 수정 하고 이 세가지 구분자를 지워준다.
b. 변경사항을 커밋한다.
c. 충돌 해결 완료