Git과 GitHub _ (1) 개인 프로젝트 관리

---

GitHub Token

 

예전 GitHub에서는 인증할 때 아이디/패스워드를 사용해서 로그인 인증을 했는데

2020년 7월 이후 깃헙 정책변경으로 토큰 인증이 필수적이라고 합니다.

 

그리고 지금 2024년 11월 30일 기준으로 봤을 때

PAT ( Personal Access Token ) 이 아닌 Fine-grained Token 이 새로 생겼네요.

 

위 Fine-grained Token은 2022년 10월에 베타버젼으로 출시 되었고
2023년 7월에 정식으로 출시된 토큰이라고 합니다.

 

기존에 있던 Personal Access Token과 비교해봤을 때 주요 특징은

1. 리포지토리(저장소) 단위로 접근 권한을 설정할 수 있음.

 

2. 각 권한에 대해 읽기/쓰기 수준을 개별적으로 지정할 수 있음.

 

3. 만료 기간을 최대 1년까지 설정할 수 있음.

 

작성날짜 2024년 12월 1일기준 최대 1년 가능

 

4. 토큰의 사용 현황을 추적할 수 있음.

 

---

왜 아이디/패스워드가 아닌 토큰을 사용하는건지?

 

그런데 일단 토큰이라는걸 왜 사용하는지 의문이 있었는데,

내가 내 계정에 있는 프로젝트를 관리하는데 토큰을 사용해서 권한을 설정한다?.. 라는 개념 자체가 이해가 안됐습니다.

 

내가 관리하는 프로젝트들인데 나의 권한을 일부러 제한하는 이유가 뭐가있을까요?..

예를들어서 내가 팀장이고 이 프로젝트에 대한 팀원들에게 권한을 부여하는 개념이라면 이해가 되지만
개인이 사용하는건데 왜 토큰을 만들고 권한을 부여하는걸까..... ?

그림1

 

위와같은 생각으로 이해가 되지 않아서 검색을 해봤는데

토큰을 사용하는 경우를 먼저 정리해봤어야 했네요...

 

토큰을 사용하는 경우를 정리하면 아래와 같습니다.

 

• GitHub API를 직접 호출할 때
• CI/CD 파이프라인 구축할 때
• GitHub Actions 사용할 때
• 커맨드 라인에서 직접 git 명령어로 작업할 때
• 자동화 스크립트를 만들 때

 

 

즉, 토큰은 주로 자동화된 시스템에서 필요하며, 일반적인 개발에서는 단순인증용도로만 사용되고있습니다.

권한 설정은 자동화 도구가 필요한 최소한의 권한만 가지도록 하기 위한 것인거죠.

 

저희처럼 단순히 Source Tree를 사용하여 프로젝트를 관리할 때에는 Git Credential Manager를 통해 자체적으로

인증 처리를 하기 때문에 토큰을 사용하지 않습니다.

 

 

좀 더 디테일하게 들어가보면 자동화에서 권한 설정이 필요한 이유는 보안 때문인데요,

아래와같은 상황이 생겼다고 가정해보겠습니다.

 

1. 개발자들이 코드를 GitHub에 올리면
2. 자동배포 서버가 이를 감지하게 되고
3. 새 코드를 읽어서 ( Read ) 실제 서비스에 배포하게 된다.

그림2. 자동배포 사이클

 

상황을 정리해보면

 - 코드를 읽어서 배포하는 권한은 필요
 - 하지만 코드를 수정하거나 삭제하는 권한은 불필요
 - 다른 저장소(프로젝트)에 접근할 필요도 없음

따라서 필요한 최소한의 권한만 가진 토큰을 만들어서 사용하는 것인거죠.

 

제가 이해하기가 어려웠던 이유는 위 자동화 예시들은 저와같이 장비/설비를 개발할 때 사용하는 방식이 아닌

웹/앱 서비스를 기준으로 많이 사용하는 것들이었기 때문이었네요 .😅😅

 

저희 팀처럼 로봇, 설비, 장비를 만들때에는 특수한 경우를 제외하고는 위와같은 자동화기능이 있으면
오히려 좋지 않을 수가 있는데, 배포를 할때에 고려해야할 상황들이 있기 때문입니다.

 - 실제 하드웨어로 테스트가 필요하고
 - 현장에서 직접 확인을 해야하며
 - 현재 생산하고 있는 라인에 영향을 줄 수 있기 때문

 

그림3. 설비 앞에서 dll 업데이트

그래서 보통 우리는 직접 설비, 장비에 찾아가서 USB, 하드등을 사용하여 dll을 업데이트 해주는 방식으로 진행되는데

이 또한 그냥 되는것이 아닌 생산설비를 잠깐 멈출 수 있는 시간을 해당 업체 관리자가 3~4시간정도 빼서 스케쥴을 주면

그 때 딱 시간을 맞춰서 dll을 넣고 실제 테스트를 해보는 방식으로 진행이 되곤 합니다.

---

CI/CD 그리고 테스트코드

 

테스트코드에 대한 내용도 CI/CD의 개념에서 나오는데 
CI는 Continuous Integration로 지속적 통합이고
CD는 Continous Delivery / Deployment으로 지속적 배포라고 합니다.

개발자들이 열심히 각자의 기능들을 개발해서 자동으로 합치고
합쳐진 코드를 올리면 자동으로 배포하게 되는데

GitHub에서 위와같은 코드가 업데이트 되고나면 
GitHub Actions 혹은 Jenkins에서 코드가 업데이트 되었다는 알림을 받아서
자체적으로 테스트를 진행해보고 문제가 없으면 자동으로 배포한다고 합니다.
( 위 그림2 참고 )

 

그런데 여기서 "테스트를 진행해보고" 가 이해가 잘 안되었는데

웹/앱 서비스를 배포하기 전에 미리 지정한 Test코드를 

GitHub Actions , Jenkins에서 한번 실행해보고 오류,버그가없이 잘 돌아가면

배포하는 기능이 있다고 합니다

 

설비/장비를 개발하는 개발자의 입장에서 상상도 못할 정말 좋은 기능이라는 생각이 들었습니다.

장비개발자는 일단 설비앞으로 가야하고,
실제 눈으로 보면서 움직이는지 확인해야하고,
움직이는게 내가 원하는 방식으로 정확히 움직였는지 확인해야하고....

이러한 이유때문에 자동화 테스트를 하기가 정말 힘들죠. 

 

만약 자동화 테스트라고 한다면 일단 메뉴얼로 장비 안정화를 모두 끝낸 뒤에 
잘 돌아가는지 시퀀스를 계속 돌려보면서 테스트하는것(?)...

 

혹은 각각 모터, 카메라(Vision), 입출력 (Digital Input/Output), 센서 등의 시뮬레이션 프로그램을 Unity로 직접 만들어서
3D 환경을 직접 만들어 테스트코드를 돌려보는 것...

 

만약 개발자가 없는 상황에서 자동화를 하게되면 어떤 에러가 발생하면서 장비가 망가질지 모르기 때문에
위 시퀀스 자동화도 초기에는 개발자가 앞에 상주해있어야 합니다 😂 😂

 

 

---

Git 단축키 사용법

 

Git은 소스 코드의 버전 관리를 위한 시스템입니다.

마치 게임의 세이브 포인트처럼, 코드의 특정 시점을 저장하고 관리할 수 있게 해줍니다.

 

이전에는 Git을 사용할 때 단순히 변경사항만 커밋했었는데, 이제는 체계적으로 관리하는 방법을 정리해보려고 합니다.

 

보통 어떤 방식으로 Git을 사용하는지 찾아보고 정리해보았습니다.

---

기본 명령어 구조 1. Add ( 스테이징 )

# 변경된 파일을 스테이징 영역에 추가
git add [파일명] # 특정 파일만 추가
git add . # 모든 변경사항 추가
git add *.py # 특정 확장자 파일만 추가

 

기본 명령어 구조 2. Commit ( 커밋 )

가장 널리 사용되는 Conventional Commits 라는 규칙인데 다음과 같은 구조를 가진다.

type(scope) : subject
body
footer

주요 type들을 아래과 같다.
 - feat: 새로운 기능 추가
 - fix: 버그 수정
 - docs: 문서 수정
 - style: 코드 포맷팅, 세미콜론 누락 등 (코드 변경 없음)
 - refactor: 코드 리팩토링
 - test: 테스트 코드 추가/수정
 - chore: 빌드 작업, 패키지 매니저 수정 등

실제 사용 예시를 보면

 """
feat(auth): 소셜 로그인 기능 추가
 - 구글 로그인 구현
 - 페이스북 로그인 구현

Resolves: #123
See also: #456
"""

나는 장비/설비 개발자이니 다음과 같은 구조를 사용하면 좋을 듯 싶다.

'''
feat(servo): XYZ 서보 모터 제어 로직 추가
 - 가속/감속 알고리즘 구현
 - 위치 보정 기능 추가
 - E-stop 안전 로직 통합

Tests: 100회 반복 테스트 완료
Safety: 비상정지 기능 검증 완료


fix(sensor): 온도센서 드리프트 현상 수정
 - 칼만 필터 적용하여 노이즈 제거
 - 센서 보정 주기 30분으로 변경

Related: #234

docs(manual): 정기 유지보수 매뉴얼 갱신
 - 윤활유 교체 주기 수정
 - 벨트 장력 점검 절차 추가
 - 예비품 리스트 업데이트

Reference: ISO 13849-1 안전기준 준수

 

기본 명령어 구조 3. Push/Pull ( 원격저장소 동기화 )

# 원격 저장소에 업로드
git push origin [브랜치명]

# 원격 저장소에서 가져오기
git pull origin [브랜치명]

# 원격 저장소 변경사항 확인
git fetch

 

기본 명령어 구조 4. Branch ( 원격저장소 동기화 )

# 브랜치 생성 및 관리
git branch [브랜치명] # 새 브랜치 생성
git checkout [브랜치명] # 브랜치 전환
git checkout -b [브랜치명] # 생성과 전환 동시에
git merge [브랜치명] # 브랜치 병합

 

기본 명령어 구조 5. Revert ( 되돌리기 )

# 변경사항 되돌리기
git revert [커밋해시] # 특정 커밋 되돌리기
git reset --soft [커밋해시] # 커밋만 되돌리기
git reset --hard [커밋해시] # 파일까지 완전히 되돌리기
git reset HEAD^ # 바로 이전 커밋으로 되돌리기

 

실제 개발 시 작업 흐름 예시

# 1. 새로운 기능 개발 시작
git checkout -b feature/login

# 2. 코드 수정 후 스테이징
git add .

# 3. 작업 내용 커밋
git commit -m "feat(auth): 로그인 기능 추가 - 구글 로그인 구현 - 보안 로직 추가"

# 4. 원격 저장소에 업로드
git push origin feature/login

# 5. 메인 브랜치에 병합
git checkout main git merge feature/login

 

위와같이 터미널을 사용하는 방법들은 잘 정리되어있지만

실제 많이 사용한다면 단축키를 모두 외울 수 있겠지만 

많이 사용하지 않는다면 단축키가 뭐였는지 찾아봐야하고... 작성해보면서 익혀야하고...

시간이 많이 걸리기 때문에 툴을 많이 사용합니다.

 

저는 그래서 이전에 조금 사용해보았던 "소스트리"를 사용해서

다음글에서 다시 한번 설명해보려 합니다.