Git 모범 사례 – (g)it을 최대한 활용하는 방법

Pull, Fetch, Commit, Push, Merge, Rebase – 이러한 용어가 아직 일상 생활에 적용되었습니까? Linus Torvalds는 Git의 첫 번째 버전을 만들 때 이를 "바보 같은 콘텐츠 추적기"라고 설명했습니다. 이 무료 오픈 소스 소프트웨어는 오늘날 가장 인기 있는 버전 관리 시스템입니다.

힘내 란 무엇입니까?

가끔은 시간을 되돌려 더 나은 결정을 내리거나 다른 일을 할 수 있기를 바라지 않습니까? 기술과 코딩의 세계에서는 가능합니다. Git은 변경/추가할 때마다 소중한 코드의 버전을 저장하는 오픈 소스 분산 버전 제어 시스템입니다. 따라서 롤백해야 할 때마다 작업 버전을 선택하고 짜잔! 또한 Git을 사용하면 개발자가 개별 로컬 복사본을 동시에 작업할 수 있으므로 팀 내에서 중단 없이 작업할 수 있습니다. 모든 팀 구성원의 모든 변경 사항이 추적되므로 조직화된 흐름에서 투명성이 유지됩니다. 그렇다면 GitHub는 무엇입니까? GitHub는 버전 제어 시스템을 최적화할 수 있는 다양한 기능을 제공하는 Git용 리포지토리 호스팅 서비스입니다.
힘내 워크플로

조직마다 Git 워크플로가 다릅니다. 가장 성공적인 Git 워크플로는 팀에 생산성을 위한 충분한 공간을 제공하는 동시에 출력의 효율성을 극대화하는 워크플로입니다. 팀 규모에 맞게 확장할 수 있어야 하며 발생할 수 있는 충돌 수를 최소화해야 합니다. 중앙 집중식 Git 워크플로는 기능 분기 워크플로, 분기 워크플로, Gitflow 워크플로 등과 같은 다른 Git 워크플로가 구축되는 기반입니다. 워크플로는 조직의 문화를 향상하고 보완하도록 계획해야 합니다. 각 팀에 자체 Git 워크플로.

Git을 사용하는 이유

1. 분산 아키텍처

개발자가 단일 중앙 저장소에 액세스하여 개별 파일에 대한 변경 사항을 "체크아웃"하고 커밋할 수 있도록 하는 중앙 집중식 버전 제어 시스템과 달리 Git은 분산 접근 방식을 따릅니다. 분산 아키텍처에서 모든 개발자는 전체 중앙 리포지토리의 고유한 로컬 복사본을 가지고 있으므로 오프라인으로 작업하고 전체 개정 기록에 액세스하고 쉽게 분기 및 병합할 수 있습니다.

2. 강력한 성능

분기, 병합, 커밋 등은 T에 대한 액세스 패턴을 이해하는 지능형 심층 지식 알고리즘으로 인해 Git 워크플로를 사용하여 정말 쉽고 빠릅니다.

3. 안전하다

Git은 해시태그 알고리즘으로 SHA1을 암호화 방식으로 사용하여 버전과 디렉토리 간의 관계를 포함한 모든 파일 콘텐츠를 저장합니다. 우발적이거나 악의적인 코드 변경은 완전히 추적할 수 있습니다.

4. 오픈 소스

오픈 소스이기 때문에 Git은 무료이며 우수한 커뮤니티 지원을 받고 품질에 대해 지속적으로 조사되며 학습자를 위한 많은 문서 및 자습서로 백업됩니다.

5. 더 빠른 릴리스

Git의 분산 개발 및 손쉬운 분기 및 새로운 기능 생성은 개발자가 애자일 워크플로에서 더 자주 변경하도록 권장합니다.

Git 모범 사례

• 새 프로젝트? 새 저장소

작업을 시작하려는 모든 새 프로젝트에 대해 새 리포지토리를 만드는 것은 좋은 조직적 의미가 있습니다. 완료되면 GitHub에 푸시합니다.

• 새로운 특성? 가지를 내다

이제 새 프로젝트를 만들었습니다. 새로운 Git 기능을 만드는 것은 어떻습니까? Git 분기를 사용하면 리포지토리 내에서 조직화된 워크플로를 만들고 관리할 수 있습니다. 팀 구성원은 다양한 Git 브랜치를 할당하여 동시에 작업하지만 격리된 방식으로 작업할 수 있습니다. 다른 사람들이 당신이 정확히 무엇을 하고 있는지 알 수 있도록 항상 git 브랜치에 의미를 부여하세요.

• 최신 정보를 유지하여 하루를 시작하세요.

생성/지정한 기능에 대한 작업을 시작하기 전에 항상 "리베이스"하거나 프로젝트(마스터)의 최신 버전을 얻으십시오. 오래된 파일을 변경하고 싶지 않습니다.

• 주기적으로 체크포인트를 가지고

큰 변화를 위해 커밋을 저장하지 마십시오. 당신과 당신의 팀 구성원이 코드를 더 쉽게 이해할 수 있도록 작은 변경 사항을 자주 "커밋"하십시오. 변경 사항이 작고 빈번할 때 되돌리기 및 추적도 더 쉽습니다.

• 작업 보관

종종 한 Git 브랜치에서 작업하고 있지만 갑자기 다른 브랜치에서 작업이 필요하지만 반쯤 완료된 변경 사항을 "커밋"하고 싶지는 않다는 것을 기억할 수 있습니다. 또는 단순히 깨끗한 작업 복사본을 원할 수도 있습니다. "git stash"를 구출합니다. Stash를 사용하면 미완성 변경 사항을 스택에 저장하여 언제든지 다시 가져올 수 있습니다!

• 커밋을 스쿼시

기록에 커밋이 적으면 어디에서 잘못되었는지 모니터링하고 추적하기가 더 쉽습니다. 깨끗한 커밋 기록을 유지하고 싶다면 이것이 당신을 위한 것입니다. pull 요청이 병합될 때 모든 커밋을 스쿼시하고 하나로 병합합니다.

• 커밋 메시지

커밋 메시지에 항상 명확하고 이해할 수 있는 정보를 제공하세요. 변경 사항에 대한 간략한 요약을 작성하는 것으로 시작하고 빈 줄을 남겨두고 변경 사항에 대한 자세한 설명을 작성하십시오. 커밋 기록이 다음과 같이 끝나는 것을 원하지 않습니다./

• 역사를 바꾸지 마라

변경 사항을 저장소에 커밋한 후에는 뒤로 돌아가 기록을 변경하지 마십시오. Git을 사용하면 그렇게 하고 공개 기록을 다시 작성할 수 있지만 그렇게 하는 것은 결코 좋은 습관이 아닙니다. 당신과 당신의 팀 모두를 위해.

• Git 패치 적용

리포지토리에 대한 쓰기 권한이 없지만 여전히 버그를 수정하고 싶을 때 Git 패치를 적용하세요. 항상 마스터 리포지토리를 복제한 다음 새 기능에 대한 분기를 생성해야 합니다. .patch 파일이 준비되면 항상 미리 보고 테스트를 실행하여 오류를 확인하십시오. Git은 완료되면 패치를 적용합니다(git apply -R path/file.patch). 테스트하고 확인하는 것을 잊지 마십시오

• 풀 리퀘스트를 너무 오래 방치하지 마세요

열린 "풀" 요청은 조만간 충돌을 일으킬 수 있습니다. 2일 이상 방치하지 마세요. 항상 코드를 검토하고 배포에 문제가 없으면 pull 요청을 병합합니다. 이렇게 하면 배송 프로세스가 단축될 뿐만 아니라 코드 충돌도 방지됩니다.

• 프로젝트 관리 도구로 더 나은 구성

Redmine과 같은 프로젝트 관리 도구를 사용해 왔다면 Git과 함께 사용하여 여러 팀 구성원과 작업을 더 잘 관리하는 것이 좋습니다. Redmine 작업을 이름으로 사용하여 Git 브랜치를 생성하는 것은 더 나은 투명성과 구성을 허용하므로 최고의 Git 모범 사례 중 하나입니다.

• GitLab CI/CD

이와 같은 지속적 통합/지속적 배포 도구를 사용하면 버그와 오류를 테스트하고 확인할 수 있으며 코드 표준과의 호환성을 보장할 수 있습니다. 이러한 작업은 코드가 스테이징 서버로 푸시된 후에 수행됩니다.