[FE - ConnecTo] DAY27 TIL👩🏻‍💻

22.08.17 수업을 통해 공부한 내용들을 정리하였습니다 😊
피드백은 언제나 환영입니다! 🍊

✅ 협업 및 프로젝트 시 회고

협업 및 프로젝트를 할 때, 스프린트 미팅, 킥오프 미팅, 회고 등등 체크를 하고 넘어가야 무엇을 배웠는지, 얻어가는 것들이 있습니다.

회사에서도, 보통 스프린트 주기 동안 마지막날에는 코드 리뷰, 회고, 다음 전략 등을 짜기 위해 하루를 다 보낼 정도로 중요한 작업입니다.

프로젝트에 대해 회고를 할 때는 다음과 같이 3가지 섹션으로 나눠서 정리를 합니다.

1. Liked ( 좋았던 점 )
2. Learned ( 배우고 느낀 점 )
3. Lacked ( 아쉬웠던 점 )

그래서 잠깐, 저번 깃 수업 때 했던 미니 프로젝트에 대한 회고를 정리해보고 넘어갔으면 합니다.

🎲 미니 프로젝트 (Pig The Dice Game)

• Liked
  git flow에 대해서 제대로 적용해보고, 팀원간의 협업하는 과정을 배울 수 있어서 좋았습니다.
• Learned
  git flow 동작 원리 및 CLI를 이용하여 기능을 익히고, 작업해볼 수 있는 좋은 기회였습니다.
• Lacked
  팀 협업이지만, 프로젝트가 동시 다발적으로 작업했던 것이 아니다보니, 차례 차례 진행되는 과정에서 시간이 약간 지체된 부분이 아쉬웠습니다.

사실, 프로젝트를 할 때는 모두의 역량이 중요하긴 한데, 팀장의 역량이 더 중요합니다.

팀장은, 우리의 팀원 들을 기분 나쁘지 않게 몰아붙여 생산성을 높이는 것이 중요합니다. 그렇다고, 갑질을 해서는 안 될 것이고, 동기부여를 열심히 해줘서, 팀원들이 방향을 잃지 않게 지시해주고, 서포트 해주고 이끌어주는 것이 중요합니다.

그리고, 코드 리뷰 또한 중요합니다.

팀장 혼자 리뷰를 하는 것이 아니고, 담당 리뷰어가 하는 경우도 있고, 팀 전체가 모여서, 프로젝트를 쏘고 다른 사람들이 의견을 제시하는 그런 경우도 있으며, 종종 스프린트 마지막 날에는 의미 있는 코드 리뷰를 하는 경우도 있습니다.

그래서 꼭 회고하는 시간을 가지면 좋겠고, Final 프로젝트 때에는 스프린트 단위별로 회고하면 좋을 것 같습니다.

---

📌 오늘 수업 목표
내가 협업을 하다 실수를 하거나 잘못했을 때 되돌리는 방법을 배웁니다.
push하기 전의 단계(작업 전에 add, commit 등을 할 때) 되돌리는 방법에 대해 하나씩 배웁니다!

git에서 파일명 바꾸기

버전 관리라는 측면에서 보면, move 명령어는 위험성이 있습니다.

$ ls
// README.md

$ mv README.md unread.me
$ ls
// unread.md

$ git status

이미 tracking 하고 있는 파일에 대해서 그냥 바꿔버리면, 다음과 같이 기존 존재하던 README.md가 지워지고 unread.md가 새로 생겼다고 판단하고 있어서, 버전 관리의 측면에서 연속성이 떨어지게 됩니다.

따라서, 내용은 같은데 이름이 바뀐다고 한 번 더 해석을 해야하는 경우가 발생하게 되기 때문에, 상태를 되돌려보겠습니다..!

우선 똑같이 이름을 바꿔주면, 다음과 같이 복구가 됩니다.

$ mv unread.me README.m

그러면 어떻게 해야 올바른 방법일까요?

다음과 같이 move 명령어 앞에 git을 붙이면 해결이 가능합니다.

$ **git** mv unread.me README.md

이름을 변경하는 것은 선언만 하면, add 할 요소가 없기 때문에, 바로 commit을 할 수 있습니다!

---

파일 수정을 했는데, 되돌리고 싶을 때는?

$ git checkout -- unread.md
// checkout은 약간 구시대적인 언어라서, 다음과 같이 restore를 사용하는 것이 좋습니다.

$ git restore -- unread.md

// 파일이 여러 개인 경우,
//  아래와 같이 입력하면 현재 위치 아래로 모든 파일의 변경 사항을 취소할 수 있습니다.
$. git restore .

---

Stage에 올렸는데 수정해야 할 때..

회사에서 일을 하거나, 협업을 하다가 할 일을 다 하고 방금 commit을 하고, push 직전이었는데, 갑자기 수정하라는 요청이 들어왔습니다. 이런 경우, unstaging을 하면 됩니다.

$ git reset HEAD {filename}

만약, unstaging 하면서 바로 지우고 싶다면, 다음과 같은 방법을 사용하면 됩니다.

$ git rm -f {filename}

---

rebase vs merge

• rebase가 필요한 상황? 협업하면서 다른 사람 작업하던 것이 중간에 들어오는 상황에 브랜치를 땄던 위치를 바꿔서 base를 옮겨줍니다! 즉, conflict를 바로바로 받은 것이 rebase 솔루션입니다.
  

• merge는 그럼 언제...? 작업하다가 중간에 변경사항이 들어왔다? → 지금 참조하는 것이 아니라, 마지막에 들어갈 때 conflict를 일으켜서 merge를 끝내도록 작업하는 것입니다.
  

둘 중 어느 방법이 좋은가..를 생각해보면,
팀원의 수가 많으면 많을수록 merge 방식의 솔루션이 훨씬 효율적입니다.

n명의 pull request를 받으면 n개의 rebase가 필요한데, 이러한 경우에는 마지막에 conflict를 일으켜서 최종 merge 하는 것이 훨씬 좋습니다.

---

커밋 엉망으로 해놓고, 직전 커밋 수정하기

commit을 할 때는 긴장감을 가지고 해야합니다.

바로 직전 commit 실수라면, 그럴 수 있다.. 생각할 수 있지만, 10일 전, 100개 전 등의 커밋을 수정하려면, 이건 문제가 있다고 판단이 되기 때문입니다.😡

$ git commit

commit 수정을 위한 명령어는 다음과 같습니다.

$ git commit --amend

commit 수정 완료! ✌🏻

+) 추가사항

rebase 명령어를 사용하면 commit 날짜를 수정할 수 있습니다..! 👀 (악용할까봐 더 말을 안하심..😂)

---

이미 올라간 commit 취소하기(없던 일로 만들기 2가지)

• 흔적 조차 지우는 방법
• 특정한 시점으로 되돌려 놓을게요(반성문) 권장!

history나 버전 관리의 측면에서도 같은 맥락입니다..!

잘못된 이력을 남겼던 것을 push 해놓고, 나한테서만 지운다고 이 문제가 해결이 되는 것이 아니기 때문입니다.(근본적 해결 x)

이렇게 되었을 때, 사과를 빨리하십시오… ( 죄송합니다.. 파일 되돌릴게요… ㅠㅠ )

이렇게 한다면 문제가 커지지 않습니다..

그리고 rest 명령어를 사용해서 지웠을 경우에,
이렇게 지워도 이력이 남아있기 때문에, 있던 일을 없게 만드는 건 어렵습니다!!!!!

그렇다면 어떻게 해야할까요?

다음과 같이 실습해봅시다.

1. 파일 생성

$ touch a.md
$ touch b.md
$ touch c.md

1. 연속해서 3개의 잘못된 커밋하기

$ git add a.md
$ git commit

$ git add b.md
$ git commit

$ git add c.md
$ git commit

1. 되돌릴건데, 한 번에 commit 할 거고요.. 지금으로부터 3개 전까지 할 거에요…

$ git revert --no-commit HEAD~3..

📍이 때, no-commit 명령을 안주면 하나씩 건너갈 때 마다 일일히 commit을 찍어야 합니다!

a, b, c가 지워졌다 그런 건 보이지 않더라도, 만들기 전 상태로 되돌리는 것은 가능합니다!

---

그렇다면 현업에는 어떤 방식을 사용하나요??

팀마다 reset이나 revert 중 어느 것을 선호하는지는 모르지만, revert를 선호하는 편인 것 같기도 합니다.

commit을 되돌릴 때도 사용하지만,

merge 했던 commit을 취소할 때도 revert를 사용하는데, 그 때는 -m 플래그를 사용해서 쓰면 됩니다!

다만, merge commit 은 메세지가 다르게 뜰 수 있습니다!!!

---

🕰 미니 프로젝트 실습! (StopWatch)

어떻게 하면 충돌을 피할 수 있을까에 포인트를 두고 현실적으로 협업해보기!