IT Lab

Git에서 --는 옵션과 파일/경로를 구분하기 위해 사용됩니다. 특히 --는 Git 명령어에서 옵션(예: -b, -m)과 파일명을 명확히 구분하는 역할을 합니다.

예시 설명: git checkout -- file.txt

이 명령어는 file.txt 파일을 최신 커밋 상태로 복원하는 역할을 합니다. 즉, 워킹 디렉토리에서 파일을 수정했을 경우, 그 파일을 변경 전 상태(현재 브랜치의 마지막 커밋)로 되돌립니다.

의미:

1. -- 앞: Git 명령과 옵션이 올 수 있습니다.

• 여기서 checkout은 특정 브랜치로 이동하거나 파일을 복원하는 명령입니다.

2. -- 뒤: 파일이나 경로를 지정합니다.

• file.txt라는 특정 파일이 대상입니다.

왜 --가 필요할까?

• Git은 checkout 뒤에 오는 내용을 파일로 볼지 브랜치 이름으로 볼지 혼동할 수 있습니다.

• --를 사용하면, Git이 file.txt를 브랜치가 아닌 파일로 인식하도록 명확히 알려줍니다.

예제:

1. 파일 복원하기 (변경 사항 삭제):

git checkout -- file.txt

• file.txt의 워킹 디렉토리 수정 내용을 삭제하고, 마지막 커밋 상태로 되돌립니다.

2. 브랜치로 체크아웃 (다른 브랜치로 전환):

git checkout main

• main은 브랜치 이름으로 인식됩니다.

3. 혼동 방지:

git checkout my-branch

• Git은 my-branch가 브랜치인지 파일인지 모를 수 있습니다.

• --를 사용하여 명확히 구분할 수 있습니다:

git checkout -- my-branch

• 여기서 my-branch는 파일로 간주됩니다.

정리:

• --는 옵션과 파일/경로를 구분하는 역할을 합니다.

• 특히 브랜치 이름과 파일 이름이 겹치는 경우에 유용합니다.

• git checkout -- file.txt는 파일을 변경 전 상태로 복원합니다.

Git에서 커밋을 한 이후, 상황에 따라 다음 작업들을 진행할 수 있습니다. 아래는 일반적으로 커밋 후 수행하는 작업들입니다:

1. 변경 사항을 원격 저장소에 푸시 (Push)

로컬 커밋을 원격 저장소로 푸시하여 다른 팀원과 변경 사항을 공유합니다.

git push origin <branch-name>

예:

git push origin main

참고:

• 만약 새로운 브랜치를 생성한 후 처음 푸시하는 경우:

git push --set-upstream origin <branch-name>

2. 코드 리뷰 요청 (Pull Request / Merge Request)

팀에서 협업 중이라면 Pull Request (PR) 또는 **Merge Request (MR)**를 생성하여 코드 리뷰를 요청합니다.

• 변경 사항을 설명하고, 리뷰어가 필요한 경우 추가 정보를 제공하세요.

• GitHub, GitLab, Bitbucket 등의 플랫폼을 사용합니다.

3. 테스트 (Test)

커밋한 코드가 예상대로 작동하는지 테스트합니다.

• 로컬 테스트: 애플리케이션을 실행하거나, 유닛 테스트를 실행합니다.

npm test       # Node.js 프로젝트 예시

python -m unittest discover # Python 프로젝트 예시

• CI/CD 파이프라인 확인: 원격 저장소에 푸시한 후, CI/CD가 설정되어 있다면 테스트가 정상적으로 실행되는지 확인합니다.

4. 코드 병합 (Merge)

병합할 준비가 되었다면, 브랜치를 메인 브랜치에 병합합니다.

• 병합 전에 메인 브랜치 최신 상태로 리베이스하거나 병합하여 충돌을 해결하세요.

git checkout main

git pull origin main

git merge <branch-name>

리베이스 예시:

git checkout <branch-name>

git fetch origin main

git rebase origin/main

5. 릴리즈 작업 (Release)

커밋한 변경 사항이 완료되고 배포할 준비가 되었다면:

1. 버전 태그 생성: 새로운 버전 태그를 추가합니다.

git tag -a v1.0.0 -m "Release version 1.0.0"

git push origin v1.0.0

2. 배포: CI/CD 파이프라인이나 수동 배포 도구를 사용하여 애플리케이션을 배포합니다.

6. 추가적인 정리 작업

• Stash 저장소 확인: 필요 없는 변경 사항이 남아있는지 확인하세요.

git stash list

git stash drop

• 브랜치 삭제: 병합 완료 후, 더 이상 사용하지 않는 브랜치를 삭제합니다.

git branch -d <branch-name>

git push origin --delete <branch-name>

7. 팀원들과 소통

커밋과 관련된 작업이 완료되었다면:

• 팀원들에게 Slack, 이메일, Jira 등의 툴을 통해 변경 사항을 공유하세요.

• 중요한 변경 사항은 문서화(예: README, CHANGELOG)하는 것도 좋습니다.

이 과정을 따르면 커밋 후 작업이 체계적으로 진행될 수 있습니다. 

Git 커밋 메시지를 작성할 때는 일관성과 가독성을 유지하는 것이 중요합니다. 일반적으로 사용되는 Git 커밋 메시지 작성 규칙은 다음과 같습니다:

1. 메시지 구조

커밋 메시지는 세 부분으로 나눌 수 있습니다:

• 제목 (Title): 한 줄로 요약 (50자 이내 권장)

• 본문 (Body): 변경 사항에 대한 상세 설명 (선택 사항, 72자 줄바꿈 권장)

• 푸터 (Footer): 관련된 이슈 번호나 참고 정보 (선택 사항)

예시:

<타입>: <짧고 명확한 제목>

<본문: 변경 사항의 이유, 배경, 자세한 설명>

<필요시 푸터: 이슈 참조 또는 부가 정보>

2. 제목 작성 규칙

• 명령문 형태로 작성하세요. (예: “Add”, “Fix”, “Update” 등)

• 나쁜 예: “Added new feature”

• 좋은 예: “Add new feature”

• 첫 글자는 대문자로 시작하세요.

• 마침표는 생략하세요.

• 50자를 넘지 않도록 간결하게 작성하세요.

3. 타입 사용 (Type)

커밋 메시지에 타입을 명시하면 커밋 목적이 더 명확해집니다. 아래는 일반적으로 사용되는 타입들입니다:

• feat: 새로운 기능 추가

• fix: 버그 수정

• docs: 문서 수정

• style: 코드 스타일 변경 (기능에 영향 없는 변경)

• refactor: 코드 리팩토링 (기능 변경 없음)

• test: 테스트 추가 또는 수정

• chore: 빌드 프로세스나 설정 관련 작업

예:

feat: Add user authentication feature

fix: Correct typo in login error message

docs: Update README with setup instructions

4. 본문 작성 규칙 (선택 사항)

• 본문은 ‘무엇을’, ‘왜’ 변경했는지 설명합니다.

• 간결하지만 필요한 정보를 충분히 담으세요.

• 한 줄에 72자를 넘지 않도록 작성하세요.

예:

fix: Resolve crash on login button click

The app was crashing when the login button was clicked due to 

a null pointer exception. Added a null check to prevent this issue.

5. 푸터 작성 규칙 (선택 사항)

• 관련된 이슈 번호를 언급하세요.

• 이슈 참조 형식: Refs #123 또는 Fixes #123

• Fixes를 사용하면 해당 커밋으로 이슈가 자동으로 닫힙니다.

예:

fix: Handle API timeout error gracefully

Improved error handling for API timeouts by adding a retry 

mechanism. This prevents the app from freezing during long requests.

Fixes #456

6. 일관성 유지

• 팀에서 사용하는 규칙이 있다면 반드시 따르세요.

• 여러 사람이 협업할 때는 일관성 있는 메시지 스타일이 가독성을 높입니다.

Git은 분산 버전 관리 시스템으로, 소스 코드를 효과적으로 관리하고 협업할 수 있도록 도와줍니다. Git의 주요 명령어들을 이해하면 기본적인 작업과 협업을 쉽게 수행할 수 있습니다. 주요 커맨드는 다음과 같습니다:

1. 설정 관련

• git config --global user.name "Your Name"

사용자 이름 설정.

• git config --global user.email "your.email@example.com"

사용자 이메일 설정.

• git config --list

현재 설정 확인.

2. 저장소 초기화 및 클론

• git init

현재 디렉토리를 Git 저장소로 초기화.

• git clone <repository_url>

원격 저장소를 로컬로 복제.

3. 파일 상태 확인

• git status

파일의 상태 확인(수정됨, 추가됨, 삭제됨 등).

• git diff

수정된 내용 확인.

4. 파일 추가 및 커밋

• git add <file>

특정 파일을 스테이징 영역에 추가.

• git add .

현재 디렉토리의 모든 변경 사항을 스테이징 영역에 추가.

• git commit -m "Commit message"

스테이징 영역의 변경 사항을 커밋.

• git commit --amend

마지막 커밋 메시지를 수정.

5. 브랜치 관리

• git branch

현재 브랜치 목록 확인.

• git branch <branch_name>

새로운 브랜치 생성.

• git checkout <branch_name>

특정 브랜치로 전환.

• git checkout -b <branch_name>

브랜치를 생성하고 바로 전환.

• git branch -d <branch_name>

브랜치 삭제.

6. 병합 및 충돌 해결

• git merge <branch_name>

다른 브랜치를 현재 브랜치로 병합.

• 충돌 발생 시:

충돌 파일을 수정하고 git add 후 git commit.

7. 원격 저장소 작업

• git remote add origin <repository_url>

원격 저장소 추가.

• git push origin <branch_name>

로컬 브랜치를 원격 저장소에 푸시.

• git pull origin <branch_name>

원격 저장소에서 변경 사항을 가져와 병합.

• git fetch

원격 저장소의 최신 상태를 로컬로 가져옴(병합은 아님).

8. 로그 및 히스토리 확인

• git log

커밋 로그 확인.

• git log --oneline

간단한 형식으로 커밋 로그 확인.

• git show <commit_hash>

특정 커밋의 상세 정보 확인.

9. 파일 복구 및 되돌리기

• git checkout -- <file>

수정된 파일을 마지막 커밋 상태로 되돌림.

• git reset <file>

스테이징 영역에서 파일 제거.

• git reset --hard <commit_hash>

특정 커밋 상태로 되돌림.

10. 태그 관리

• git tag <tag_name>

태그 생성.

• git tag

태그 목록 확인.

• git push origin <tag_name>

태그 푸시.