Git, Github 2 - git flow

상황별 되돌리기

git flow를 이용해서 어떤 작업을 하더라도 feature branch를 생성해서 하는 것을 권장한다 (main branch는 실제 서비스를 담당하는 부분이기 때문에 main branch에서 실수를 할 수도 있기 때문이다)

또한 develop branch에서 commit을 하지 않는 것을 권장한다 (feature branch를 생성해서 하는 것 권장!)

▶️ 파일의 이름을 바꾸거나 이동시킬때

cmd나 터미널에서 mv [file-name] [path]를 이용해서 파일의 경로를 변경하거나 이름을 변경하는 경우 git에서는 파일이 이동하거나 이름이 변경된 것을 인식하지 못한다 → 기존의 파일이 삭제되고 새로운 파일이 생성됬다고 인식

따라서 git에게 파일을 이동하거나 이름을 변경한다고 전달해주어야 한다 이때 명령어 앞에 git을 붙여주면 된다

git mv [file-name] [path]

// ex
git mv README.md readme2.md

이렇게 했을 경우 git status로 확인하면

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	renamed:    README.md -> readme2.md

renamed라고 이름이 변경됨을 인식할 수 있었다

▶️ 파일을 수정하고 최신의 commit으로 돌아가는 경우

여러 파일을 수정하다가 꼬여서 최근의 commit으로 돌아가야 하는 경우가 있다 이럴때는 다음과 같은 명령어를 사용한다

// 하나의 파일
git checkout -- [filename]

// 여러개 파일
git checkout -- .

최근 checkout이라는 명령어가 변경되어 restore로 사용가능하다 (현재 둘다 사용가능)

▶️ 변경사항을 잘못 add 했을때

git reset HEAD [filename]

HEAD는 현재 가르키는 최신상태이고 이를 reset하는 명령어이다

▶️ 가장 최신의 commit을 수정하는 방법

commit message를 입력하다가 잘못 입력한 경우 가장 최근의 commit을 수정하는 다음과 같은 명령어를 사용하면 된다

git commit --amend

vi 창이 열리면서 수정이 가능하다

▶️ commit을 취소하는 방법

commit을 수정하기 위한 방법으로는 두가지로 볼수 있다

1. 강제적으로 commit 취소

   git reset —-hard HEAD~3
   git push -f origin [branch]
   

   –hard는 굉장히 위험한 flag로 권장하지 않는다

2. 잘못된 commit을 두고 새로 수정하는 방법

   git revert --no-commit HEAD~[개수]..
   

   revert는 하나를 되돌릴 때마다 commit이 하나씩 작성되기 때문에 --no-commit은 이런 commit을 작성하지 않도록 한다

revert를 사용하면 잘못을 인정하고 되돌리는 commit을 다시 작성하는 형식이다

반면에 reset --hard를 이용한 commit의 취소는 강제적이다 그러나 내가 commit을 강제적으로 취소했더라도 다른 동료가 이전에 그 파일을 가지고 있었다면 좀비파일처럼 계속해서 다시 생기는 경우를 볼 수 있다

따라서 revert를 수행하는 것을 권장한다

revert를 수행할때 고민할 수 있는 부분이 있는데 만약 feature branch를 생성하고 작업을 하고 있었다면 잘못 되었을때 branch를 삭제하고 아에 새로하는 방법을 선택하지 아니면 revert를 수행해서 어느정도의 commit을 취소한뒤 재작업할지 고민할 수 있다 →

git flow

git flow를 이용해서는 다른 동료들과 협업을 진행할 수 있다 → issue, project

▶️ Issue

프로젝트를 진행라면서 해야할 일들, log를 등록할 용도로 사용할 수 있다

- Label

해당 이슈가 어떤 카테고리에 속하는지 지정할 수 있다

- Milestone

보통 각 기능별 단위별 데드라인을 지정할 수 있다

• 이슈를 작성할 때 - [ ]를 이용해서 checkbox를 만들 수 있다
• 하나의 작업(checkbox 하나)를 완료하고 checkbox에 체크를 한다
• 이슈를 작성할 때 이유를 같이 명시하는 것이 좋다
• 팀장이 Assignees로 이슈의 담당원을 명시할 수 있다

▶️ Project

project에서는 이슈를 개별로 backlog, todo, done의 구간으로 옮길 수 있다

• 모든 backlog를 done의 공간으로 옮겨야 한다

▶️ team 단위의 협업

team 단위로 작업을 할 수 있는데 이때 방법이 두가지가 있다

1. cooaborator를 추가하는 방법(권장x)
   • 팀장이 manage access를 팀원에게 할당한다 (권한을 줌)
   • 원본에 바로 밀어넣는 형태이기 때문에 잘못하면 원본이 꼬일 수 있다
2. fullrequest 팀원은 사본을 가지고 작업하고 원본에 반영이 되도록 팀장에게 요청하는 방법

▶ 팀장의 역할

1. 새로운 repository를 생성
2. clone 진행
3. branch를 생성한다 (git flow init)
4. 대상 파일 생성 (touch [file-name])
5. git add [file-name]
6. commit message와 함께 commit을 진행한다 (git commit)
7. git push -u origin develop (처음이라면 -u 플래그를 사용한다)

▶️ 팀원의 역할

1. 팀장이 생성한 repository 주소를 받는다
2. 팀원이 스스로 Issue를 작성한다
3. FORK를 진행해서 사본을 만든다(개인의 repository)
4. FORK한 repository의 주소로 clone을 진행한다 (git clone [forked-repo])
5. git flow init: branch를 생성한다
6. Feature branch를 생성한다(git flow feature start [branch-name])
7. 작업을 완료하고 git add [file-name], git commit을 진행한다
8. 마지막 commit에서는 이슈가 마무리 되었음을 알리기 위해 resolve, close, fix과 넘버링된 이슈를 입력해준다(resolve [issue-numer])
9. git flow feature finish [branch-name]
10. git push origin develop (첫 push인 경우 -u를 추가한다)
11. fullrequest를 진행한다
12. 수정사항이 있을시에 develop branch에서 add, commit, push를 진행하고 팀장이 확인한다

여러명이서 진행하다보면 파일 충돌의 위험이 있다 이럴때는 다음과 같은 과정을 진행한다

git remote add upstream [leader-repo]
git fetc upstream develop
git merge FETCH_HEAD

자신이 수정한 파일에 충돌이 된부분을 해결하고 ad,, commit, push한다