버전 관리 및 Git 소개

Google 문서도구에 익숙하십니까? 그렇다면 작성자와 관련된 사람들이 문서의 모든 변경 사항을 확인하고 추적할 수 있는 작은 '버전 기록' 탭을 알고 있다고 가정하는 것이 안전합니다. 주어진 시간에. 편리한 도구죠?

이제 단락으로 가득 찬 시트 대신 수백 줄의 코드로 가득 찬 파일이 있다고 상상해보십시오. 단일 문서와 달리 지속적으로 업데이트되는 다양한 파일이 있습니다.

수천 줄의 코드가 실행되고 최종 결과, 즉 모바일 앱이 비즈니스의 미래에 달려 있는 이와 같은 시나리오에서는 모든 변경 사항을 추적할 수 있는 소프트웨어를 보유하는 것이 훨씬 더 중요해집니다. 코드 파일에서 만들어집니다.

여기에서 버전 관리 소프트웨어가 등장합니다.

소프트웨어 개발에서 버전 관리가 중요한 이유

이름에서 알 수 있듯이 버전 제어 소프트웨어를 사용하면 모바일 앱 개발자가 소프트웨어 개발 주기의 여러 버전을 추적하고 변경할 수 있습니다. 코드에서 발생하는 모든 변경 사항을 추적한 다음 변경 사항을 취소할 수 있는 옵션은 버전 제어 를 여러 개발자가 참여하는 모바일 앱 개발 회사 프로세스 의 중요한 부분으로 만드는 것입니다.

이제 버전 제어와 관련하여 현재 시장에서 사용할 수 있는 소프트웨어가 많이 있습니다. 그 중 일부를 살펴보겠습니다.

버전 관리에 사용 가능한 소프트웨어

GitLab 설문조사에서 분산 소프트웨어의 리더는 사용자의 98%가 Git 오픈 소스 도구를 사용하고 개발자의 92% 이상이 앱 개발 프로세스에서 버전 제어 언어로 Git을 사용한다는 사실을 발견했지만 몇 가지가 있습니다. 개발자가 Git 대안을 볼 수 있는 이유. 이러한 이유 중 일부는 GitHub 가격 책정 구조와 Github이 iOS와 Android 모두에서 시작되었다는 사실, Octocat에 대한 혐오감, 또는 Git이 아닌 버전 제어 언어의 단순한 편안함 수준에서 다를 수 있습니다.

이유가 무엇이든 버전 제어를 위한 Git의 대안은 다음과 같습니다.

이제 Version Control과 Appinventiv에 사용할 수 있는 대안이 여러 개 있는 경우에도 다양한 고객 요구 사항으로 인해 실제로 많은 대안을 직접 작업한 경험이 있습니다. 이유를 알려드리겠습니다.

Appinventiv가 버전 관리에 Git을 사용하는 이유

1. 번개 같은 속도

시장에 나와 있는 모든 버전 관리 소프트웨어 중에서 Git 로그 및 커밋 요소가 작동하는 속도는 타의 추종을 불허합니다. 그리고 개발자 팀이 플랫폼에서 작업할 때 소프트웨어가 빨라야 하는 것이 절대적으로 필요합니다.

2. 오프라인 작업 기능

인터넷에 의존하는 소프트웨어에서 작업할 때 이동 중에 중앙 저장소와의 연결이 끊어지면 위험할 수 있습니다. 하지만 Git은 그렇지 않습니다. Git을 사용하면 커밋, 프로젝트 기록 탐색, 분기 생성 또는 병합과 같은 거의 모든 작업을 로컬 컴퓨터에서 수행할 수 있습니다.

3. 실행 취소 완화를 위해

Git에는 전체 커밋을 수정하고 되돌릴 수 있는 '실행 취소' 명령이 함께 제공됩니다. 실제로 Reflog 옵션을 통해 '삭제된' 커밋을 복원하는 옵션도 제공합니다.

4. 백업용

팀이 Git에서 작업할 때 팀이 컴퓨터에 있는 모든 단일 클론에는 사용 가능한 백업이 함께 제공됩니다. 또한 거의 모든 단일 Git 작업은 데이터를 추가만 하고 삭제하지는 않습니다.

5. 유용한 커밋 만들기

우리 개발자 팀이 A에서 일부 기능을 가져오고 다른 기능에서 일부 버그를 수정하는 등 관련 없는 일련의 변경을 커밋할 때 다른 팀 구성원이 무슨 일이 일어났는지 이해하기가 매우 어려울 수 있으며 롤백하기 어려울 수 있습니다. 문제를 일으키는 경우 A의 기능입니다.

Git은 세분화된 커밋을 생성하여 이 혼란을 해결합니다. 'staging area' 개념을 통해 한 줄만 살펴보더라도 다음 커밋에 어떤 변경 사항이 포함될지 쉽게 알 수 있습니다.

이것이 Appinventiv에서 Git을 사용하는 다섯 가지 주요 이유입니다. 이유를 살펴보았으니 이제 방법을 살펴볼 차례입니다. 버전 관리 프로세스에 Git을 통합하는 방법.

이제 시작하겠습니다.

Git 사용 시 버전 관리 프로세스

리포지토리 생성

Git의 목표는 프로젝트라고 하는 파일 세트를 관리하는 것입니다. 이를 위해 Git은 모든 정보를 Repository라고 하는 데이터 구조에 저장합니다. 리포지토리는 앱의 소스 코드, 리소스 및 데이터 세트로 구성됩니다. 기본적으로 앱 프로젝트를 정의하는 모든 것이 있습니다.

이제 Git에서 저장소를 가져오는 두 가지 방법이 있습니다. 로컬 디렉토리를 사용하고 명령줄을 사용하여 이를 Git 리포지토리로 변환하거나 이미 업로드된 Git 리포지토리를 복사할 수 있습니다.

리포지토리를 만들 때 일반적으로 공개 및 비공개의 두 가지 옵션이 제공됩니다. 공개 저장소는 Git을 사용하여 다른 개발자가 볼 수 있는 저장소이고 Private 저장소는 소수의 사람들만 볼 수 있는 저장소입니다.

분기

저장소 생성 옆에는 분기가 있습니다. Appinventiv와 같은 회사에서는 특정 시점에 15~20명 이상의 개발자가 하나의 프로젝트에서 작업하고 있으므로 개발자가 동일한 소스 코드를 공유하고 작업하는 경우가 많습니다. 어떤 개발자는 문제를 해결하느라 바쁘고 다른 개발자는 일부 기능을 구현하고 있을 수 있습니다.

이와 같은 상황에서는 동일한 코드베이스에서 다른 코드 버전을 쉽게 처리할 수 있는 시스템이 필요합니다.

여기에서 Gitflow가 등장합니다. Gitflow 는 체계적이고 효율적으로 분기하는 데 사용되는 프레임워크입니다.

Gitflow에서 분기 프로세스가 작동하는 방식을 설명하기 전에 예제를 통해 개념을 설명하겠습니다.

팀에 5명의 개발자가 있고 그들이 Instagram 앱과 같은 개발 작업을 하고 있다고 가정합니다. 이제 피드 및 알림과 같은 개별 앱 기능이 모듈 1, 모듈 2 등으로 표시된다고 가정합니다. 이제 이러한 다른 모듈은 개발 분기이며 작업 후에 상위 분기 또는 마스터와 병합됩니다.

개발자가 브랜치를 추가하는 순간 그들은 팀 구성원의 작업과 작업을 분리하는 독립적인 개발 라인을 만듭니다. 그런 다음 다른 분기가 상위 분기로 병합됩니다.

분기는 팀 구성원이 예상해야 하는 모든 변경 사항을 식별할 수 있게 하고 역추적을 쉽게 만드는 방법입니다.

우리 프로젝트에서 일반적으로 다음 분기를 유지합니다.

• 마스터 브랜치
• 개발지사
• 기능 분기
• 릴리스 분기
• 핫픽스 및 버그 수정

저 지르다

개발자가 개별 파일에서 변경한 사항을 커밋이라고 합니다. 변경 사항이나 커밋은 서버가 아닌 로컬 저장소에 추가됩니다. 다음으로, 우리 개발자들은 커밋 메시지를 작성하는 습관을 따릅니다. 여기에 커밋에 대한 설명(파일의 변경 사항)이 게시되어 다른 개발자도 파일의 변경 사항에 대한 세부 정보를 알 수 있습니다.

푸시

로컬 Git 리포지토리에서 커밋하면 다음으로 변경 사항이 푸시( Push )라고 하는 서버로 전송됩니다 .

파일 작업을 하는 유일한 사람이 커밋 히스토리를 서버에 푸시하는 것은 상당히 쉽지만 다른 개발자도 프로세스에 참여하는 경우 변경 사항을 가져와야 파일 세트를 푸시할 수 있습니다. Git에 커밋합니다.

다음으로 Pull Change 단계에서 수행되는 작업을 살펴보겠습니다.

풀 리퀘스트

두 명 이상의 개발자가 동일한 파일에서 작업하는 경우 어떤 커밋을 푸시하기 전에 다른 개발자가 서버에 일부 커밋을 푸시할 수 있습니다. 그리고 그런 일이 발생하면 충돌이 발생합니다(나중에 자세히 설명).

서버에 동일한 코드베이스를 두 번 업로드하는 것을 방지하기 위해 개발자는 먼저 리포지토리에서 변경 사항을 가져와서 코드가 다른지 확인합니다. 이제 일반적으로 두 명 이상의 개발자가 동일한 파일에서 작업하고 커밋을 서버에 푸시하면 '병합' 옵션이 제공됩니다.

다음으로 Merge에 대해 알아보겠습니다.

병합

병합은 개발자가 먼저 모든 분기를 서로 결합한 다음 마스터 또는 상위 분기와 결합하는 단계입니다.

딜리버리가 푸시 명령을 입력할 때마다 병합 옵션이 표시되고 커밋을 병합할 분기를 묻습니다.

이제 Merge 단계에서 Conflict의 발생이 매우 일반적입니다. 충돌은 일반적으로 병합하려는 두 분기가 동일한 파일의 동일한 부분에서 변경될 때 발생합니다. 여기서 일어나는 일은 Git이 어떤 버전을 사용해야 하는지 알아낼 수 없다는 것입니다.

이 충돌 문제가 발생하면 Git은 자동 및 수동의 두 가지 해결 방법을 제공합니다.

이름에서 알 수 있듯이 하나는 Git이 문제 자체를 찾는 곳이고 후자는 개발자가 수동으로 수행해야 하는 곳입니다. Appinventiv에서는 사소한 버그 발생 가능성도 제거하기 위해 수동으로 충돌을 해결하는 데 중점을 둡니다.

Git을 사용하여 앱 개발 프로세스의 버전 제어를 수행하는 동안 동시에 발생하는 것은 문제 추적입니다.

우리는 Agile의 열렬한 추종자이며 모바일 앱 개발 프로세스 에 대해 Agile을 신뢰하기 때문에 동시에 여러 개발 프로세스를 처리하는 것의 중요성을 이해합니다. 그리고 문제 추적 기능을 사용하면 테스터가 Git 서버에서 작성되고 푸시된 코드를 실시간으로 감시하는 것이 훨씬 쉬워집니다.

ZenHub 보드를 사용하여 각 저장소의 워크플로를 모니터링합니다. 게시판을 통해 제안된 변경 사항의 우선 순위를 추적하고 개발자가 게시판에 대한 의견을 실시간으로 업데이트할 수 있습니다.