github로 협업하기

요약
- git은 분산 버전 관리 시스템이다
- github는 코드 호스팅 플랫폼이다.
- commit은 의미 있는 변화다.
- branch는 목적에 따른 분기다.

centralized vs distributed

저장소가 분리되어 있다. 내 컴퓨터에도 저장소가 있고, 깃허브에도 저장소가 있으며 다른 컴퓨터에도 저장소가 되어 있는 것을 분산이라 한다.

  
# apt update
# apt install git
# git --version
# mkdir catkin_ws
# cd catkin_ws
# git init
# git status // 추가가 잘 되었는지 확인
# git clone https://github.com/prgrms-ad-devcourse/ad-3-practice-assignment.git

# touch first
# git add first // 모든 파일을 하고 싶은 경우 git add .
# git commit -m “자율이 3기 화이팅” // "메세지 내용" 
# git push
# git push origin master

협업을 진행하기 전 고려해야 할 사항에는 어떤 것이 있을까?

코딩 스타일 = 코딩 컨벤션 사람마다의 네임 지정과 스타일이 다르다. 회사에 취직하더라도 회사만의 스타일(컨벤션)에 맞춰야 한다. 탭과 스페이스키는 둘 다 상관없지만, 함께 사용하면 오류가 난다.
일을 분배하는 기준 내가 잘하는 부분과 다른 사람이 잘하는 부분이 다르기 때문에 이에 대해 잘 분배를 해야 한다. 시간의 제약도 존재한다. 그래서 어떻게 일을 분배할지에 대해서도 고려해야 한다.
의사 소통 규칙 특정 시간에 서로의 작업 사항을 공유하는 것도 의사소통이고, 특정 문제를 어떻게 해결할지에 대한 아이디어를 도출하는 회의를 만들어놔야 한다. 누군가의 아이디어를 반박할 때는 그 아이디어보다 더 좋은 아이디어를 제시하면서 반박해야 한다는 규칙을 만드는 것도 좋다.
Workflow
- Repository 운영
- branching 전략
- issue, PR 관리

coding style

  
import rospy

from geometry_msgs.msg import Twish
from std_msgs.msg import Float32

cmd_vel_pub = rospy.Publisher("cmd_vel_mux/input/",Twist,queue_size=10,)

  
import rospy
from geometry_msgs.msg import Twish
from std_msgs.msg import Float32

cmdvelpub = rospy.Publisher("cmd_vel_mux/input/",Twist,queue_size=10)

여기서 다른 것은 ,이다. 깃에서 버전 관리를 할 때 ,가 있으면 1줄만 추가하도록 되지만, 아래처럼 ,가 없으면 2줄이 추가된 것으로 인식된다. 또한, 위의 코드에서 맨 아래 1줄 띄우기를 진행하는 것도 다르며, __(underscore)을 추가하는 것은 파이썬 공식 스타일 가이드에 적혀있는 것처럼 추가하는 것이 좋다.

코딩 스타일을 정해야 충돌이 발생하지 않는다.

formatter이라는 코드를 정렬해주는 도구가 있다. git에 커밋하기 전에 black을 한 번 돌린 후 commit하면 충돌할 일이 없다.

black
yapf
isort(import 특화)

변수명을 쓸 때 snakeclass를 사용하거나 변수명에 대한 코멘트에 대한 추천을 해주는 장치인 linter가 있다.

black

  
{
    "[python]": {
        "editor_tapsize"=4,
        ...
    }
}

Workflow

centralized(중앙 집중식) vs forking(distributed)(분산식)

contralized는 관리 포인트가 하나여서 push하면 바로 저장소에 저장이 된다. 내가 변경하여 push하면 다른 사람들에게 바로 변경사항이 추가될 수 있어서 여러 시도를 하기 힘들다. forking은 원본 저장소가 따로 있고, 자신이 commit한 내용을 PR하므로 자유롭게 시도를 적용해볼 수 있다. 그 대신 관리 포인트가 늘어난다.

git flow

어떤 버전을 합칠지, 어떤 버전은 버릴지를 관리하는 방법이다. 여러 개의 브랜치로 인해 매우 복잡하다.

github flow

그에 반해 이 것은 브랜치가 적어서 main에서 추출해서 추가할 브랜치를 추가해서 합친다.

브랜치를 생성할 때 자신이 fix한 내용을 추가해서 feature/fix 등과 같이 작성하는 것이 좋다.

Issue

issue는 문제, 할 일, 관심사 등으로 표현할 수 있다. 코딩 스타일을 어떻게 맞출 것인지에 대한 것도 이슈라고 할 수 있다.

issue labels

이슈를 활용하여 assignee 탭을 통해 누가 맡아서 처리할 것인지를 설정할 수도 있다.

Pull Request

코드를 통합하는 방법 중 하나다. merge를 하면 그냥 혼자 통합하는 것이므로 내 코드가 틀린지 맞는지에 대해 상관하지 않고 합치는 것이다. 그러나 pull request를 하게 되면 나의 코드 검토를 요청할 수 있고, 어떤 기능에 대한 것인지, 어떤 이슈에 대한 것인지 팀원들에게 알려줄 수 있다.

conflict(충돌)

충돌인 채로 merge를 하면 문제가 많아진다. 내가 수정한 파일을 commit한 내용과 팀원이 수정한 파일을 commit한 내용이 다르면 main에서 merge를 할 때 충돌이 일어난다. 여기서 충돌이 일어나면 누가 코드를 commit한 것인지 나오기 때문에 서로 협의를 본 후에 수정해야 한다.

conflict를 해결하는 방법에는 파일을 분리한다. 내가 수정하는 파일과 팀원이 수정하는 파일이 다르다면 conflict가 생길 확률이 줄어든다. 또는 branch를 분리해도 생길 확률을 줄일 수 있다.

conflict가 발생했을 때 파일의 상단에 보면 둘 다 추가할 것인지, 하나만 추가할 것인지 클릭하는 부분이 있다. 그래서 변경 사항을 수정한 후 스테이징상태로 둔 뒤에 merge를 사용하면 된다.

merge 중에 fast-forward 전략이라고 있다. main브랜치보다 다른 브랜치가 더 앞에 있을 때 merge를 하게 되면 그 브랜치로 main이 이동하게 된다. 즉, 그 위치로 main을 이동시킴으로서 변경사항을 pull하는 것이다.

여기서 굳이 그 브랜치를 만들어두고 싶다면, --no-ff라는 인자를 넣어줘야 한다.

git merge --no-ff fast-forward

main에서 git pull을 사용할 때 git config --global 이라는 메시지가 나온다면 ff.only 즉, fast-forward일 때만 pull이 가능하도록 설정해야 한다. 이렇게 설정하게 되면 main브랜치가 merge하려는 브랜치보다 뒤에 있어서 fast-worward가 될 때만 pull을 하겠다는 것이다.

이 때 억지로 가져오고 싶다면 rebase방식을 사용한다. 이는 main 버전에서 가장 마지막에 오도록 위히시키고, 그 전에 commit된 내용들을 모두 검사하고 충돌이 일어나지 않으면 다 다운받아서 pull을 한다.

pull이 충돌이 되었을 때는 서로 작업 사항이, 수정사항이 맞지 않아서 생기는 것이다. 합치는 방식에는 2가지가 있다.

merge방식
rebase방식

merge를 하면 main에서 수정했던 변경 사항과 함께 이전의 변경 사항들을 다 저장한 branch가 생기고, 그것을 merge, 합쳐지게 된다.

$ git pull --no-ff

rebase를 하면 main 변경 사항의 맨 마지막으로 위치시키는 것으로 이전의 모든 변경 사항들을 다운받아지면서 업데이트가 된다.

$ git pull --rebase

Github 추가 기능

Templates

.github/.github/안에 템플릿을 만들어두면 issue를 생성할 때 자동으로 추가되는 템플릿을 추가할 수 있다.

Project & Milestone

project를 생성함으로서 노션의 board와 같이 날짜별로 시각화할 수 있다. milestone을 설정하여 due date를 설정할 수 있다.

Git Hooks

pre-commit이라고 해서 커밋하기 전에 수행해주는 기능들에 대한 설정을 할 수 있다. pre-commit

Git actions

push했을 때 자동으로 돌아가도록 하는 세팅을 말한다.

[데브코스] 7주차 - GitHub로 협업하기