Git

Git 

 

git은 버전관리 시스템 / GitHub 은 파일을 업로드하는 공간

 

Git은 모든 파일을 트래킹한다, 문제가 있다면 그전 히스토리로 돌아갈수있다

---

Repository 

• 기본적으로 폴더
• git이 주시하고있는 곳

 

.파일 은 안보여진다

---

Commit

• 기본적으로 기록이다
• git에 어떤 변경사항이 있었을때 record를 세팅하는 것
• Commit 의 제목은 꼭 적어주어야한다
• Git 에 저장하고 싶은 시점 

---

Area

• git은 area를 가지고있다
• 첫째는 working directory 라고 불린다, 우리가 작업하는 공간
• Staging area 는 한 파일이 커밋되면 기본값으로 깃허브 데스크탑에서는 모든 파일들이 staging area 로 바로가게 된다. Staging 은 파일이 곧 커밋될거라는 것
• 항상 모든 수정사항들은 staging area에 추가된다
• 마지막은 commit area 파일이 커밋되고 우리가 그 수정사항의 스냅샷을 갖고 있는것 그 수정사항, 시간, 누가 수정했는지 등등 , 같은말로 repository area 라고도 한다

---

Branch

 

• 마지막 커밋에서부터의 다른 타임라인

---

Branch에 Conflict 가 생기는 이유

• main과 branch가 같은 line을 수정했을때 발생한다

---

Github fork

• 전체 레포지토리를 우리의 계정으로 복사한다
• 한 레포지토리를 가지고 프로젝트를 가져와서 본인 레포지토리로 복사한다
• 포크후 작업한파일을 푸쉬한후에 포크해온 부모에게 가서 pull request를 보낸다
• 만약 베이스 저장소의 리드미가 바뀐다면 ? 포크한 저장소에는 커밋사항이 반영되지 않았을 것이다.  포크를 하면 기본적으로 upstream 브랜치가 만들어진다.  이 upstream 브랜치를 통해 베이스 저장소의 최신 변경사항을 요청받을수 있다.  Fetch origin 을 클릭하면 upstream 에서 fetch를 하게된다. 그다음 upstream의 코드를 현재 브랜치에 병합하면 된다.

---

Github, Gitlab, Bitbucket 의 이슈 기능

• 이슈는 프로젝트가 해야하는데 아직 하지 않은 일이나, 사람들이 발견한 문제나 버그같은 것을 기록하는 것
• 오픈소스에서 작업할 때 보거나 테스터들이 문제를 찾아서 이슈를 적을 때 볼 수 있다
• 해결해야 할 문제들이 이슈로 적혀있다
• 버그나 문서화 라는 라벨을 달 수 있고 라벨을 새로 만들수도 있다
• 이슈에 milestone 이라는게 있는데 이는 버전을 올릴때 필요한 것들을 모아두는 것이다. milestone을 생성하고 그 안에 많은 이슈들을 할당할 수 있다. 그 이슈들이 모두 해결되면 마일스톤이 달성되는 것이다.

---

Git console

• 콘솔에서는 항상 작업하는 디렉토리에 위치해야한다.
• git log 명령어로 커밋된 내역을 확인할 수 있다
• git add 파일명 이렇게하면 해당파일만 스테이지에 추가된다 하지만 대부분의 경우에는 모든 파일을 추가한다 
• git add .   닷은 현재 폴더라는 뜻이다. 현재 폴더에 있는 모든 파일을 포함한다 
• git push origin main 커밋된 사항들을 깃허브 클라우드에 올린다

---

Git console : 하드 리셋 (이전 커밋으로 돌아가고 싶을때)

• git log 를 보면 커밋부분이 있다 되돌아가고 싶은 커밋부분을 복사한다.
• git checkout ${커밋붙여넣기} 
• git log 를 확인해보면 HEAD 가 옮겨진걸 확인할 수 있다
• 다시 현재상태로 돌아올수도 있다 git checkout main
• 이런식으로 git 의 HEAD를 옮길 수 있다
• git reset —hard HEAD^  여기서 —hard 는 삭제한다는 뜻이다 HEAD^ 부분은 HEAD에서 얼마나 멀리갈지를 나타낸다 HEAD^^ 두커밋 HEAD^^^ 세커밋 이전으로 돌아가는 것. 
• 위를 하고나면 문제가 생기는데 원격저장소인 origin에 내가 원하지 않는 커밋이 더있다는 것이다. git push origin master —force 로 강제 푸시를 해야한다
• git reset HEAD^ 를 한다면? 이는 하드 리셋도 아니고 소프트 리셋도 아니다. 이는 복합 리셋이다.

---

Git console : 복합 리셋 

• 복합 리셋은 방금 커밋한 변경사항들을 다시 unstage 영역으로 옮기는 것이다.  아직 완료되지 않은 파일을 커밋하는 것 같은 실수를 한 경우에 복합 리셋을 한다. (파일 변경 내용은 그대로 유지하고 싶을떄) 파일을 수정하고 다시 커밋하면 문제가 생긴다 원격저장소의 최종상태와 컴퓨터의 최종상태가 다르다 
• git remote -v  로 원격 저장소를 확인 
• git push origin main —force 대신에 git pull origin main 을 실행한다.  이를 실행하면 코드 변경사항충돌이 생긴다. 컴퓨터의 최종상태로 하고싶다면 vsc에 Accept Current Change 를 클릭한다.  이후 다시 커밋.  이러면 병합되지 않은 파일이 있어서 커밋할 수 없다고 한다.  git add . 입력후 커밋한다. 그리고 git push origin main 을 실행하면 그 전에 작업했던 내용들은 사라진다.

---

Git console : 소프트 리셋

• 소프트 리셋은 이전 커밋에서 변경한 내역을 unstage 영역에 두지 않는다. 
• git reset HEAD^^ —soft  는 stage 영역에 추가한다. 즉 지금 작업하는 내용과 섞이지 않는다. unstage 영역에 작업중인 파일이 있을 때 섞이지 않고 싶을떄 사용하면 된다.
• git reset 을 하면 과거로 돌아가 모든 파일을 kill 해버린다. copy를 주지도 않는다.  복합 리셋은 변경내역을 unstage 영역에 둔다. 소프트 리셋은 복합 리셋과 비슷하지만 변경 내역을 stage 영역에 둔다. 
• 대부분의 경우 하드 리셋으로 되돌려서 다시 시작을한다. 혹은 복합 리셋을 하기도한다. 어느 영역에 저장되는지는 신경쓰지 않기 때문.

---

Git console : Checkout branch

• 파일을 유지하면서 새 브런치를 만들고 싶으면 git checkout -b ${브랜치명} 을 입력하면 된다. Git desktop 에서 새 브랜치를 클릭할 때 이 명령어가 실행되는 것이다. 
• git branch 를 실행하면 브랜치 목록을 볼 수 있다.
• 과거의 커밋으로 checkout 하는 것과 브랜치로 이동하는것을 한꺼번에 할 수 있다. git checkout ${커밋명} -b ${브랜치명}  이렇게 마스터에서 체크아웃과 브랜치 생성을 한번에 할 수 있다.
• 생성된 다른 브랜치를 깃허브에 올리려면 git push origin ${브랜치명} 을 실행하면 된다.

---

Git console : 브랜치 삭제

• git branch -d ${브랜치이름} 
• 브랜치 삭제 후 git push origin —delete ${브랜치명} 입력해야 원격 저장소에서도 삭제가 된다.

---

Git console : 커밋 수정

• 만약 push를 했는데 실수를 했다면? (Ex : 파일을 추가를 안한경우) 방금 한 커밋에는 첫번쨰 파일만 추가되있을것이다. 첫쨰로 git add . 로 깃에 추가하고 새로 커밋할 수도 있다. 하지만 이건 이해가 가지 않는 행동이다.  커밋을 수정해 볼 것이다. 
• 커밋 수정(amend)는 가장 마지막 커밋을 수정하는 것이다. 
• git commit —amend —no-edit 이는 -m “” 으로 메시지를 넣을 수도 있고 —no-edit 옵션은 커밋 메시지를 수정하지 않는 것이다. 입력후 푸시

---

Git console : git status

• git status 는 커밋할때 파일들의 상태를 볼 수 있다.
• git add 후 git status 를 실행하면 내가 커밋하게 될 파일을 확인할 수 있다.

---

Git console : 파일을 깃에서 숨기는 방법

• 가끔 .env 파일처럼 숨기고 싶은 파일이 있다.  이럴땐 .gitignore 라는 파일을 만들면 된다. 그리고 깃에 추가하지 않고 싶은 파일이나 폴더를 .gitignore 파일에 입력하면 된다. 

---

Git console : add 로 stage에 추가한 파일 제거

• git rm -r ${파일명} —cached 으로 stage 에서 제거할수 있다. 폴더를 제거한다면 -r 옵션 추가
• 가끔 올리지 말아야 할 파일을 깃헙에 올리고 잊을때가 있다. 그리고나서 파일을 숨기고 싶을때가 있다. 그럴때는 git 에서 파일 삭제를 먼저 해야한다. 
• 파일명을 .gitignore 에 추가하고 깃의 stage영역이나 원격저장소에 추가한 파일을 제거해야한다. 

---

만약 facebook/react 코드에 기여하고 싶다면?

• 저장소를 포크하고 무언가를 하면 같이 협업할 수 있게 된다. 이번엔 콘솔을 사용할 것.
• 포크한후 url 복사
• git clone ${url} 이는 내 포크 저장소를 clone 하는 것이다. 
• git clone ${url} ${폴더명} 으로 이름을 정할 수 있다. 
• 만약 내가 포크하지 않은 코드 저장소를 클론하면 파일을 내려받을 수는 있지만 작업한 내용을 업로드 할 수 없다. 
• 파일을 수정하고 add, commit, push 한다 파일이 저장소로 올라가고 이걸로 pull request 를 생성할 수도 있다. 
• 협업할때 포크는 해야하지만 GitHub desktop을 사용할 필요는 없다.