TIL 2022-09-16 (금) 3일차

오늘 배운 것

0.5 Rename

우리는 단순히 이름만 바꿔야 하는 상황이 종종 있다. 이름을 바꾸는 것은 따로 정해진 명령어가 있는 것은 아니다. 하지만 방법이 없는 것은 아니다. 바로 mv 명령어를 이용하는 것이다.

mv '현재 이름' '바꿀 이름'

mv를 통해서 현재 있는 파일의 이름을 바꿀 수 있다. 물론 다른 디렉토리로 옮기는 것도 한 번에 할 수 있다.
그러나 git을 사용하는 경우에는 한 가지 더 생각해야하는 부분이 있다. 바로 이 과정의 오류인데
mv 명령어는 이름을 바꾸는 명령어가 아니기 때문에 기존에 있던 파일을 삭제하고 똑같은 파일을 다른 이름으로 생성하는 과정을 실행한다. 따라서 git은 기존의 파일이 삭제되고 다른 이름의 파일은 생성되었다고 판단한다.

이를 위해서 우리는 mv 명령어 앞에 git을 붙여서 미리 이름을 바꾸는 것이라고 알리는 것이 필요하다.

git mv '현재 이름' '바꿀 이름'

물론 commit을 해주는 과정은 필요하다.

1. Revert

일을 하다 보면 때로는 실수를 하는 경우가 있다. 프로그래밍을 할때에도 마찬가지의 상황이 일어날 수 있다. 하지만 당황하지 않아도 된다. git에서는 이를 고치기 위한 방법이 마련되어있다.

여러가지 상황에서 일어날 수 있는데 크게 Working directory, Stage, localrepo 세 가지의 상황에서 되돌리는 방법에 대해서 알아보기로 하자.

• Working directory
  커맨드에서 작업을 하다가 말 그대로 Undo 되돌리기를 하고싶은 경우를 의미하는데 간단하게 할 수 있다.
  파일을 수정하거나 삭제, 이동 등의 명령을 내렸다가 되돌리고 싶은 경우

  git restore "파일 이름"

  해당 명령어를 통해서 간단하게 되돌릴 수 있다.

• Staging area
  만약 git add를 통해서 stage에 작업물을 올린 경우에도 아직까지는 쉽게 해결할 수 있다.

  git reset HEAD "파일 이름"

  해당 명령어를 입력하면 git add를 통해서 commit을 하기위해 stage에 올린 파일들을 다시 취소할 수 있다.
  보통 commit을 하는 과정에서 git add . 이라고 입력해서 모든 변경사항을 한꺼번에 commit을 할 수도 있지만 이 경우에는 기록을 하는 입장에서 올바르지 않은 행동이다.
  여러가지 작업을 한꺼번에 commit을 하면 확인을 하는 입장에서 정확하게 파악하기 힘들기 때문이다. 따라서 종류가 다른 작업물들은 따로 commit을 해주는 것이 좋다.

• Localrepo

commit을 실행하고 뒤늦게 실수를 깨달았다면 실수를 수정하는 과정을 거쳐야한다. 물론 없었던 일로 하면서 다시 commit을 하는 방법도 있겠지만 여러 사람이 함께 작업을 하는 과정에서 오해를 만들 수 있다. 따라서 수정을 했다는 이력을 남기는 것이 좋은 방법이다.

우선 자신이 한 commit의 로그를 파악한다.

git log

git revert --no-commit HEAD~3..
가장 최근 commit 3개를 되돌린다

단 모든 과정은 remote repo에 push되기 전에 진행되어야 한다. 이미 업로드가 되었다면 변경사항을 적용 후 다시 push하도록 하자.

2. Collaborate with team

이제 우리는 github의 목적인 여러 명이서 협업을 하는 과정에 대해서 알아보도록 하자. 우선 크게 두 그룹인 팀장과 팀원이 해야할 일을 따로 설명하도록 하겠다.

팀장의 경우 먼저 organization을 생성해서 팀을 하나 만들어야 한다.
github에서 쉽게 생성할 수 있다.

그 다음 만든 organization에 팀원들을 초대한 후 작업이 이루어질 Repository를 생성한다.
git flow를 위한 기본적인 세팅과 Issue 템플릿 등을 설정하고 팀원들에게 공유한다.

develop branch 까지 성공적으로 만들어졌다면 작업할 repo에 push해서 팀원들이 fork를 진행할 수 있도록 한다.

이제 기본적인 설정은 끝났다.

팀원의 경우 팀장이 만든 repo에 초대받고 Fork를 통해서 자신의 remote repo로 우선 복사해와야 한다. 이 과정은 여럿이서 한 번에 push 하는 일이 생기는 경우 conflict나 동시에 여러 작업들이 실행되면 헤깔릴 수 있기 때문에 편의를 위해서 하는 것이 필요하다.

그 다음 issue를 등록하는 것이 중요하다.
내가 해야할 일을 미리 팀장에게 알리고 진행상황을 공유하는 것이 중요하기 때문이다.

Assignees와 Labels 설정도 잊지말고 꼭 하도록 하자

그 다음 자신의 remote repo에 가져온 repo를 clone해서 작업을 진행하면 된다.
물론 git flow를 통해서 branch를 생성해서 작업을 진행한다.

작업이 진행됨에 따라서 Issue를 실시간 반영하는 것이 좋다.
작업의 commit 완료하고 push를 하면 본인의 remote repo에 작업물이 올라갈 것이다.
이 때 팀의 repo에 자신의 작업물을 반영하기 위해서는 Pull requests를 해야한다.

대상과 branch를 잘 보고 반영해야한다.

정상적으로 이루어 질 수도 있겠지만 conflict가 발생하거나 오류가 발생할 수도 있다.
conflict가 발생하는 경우 다시 로컬 repo로 받아와서 수정을 한 후 반영해야한다.

이를 위해서는 우선 git에서 팀 repo에 연결을 해야한다.

이 후 pull을 통해서 작업해야할 사항을 받아오면 된다.

git pull upstream develop

conflict가 발생한 부분을 모두 수정하고 다시 push를 해주면 된다. 지금은 이전에 pull request를 진행한 적이 있으므로 바로 반영이 될 것이다.

팀장은 이 부분에서 팀원의 코드 리뷰를 진행하면 된다. 리뷰 이후 수정해야할 사항이 있다면
local repo로 다시 pull해서 똑같이 진행하면 된다.

수정된 사항을 확인한 후 팀장이 merge를 진행하면 된다.

모든 팀원들의 작업결과를 Pull request를 통해서 받았고, 추가적인 수정 사항이 없는 경우
팀장은 git flow release를 통해서 main branch에 반영하면 된다.

팀원들은 모든 과정이 끝난 결과물을 다시 공유받으면 모든 작업이 끝이 난다.

팀원 또는 팀장과 의사소통을 계속해서 하는 것은 매우 중요하다.

내일 할 일

• 한 주 돌아보기

돌아보기

처음으로 이렇게 git과 github를 통해서 협업을 진행해보았다. 학교에서 배울 때는 이렇게 모든 과정을 git을 통해서 진행하지는 않았었는데 직접 파일을 전달해주거나 코드를 복사해서 보내주는 등의 방법보다 복잡할 수는 있겠지만 확실하게 협업을 하고있다는 느낌을 들게했다.
익숙해진다면 오히려 더 쉽게 작업을 진행할 수 있을 것 같다. 물론 로컬로만 작업하는 것이 아니기 때문에 commit이나 push를 진행하는 과정을 좀 더 신중하게 해야함을 느꼈다.

참여한 실습 프로젝트
https://github.com/fc-2line-left-team/pig-the-dice-game