GIT 사용법 - 팀원

0. 컴퓨터 환경설정

git을 사용하기 위해 환경설정을 해준다.
(컴퓨터마다 처음에만 해주는 작업)

git config --global user.name "내 이름"
git config --global user.email "내 이메일"

git config --list <!-- 환경설정이 잘 되었는지 확인 -->

1. 이메일을 통해 organization에 참가

2. 이슈 작성 (Assigneds,Labels 등은 팀장이 설정) 또는 할당받은 이슈를 확인

• issue와 PR(Pull request)은 넘버링은 공유한다. 이슈 하나만들고(#1) PR하나만들면 PR은 #2가 됨

2. 레포지토리를 fork해서 나의 레포지토리로 복사한다.

• 이 때 Copt hte main branch only 체크박스를 해제하여 모든 브랜치를 가져온다.

3. 나의 레포지토리를 Clone하여 작업을 시작하면 된다.

• 1. github에서 Clone 주소를 복사한다.

• 터미널에서 작업폴더를 만들고 이동한다.
• git clone [복사한 주소] 를 입력한다.

git clone [복사한 주소]

• 새로운 branch를 생성한다.

git branch features/fizzbuzz

• 브랜치를 이동한다 (main -> features/fizzbuzz)

git switch features/fizzbuzz

• 작업을 한다. (fizzbuzz.py파일 작성)
• git status확인 후 add 와 commit을 한다.

git status

git add fizzbuzz.py

git commit fizzbuzz.py
# 파일명을 안붙이면 변경된 파일 전부 커밋

• commit시에 commit 내용을 작성한다.

feat: Init fizzbuzz.py

환경, 함수 입력 테스트 완료

 

1. commit의 제목은 commit을 설명하는 하나의 구나 절로 완성
2. importanceofcapitalize Importance of Capitalize (띄어쓰기, 대문자규칙)
3. commit은 동작 가능한 최소단위로 자주 할 것.
4. 해당 작업단위에 수행된 모든 파일 변화가 해당 commit에 포함되어야 함.
5. 모두가 이해할 수 있는 log를 작성할 것.
6. Open Source Contribution시 영어가 강제되지만, 그렇지 않을 경우 팀 내 사용 언어를 따라 쓸 것.
7.  제목은 축약하여 쓰되(50자 이내), 내용은 문장형으로 작성하여 추가설명 할 것. 제목과 내용은 한 줄 띄워 분리할 것.내용은 이 commit의 구성과 의도를 충실히 작성할 것.
8. 팀마다 다를 수 있으니 관련 문서를 참조할 것.
9. 영어로 쓰는 것이 좋다. 제목만큼은 영어로!
10. 내용부분에 close(또는 fixed,resolve, 단수복수과거형 가능) #1 등의 신택스를 사용하면 해당 번호의 이슈도 동시에 다룰 수 있음 
11.  
12. prefix 꼭 달기
    feat: 기능 개발 관련
    fix: 오류 개선 혹은 버그 패치 docs: 문서화 작업
    docs:문서화 작업
    refactor:리팩로팅
    test: test 관련
    conf: 환경설정 관련
    build: 빌드 관련
    style: 주석이나 텍스트 수정(기능의수정은 없어야함)
    ci: Continuous Integration 
13. 커밋하면서 어떠한 기능이 더이상 작동하지 않는다 등의 브레이킹체인지가 있다면 커밋메시지 하단에 푸터에 작성하고 feat!처럼 prefix에 느낌표를 붙여줘야함
14. ref: https://www.conventionalcommits.org/ko/v1.0.0/
15. 예시
    1. (git add 후 git commit을 치면 vim으로 들어간다; vim이 아닐경우 git config --list 에서 조회해보고 수정하면됨)
    2. vim에서 첫줄에 prefix와 제목을 작성후 한줄공백띄우고 본문쓰면 됨
    3. wq로 저장하고 나오면 커밋됨
    4. 또는 git commit -m "제목 내용"을 써도된다. 엔터도 동일하게 들어가지만 쓰는중간에 다시 쓰려면 지우고 다시 써야함
    5. m플래그는 비추 또한 a플래그도 안쓰는 것이 더 좋다. (git add .도)
    6. 이전의 커밋내용을 수정하려면 git commit --amend로 하면됨

 

• 팀 레포지토지의 이슈를 보면서 작업을 계속 해나간다.
• 작업이 끝나면 자신의 레포지토리 features/fizzbuzz (main이 아님)에 push를 한다. (-u 옵션은 원격연결을 앞으로 계속 하라는 뜻)

git push -u origin features/fizzbuzz
# clone을 해오면 origin에 주소를 저장할 필요가 없다.
# -u 옵션은 업스트림, github에는 해당 브랜치가 존재하지 않을 경우 생성을 해달라고 해야한다.

git push --set-upstream origin features/fizzbuzz 와 같은 의미

 

 

 

 

• 원격 레포지토리 포함 모든 브랜치 보는 방법

git branch -a

• 원격 레포지토리가 추적안된다면 먼저 업데이트를 해준다.

git remote update

 

• 만약 원격 레포지토리 추적이 안된다면 직접 추가를 해주어야 한다. 

git remote set-branches --add origin origin/feat

 

• 브랜치목록을 보고 원격 브랜치로 바로 이동 할 수는 있지만 로컬레포가 만들어지지는 않는다.

git checkout -b origin/feat

 

 

• 원격 브랜치가 이미 존재 할 경우 원격 브런치를 와 로컬 브랜치를 연결하면서 생성하는 방법 (위의 방법들은  다 만들고 push하면서 연결이 된다.) feature-01은 생성할 로컬브랜치, origin/feature-01은 존재하는 원격브랜치, 원격브랜치목록을 보려면 git branch -a하면 볼 수 있다.

git checkout -b feature-01 origin/feature-01

• 브랜치 이름을 짓지 않고 remote 저장소의 브랜치 이름을 그대로 로컬 브랜치로 생성하고자 한다면 git checkout 명령어에 -t 또는 --track 옵션을 사용한다.

git checkout -t origin/feat
git checkout --track origin/feat

 

Pull request

• 레포지토리화면에 뜨는 Compare & pull request 를 클릭
• 또는 Contribute 클릭또는 Pull requests 메뉴로 이동하여도 됨
• 나의 레포지토리 features/fizzbuzz 에서 팀레포지토리로 넘어가는 것을 확인하고 PR을 날린다.
• 충돌이 날시에는 추가 작업이 이어져야한다.
• PR 제목이 나중에 버전릴리즈시 작업사항이 되기에 기능에 대한 내용을 축약해서 적어야함
• PR 내용에는 기능에 대한 설명, 전하는 말과 자동화문법이 들어간다.
  • close: PR이 되므로써 해당 issue가 닫히기를 원할 떄
  • fix: 상황을 해결한 경우
  • resolve: 해당 이슈를 이 PR가 해소할 때
  • 과거형 현재형 둘다 됨

 

 

 

이후 팀원, 팀장 코드 리뷰가 이루어 지고 팀장이 PR을 처리한다.

 

PR이 거절당한다면( request change) 메일이온다.

 

추가 작업시에는 그냥 나의 Branch(features/fizzbuzz)에 commit, push를 해주면 팀레포에 자동으로 업데이트가 된다.

 

이후 추가 PR없이 팀장이 해당 PR로 들어가 업데이트된 사항을 확인하고 PR을 처리한다.

 

해당 기능 작업이 끝났다면 자신의 레포지토리에서 브랜치를 삭제하면 된다.

git branch -D features/fizzbuzz

현재 팀 repo를 fork한 내 repo는 팀레포의 작업이 동기화가 안된다. 이를 연결하기 위해 아래의 명령을 한다.

origin을 단축키로 쓰는 것 처럼 upstream이라는 단축키로 등록한 것이다.

git remote add upsteam [팀레포지토리 주소]

git remote -v # 등록된 단축키 목록을 보여줌

push를 할 때는 origin을 쓰고 동기화(pull)을 할 때는 upstream을 쓴다.

git pull upstream main
#또는
git fetch upstream main # fetch를 쓰면 FETCH_HEAD라는 임시 브랜치에 받아온다. 병합하기전 확인하는 용도
git merge FETCH_HEAD

 

 

 

 

 

Git Pull

가끔 협업을 하던 도중 pull을 하지 않고 작업을 진행한 경우가 종종 있다. 이렇게 되면 conflict가 발생할 수 있다.

push가 불가능해진다.

 

해결방법

그냥 git pull origin main을 치면 거부될 것이다. 옵션을 선택해주어야 한다

1. git pull의 방법에는 3가지가 있다.

 

• git config pull.rebase false (기본값: false)
  • 이 옵션을 설정하면 git pull 명령은 가져온 변경 사항을 현재 브랜치에 병합하기 위해 병합(merge) 작업을 수행합니다. 이는 가져온 커밋을 현재 브랜치의 끝에 병합하는 것을 의미합니다. 이 경우, 병합 커밋이 생성되며 기존 커밋 히스토리와 함께 유지됩니다.
• git config pull.rebase true
  • 이 옵션을 설정하면 git pull 명령은 가져온 변경 사항을 현재 브랜치에 병합하기 전에 리베이스(rebase) 작업을 수행합니다. 이는 가져온 커밋을 현재 브랜치의 기반이 되는 커밋 위에 새로 생성하여 덧붙이는 것을 의미합니다. 이 경우, 커밋 히스토리가 선형적으로 유지되고, 기존 커밋이 수정되거나 새로운 커밋이 생성될 수 있습니다.
• git config pull.ff only
  • 이 옵션을 설정하면 git pull 명령은 "fast-forward"만 허용합니다. 이는 원격 저장소의 변경 사항이 현재 브랜치에 이미 포함된 커밋인 경우에만 병합을 수행하도록 합니다. "fast-forward" 병합은 단순히 브랜치를 원격 저장소의 최신 상태로 이동시키는 것을 의미합니다. 변경 사항이 없거나 이전 커밋에 대한 세부 정보가 필요하지 않을 때 유용합니다.

이중 하나를 골라서 명령어를 입력해준다. 예시에서는 rebase:false로 진행한다.

 

2. 충돌난 부분 제거 및 스테이징, 커밋, 푸시

충돌이 나지 않았다면 코드를 두개를 합치고 충돌이 난 부분을 git에서 파일에 표시를 해줄 것이다.<<<<<<<< HEAD 

작업한 부분

==========

pull해온 부분

>>>>>>>>>>> dlksdpoaij214o2ok41jp

 

위와 같이 파일에 추가 되어있을 것이다.

이것을 직업 수정하여도 되고 IDE의 기능을 이용하여 수정할 수도 있다. intellij의 경우 파일우클릭 -> Git -> resolve 클릭

수정을 하게 되면 스테이징하여야 한다. git add

그다음 다시 커밋을 해주는데 이 때는 git commit 파일명이 아닌 그냥 git commit이다.

그 다음 git push를 진행해주면 된다.

 

 

 

위의 방법으로도 충분하지만 다른 방법도 있다.(딱히 쓸 일 없음(혼자작업하는 경우에 쓸만함), 하지만 stash는 알아두는 것이 좋다)

만약 이미 새로운 작업을 완료하고 커밋(commit)까지 했는데, 이후에 git pull을 실행해야 한다면 다음과 같은 방법을 사용하여 수정한 작업을 보존할 수 있다

1. git stash: 이 명령어를 사용하면 현재 작업 디렉토리의 변경 사항을 임시로 저장할 수 있다. 수정한 파일 및 새로운 작업은 stash(stack)에 저장되며, 작업 디렉토리는 이전 커밋 상태로 되돌아간다.
2. git pull: 원격 저장소에서 변경 사항을 가져온다. 이 명령어는 pull.rebase 또는 pull.ff 옵션에 따라 병합(merge) 또는 리베이스(rebase) 작업을 수행할 수 있다. git stash를 사용하여 작업을 임시로 저장했기 때문에 작업 디렉토리는 깨끗한 상태에서 pull 작업을 진행할 수 있다.
3. git stash pop: git stash로 저장한 작업을 다시 복원한다. 이 명령어를 실행하면 stash에서 가장 최근에 저장한 작업이 복원되고, 작업 디렉토리는 수정한 상태가 된다. 이제 수정한 작업이 적용된 상태로 작업을 계속할 수 있다.

위의 방법은 push가 가능하게 해줄 뿐!

 

아래는 이 과정을 요약한 명령어들의 예시:

# 현재 작업을 stash에 저장

git stash

# 원격 저장소에서 변경 사항 가져오기

git pull

# stash에서 작업 복원

git stash pop

위의 절차를 따르면 수정한 작업을 임시로 저장하고 git pull을 실행한 후, 작업을 다시 복원하여 수정한 작업을 적용할 수 있다.

 

 

 

 

실수로 올리면 안되는 코드를 올렸을(push) 경우!! (yaml파일등 비밀번호가 포함된 파일)

1. git log를 쳐서 로그 기록을 본다.

git log

2.해당 커밋이 몇번째인지 본다. 첫번째라면 ^한개 10번쨰라면 ^ 10개 를 입력해 그 상황때까지 리셋시킨다. 해당커밋하나만 지우는게 아니다. ^갯수만큼 삭제 된다.

git reset HEAD^^^^^^^^^^

3. 리모트 리포지토리에 푸시한다.

git push -f origin main

4. 로컬 파일에서는 파일은 사라지지 않고 Commit이 안된 상태로 돌아간다.

 

 

Merge Conflict 해결법

머지를 하다보면 충돌이 날 수 있다.

이 때는 중재를 해서 해결할 수 있다. 충돌 후에는 status가 머지컨플릭트가 된다. 이때는 다른작업 커밋이 안될 것이다.

머지를 먼저 해결해야 한다. 충돌난 파일을 들어가보면 <<<HEAD같은 특수문자가 있고 충돌된 내용들이 두가지 모두 나타날것이다 이것을 수정해서 커밋하면 된다.

 

REBASE 충돌 해결법

REBASE의 경우 REBASE는 시점을 바꾼다.(두 팀원이 하나의 파일을 가지고 수정을 하고 팀원A가 먼저 커밋을 하면 B는 A가 수정한 것 기준으로 REBASE를 한다면 충돌이 날 수 있다. continue(진행) abort(취소)를 선택하면된다

 

 

 

 

 

 

git 관련 코드가 간략히 정리된 글(링크된글 내용과 이 글은 조금 차이가 있음): https://velog.io/@minwest/github를-이용한-협업-쉽게-이해하기