github 사용법

📌 git이란?

• 깃 덕분에 같은 파일을 가지고 여러명과 함께 일을 할 수 있음
• 팀원끼리 업무 파일로 일을 해도 서로의 변경사항과 충돌하는 일 없이 일을 할 수 있음
  

📌 github이란?

클라우드에 있는 깃 제공자

• 로컬에서 작업하고 있는 파일을 github 저장소에 push하면 다른 개발자가 해당 파일을 pull하여 본인 원격 저장소로 저장하여 모든 기록들을 볼 수 있음
  

📌 git 사용법

1. 포크 후 깃 클론 -> main 브랜치 생김

2. git checkout -b 브랜치명, git switch -c feature/브랜치명 -> 새로만든 브랜치명이 뜨면서 바뀝니다

   • 기존에 있던 main브랜치로 HEAD를 변경하려면 -c를 붙이지 않으면 됨
     git switch main, git checkout main
     

3. 코드 작업

4. 커밋하기

• git add : 전체 업데이트
• git stage : 변경된 내용만 업데이트
• git commit -m "커밋 메시지"

5. [skip가능] main 브랜치로 병합git merge feat/브랜치
   ➡️ 프로젝트시 로컬에서 합치기보다는 Github의 pr 기능을 이용해서 변경내역을 팀원들과 충분히 확인하고 난 다음에 머지하는 것이 더 좋으니 feature브랜치를 push하고 pr을 요청하는것을 권장

6. git push origin "브랜치명"

7. git에 PR까지 하고 Merge(통합)하고 나서 (이상없으면)브랜치 삭제

8. (로컬로 들어와서) git branch로 현재 로컬에 branch가 main만 있는지 확인 안되어있다면 8번 확인

9. git fetch-> git pull origin main
   -> 기존의 branch가 남아있다면 git brach -d 브랜치명 사용 (브랜치가 합쳐지지 않는다면 삭제하지 못하게 설정이 되어 있음)

10. 그러고 나서 다시 브랜치 만들어주기 (2번부터 반복하면서 진행)

📍 git switch () : (이동하고 싶은) 브랜치로 이동 -> ex)

// 메인브랜치로 이동
git swtich main

Stage & commit

다음 커밋을 위해 현재 디렉토리에서 수정된 파일을 확인할 수 있습니다.
$ git status

다음 커밋을 위해 파일을 추가(스테이지)합니다. (stage)
$ git add [file]

추가한 파일을 언스테이징합니다. 변경 사항은 유지됩니다.
$ git reset [file]

스테이지되지 않은 변경 사항을 보여줍니다.
$ git diff

$ gitdiff --staged

# 스테이지된 콘텐츠를 메시지와 함께 커밋합니다. (스냅샷 생성)
$ git commit -m “[descriptive message]”

Branch & Merge

작업 내역을 브랜치로 분리해서 컨텍스트를 변경, 통합 가능

브랜치 목록을 보여줍니다. * 표시로 현재 작업중인 브랜치를 확인할 수 있습니다.
$ git branch

현재 커밋에서 새로운 브랜치를 생성합니다.
$git branch [branch-name]

다른 브랜치로 전환합니다.
$ git switch [branch-name]
$ git checkout [branch-name]

새로은 브랜치를 생성하고 해당 브랜치로 전환합니다.
$ git switch -c [branch-name]
$ git checkout -b [branch-name]

현재 브랜치에 특정 브랜치의 히스토리를 병합합니다.
$ git merge [branch-name]

현재 브랜치의 모든 커밋 히스토리를 보여줍니다.
$ git log

commit 취소

git reset HEAD^ (단계로 commit 취소)
커밋 기록 자체를 말고 꺽쇠 수만큼 이전으로 돌아가게 하는 명령

• ^ : 한단계 앞
• ^^ : 두단계 앞
• ~ 숫자 : 숫자만큼

# [방법 1] 
# commit을 취소하고 해당 파일들은 staged 상태로 워킹 디렉터리에 보존
$ git reset --soft HEAD^


# [방법 2] 
# commit을 취소하고 해당 파일들은 unstaged 상태로 워킹 디렉터리에 보존
$ git reset HEAD^
$ git reset HEAD~1 # 마지막 commit을 취소. 하나를 되돌림

$ git reset HEAD^^ 
$ git reset HEAD~2 # 마지막 2개의 commit을 취소


# [방법 3] 
# commit을 취소하고 해당 파일들은 unstaged 상태로 워킹 디렉터리에서 삭제
$ git reset --hard HEAD^

브랜치 의미

• Main브랜치 : 가장 안정적인 소스가 있어야 하는 공간 (운영하는 소스와 개발하는 소스는 다름)
  ➡️ 개발자가 사용하는 소스는 현재 계속 개발중에 있어 안정적이지 않아서 테스트하고 안정적이어야지 main 브랜치로 push한다

• dev브랜치 : 개발자가 개발하는 소스 중에서 제일 안정적인 소스
  (실질적인 배포가 되는 브랜치 ➡️ 배포가 되고 나서 운영에 문제가 없다면 main으로 push를 시킴)

• feat브랜치 : 개발자가 현재 개발중인 소스가 들어있는 곳 (dev브랜치를 기준으로 만들어짐)
  ➡️ 기능이 다 완료된 이후에 dev브랜치로 머지를 함

깃허브에서 브랜치 생성

2. 터미널에서 브랜치 확인

• git clone git@github.com:codestates-seb/project_section_git_test.git
• git fetch (깃 정보 갱신)
• git remote prune origin (로컬에서 캐시 삭제)
• git branch -r (origin 브랜치 정보 확인)
• git switch feature/45_test (브랜치 변경)
• git pull (현재 브랜치 origin -> local)
• git branch (현재 브랜치 확인)

3. test.js 변경 후 커밋

• git stage . or git add . (변경 사항을 스테이징 한다.)
• git commit -m ‘test’ (로컬 브랜치 반영)
• or git commit -a -m ‘리드미 변경 ‘  (신규 파일은 스테이징 선행.)
• git push (origin에 반영)

git 충돌

1. git pull 
2. test.js 파일 변경 후 push -> 에러 발생

• git commit -a -m ‘내역’
• git push
  4.문제 코드 머지
• git status (상태 확인)
• git config pull.rebase false (컨플릭트 코드 머지 ON)
• git pull

5. 합의 후 커밋 (대화)

• git commit -a -m ‘내역'
• git push

fork뜨는 이유

fork를 뜨는 이유는 오리지널 메인을 건들이지 않기 위해 해당 레포에서 작업하고 pr을 한 다음에 아무 에러가 없다면 오리지널 메인으로 push하게 된다

git 예시

git clone codestates - Repo > main 브랜치 > git pull > 브랜치를 다 가지고옴 > git switch feat(FE) > git switch -c feat(FE)/header > 코드 작업 > git add . > git commit > git push origin feat(FE)/header > 깃허브 compare/pull request > feat(FE) PR

git pull 생활화