git bash !!! 파일로 git 수정 하는 법

 

 

 

 

 

mac은 파일에 메모장 만드는 대신 vscode에 파일 불러와서 메모장 만들기 .yaml 로 만들기 !!!

 

git reflog 는 전체 log 보는 것

git status 보는 습관 들이기 !!!

git add . 은 index에 추가 하는 작업

git commit -m "커밋할 내용" 은 커밋 하는 작업

 

쉬프트 + 커멘드 + . 은 숨겨진 파일 보는 단축키 !!!

---

git의 간단 개념
내가 작업한 파일을 git은 변화를 감지하고 관리를 하겠다라고 명령어를 입력하게 되면 
그 파일을 인덱스 트리화 해준다(박스화 *나만의 용어).
이제 그 박스를 git commit을 하면 head(브랜치인거 같음) 의 줄기중 하나의 점으로 찍히게 됨
이 줄기의 점들은 내가 박스화한 작업들을 올린 시점을 찍어주는 것
히스토리가 계속 남기 때문에 언제든지 이전 작업, 이후 작업으로 복구가 가능하다

-명령어 

git init :  git 작업공간 만들기 (repository를 만드는 느낌인거 같음)
git status : 파일의 변화를 감지하여 현재 git의 상태를 알려줌

*untracked : 관리되고 있지 않다는 의미 -> 파일의 상태에서 이 문구면 관리 안된거

git add . : . 을 붙인거는 모든 파일을 관리하겠다는 의미 -> 관리 시작 문구 (track이 된거임)
- 내가 관리하고자 하는 파일을 박스화한다고 하자(나만의 용어임)
이 명령어 이후에 다시 git status를 하게 되면 관리되고 있는 파일이 나옴

이제 head(브랜치 : 줄기)에 내가 작업한것을 올려놓고 싶다  => git commit 을 해야함
git commit -m "commit 메세지"    => git을 처음한다면은 너 누구야? 라는 말이 나온다

이때는 사용자 정보 설정을 해야함 (팀원들 챙기기용)
유저 네임 (깃의 닉네임 + 이메일)
git config --global user.name"닉네임"
git config --global user.email"이메일 주소"

설정해야할것을 보려면 git config --list라고 해서 확인해보자

여기까지 간단하게 head(내 브랜치) 에 올리는 과정 
git init(작업공간 생성) -> git add . (파일들 박스화) -> git commit (줄기에 올리기)

* git log  : 내가 git에 올린 로그가 나오게 된다 (유용하게 쓰일거 같은데)

* git 파일에 refs > heads라는 파일에 기록이 남음

내가 커밋까지 한 파일을 수정한 후에 git status 를 입력하면 변화를 감지하고 new file이 아닌
modified라고 올라온다

수정이 되었다고 해서 이전의 작업들을 박스화 한게 무너지고 그런게 아님 
수정한 파일은 다시 또 이전의 박스들과 함께 다시 박스화 한다. (git add . )

내가 commit한 로그중에 뭔가 마음에 안든다 또는 잘못 commit했다 하면
git reset을 해야함 
3가지 옵션이 있음 

1.  soft : 브랜치에서만 날린다. head에 위치가 이전 commit상태로 옮겨짐
   -> commit 로그 변경시 사용
   - git reset --soft 해쉬코드4자리(돌아가고 싶은 상태의)

2. mixed : 브랜치에서 날리고, 박스화 한거 날리고 (add하지 않은 상태 => 파일만 수정된거임)
   -> 작업 공간의 내용 변경이 필요할 때 사용
   - git reset --mixed 해쉬코드4자리(돌아가고 싶은 상태의)
   ex) 2번째 커밋을 취소하고 내용을 수정하고 싶다
   1번째 커밋으로 mixed reset해서 2번째거 내용 수정하고 다시 add, commit

3. hard : 브랜치에서 날리고, 박스화 한거 날리고 작업공간에서도 날리고
   -> 그냥 처음으로 돌아가고 싶을 때


상황 : 저번에 삭제한 그게 더 나은거 같다, 그걸로 다시 하자
git reflog : 내가 한번이라도 commit했던 것들의 로고를 다 보여준다.
=> log에서 다시 돌아가고 싶은 해쉬코드를 찾고
git reset --hard 해쉬코드 를 하면 기가막히게 돌아감

최종적인 커밋의(이전에 커밋한 로그가 없는 경우) 수정을 원할때는 이전 커밋이 없긴때문에
reset으로 돌아갈 해쉬코드가 없다
그럴땐
git commit --amend -m "수정" 이라고 하면 수정이 된다



Branch (줄기)

보통 메인에서 가지를 친후 다른 공간을 만드는 느낌으로 이해
메인에서 부터 나온 시점을 공통 조상이라고 함 
공통 조상 = 분기점

동일한 파일을 수정한 것이 없나 뭐가 다른지를 알아서 분석
그 후에 합치는 것을 

3-way merge => 브랜치로 나눈 후 각 브랜치의 형상이 다를때 

fast - forward - merge => 브랜치로 나눈 후에도 형상이 같을 때

브랜치 포인터 : 실질적으로 내부에서는 가지치기로 가는것이 아닌 메인 브랜치 포인터가 커밋한 지점을 찍을때
그것이 바로 메인 브랜치이다.

실질적으로 merge는 브랜치 포인터를 합치는 것


git branch : 브랜치 확인
git branch 브랜치명 : 브랜치명이라는 브랜치를 하나 만든다.  이때 메인 브랜치는 특수 표시가 있을거임...
-> 브랜치가 만들어진거라고는 하나 사실상 브랜치 포인터가 만들어진거임

git checkout -b 이동할 브랜치이름  : 해당 브랜치로 이동 (또 특수 표시가 있을거임)
checkout은 head 포인터의 이동임 = 헤더가 이동한 공간에서 작업 가능

merge순서 : 따로 만든 브랜치에서 checkout -> 그럼 head는 다시 main을 가리킨다. -> 외부 브랜치를 Merge
-> git merge 머지할 브랜치

git merge 충돌 : 서로 다른 브랜치에서 같은 파일을 건드렸을 경우 발생
웬만하면 같은 파일은 건드리지 않는게 좋음

git rebase : 코드를 다시 세팅 => 코드에 대한 로그를 다시 정리한다 -> 로그 정리

squash, pick : 로그를 압축해서 정리하고 싶다면 최근의 로그들을 squash하고 최종 로그는 pick
=> git rebase -i head~3 : 헤드에서부터 3개의 커밋을 압축



Github(클라우드 저장소) : 파일의 형상관리 => 분산버전관리가 가능한

repository를 만든다 = git init을 한다.

깃허브 저장소를 origin이라고 한다.(변경 금지 - 그냥 쓰셈)

시나리오
1. 회사에서 작업을 한다. : myApp이라는 프로젝트를 작업함
- git init : 레포지토리를 만들어서 작업을 함
- git add .  , git commit -m" " 을 통해 작업 프로젝트를 인덱스에 올리고 커밋을 한다.
- git remote add origin 내 깃허브 주소 : 내 원격 깃허브에 연결
- git remote -v : 연결을 확인한다. (git ls-remote : 이게 더 자주 쓰임)


깃허브 push : 파일 업로드 + merge
- origin 으로 파일을 업로드하고 merge(병합)까지 한다.
-> 명령어 : git push origin master : 내 메인 브랜치에 파일 업로드와 merge를 한다.

2. 회사에서 집으로 push(업로드 + merge)를 했기 떄문에 (origin에는 회사에서 한 작업이 있다)
-집에서 깃허브에서 내 집 컴퓨터로 가져올때에는 
pull을 해준다.
명령어 : git pull origin master(가져올 브랜치) => 파일 다운로드 + merge
-그 후에 로그 확인 ㄲ


- git clone url : init, remote~, pull 을 한꺼번에 함 (작업공간 생성, origin연결, pull을 한꺼번에)