Intellij IDEA와 Git을 연결해보자

전통에 따라 미래의 수석 소프트웨어 엔지니어 여러분을 환영합니다. 오늘 우리는 Git 에 관한 내 기사의 논리적 연속에 대해 이야기하겠습니다 . 또한 이전에 게시한 분기 전략 에 대한 자료를 읽어 보는 것이 좋습니다 . Git에 관한 기사에서 명령줄에서 작업하는 방법을 설명했으며 오늘은 Intellij IDEA에서 이 모든 작업을 수행하는 방법을 보여 드리겠습니다. 개발자로서의 여정을 시작할 때 저는 명령줄을 사용했고 이 문제에 대해 UI를 사용할 필요가 없다고 생각했습니다. 결국 모든 것이 명확하고 그렇습니다... 하지만 그것은 Intellij IDEA에서 Git을 사용하기 시작한 순간까지였습니다... 제 개인적인 경험을 설명하겠다고 즉시 말하고 싶습니다. Intellij IDEA를 사용하여 동일한 문제를 해결하는 데는 여러 가지 옵션이 있습니다. 제가 이 기사에서 설명한 내용을 더 잘 수행하는 방법을 알고 계시다면 댓글을 달아주시면 논의하겠습니다.

필요한 소개 참고사항:

1. git에 관한 기사를 읽고, 반복하고, 이해하세요 . 이렇게 하면 모든 것이 이미 설정되어 준비가 되었는지 확인하는 데 도움이 됩니다.
2. Intellij IDEA를 설치합니다.
3. 완전한 흡수를 위해 한 시간의 개인 시간을 확보하십시오.

작업을 위해 git에 관한 기사에서 사용한 데모 프로젝트를 살펴보겠습니다 .업데이트:게시 시점에 새로운 Github UI를 이미 사용할 수 있으며 일부 아이콘은 기사에 표시된 위치에 표시되지 않습니다. 놀라지 마십시오. 새 UI로 전환하지 않거나 새 UI를 찾아보면 됩니다.

프로젝트를 로컬로 복제

여기에는 두 가지 옵션이 있습니다.

1. 이미 Github 계정이 있고 나중에 무언가를 푸시하고 싶다면 프로젝트를 자신에게 포크하고 복사본을 복제하는 것이 좋습니다. 포크를 만드는 방법 - 이 기사의 장에서 포크 작업 흐름의 예를 설명했습니다 .
2. 내 저장소에서 복제하고 모든 것을 서버에 푸시할 수 있는 능력 없이 로컬에서 모든 작업을 수행합니다. 결국 이것은 내 저장소가 될 것입니다))

Github에서 프로젝트를 복제하려면 프로젝트에 대한 링크를 복사하여 IntelliJ IDEA에 전달해야 합니다.

1. 프로젝트 주소를 복사합니다.

2. Intellij IDEA를 열고 버전 관리에서 가져오기를 선택합니다.

3. 주소를 복사하여 프로젝트에 붙여넣습니다.

4. Intellij IDEA 프로젝트를 생성하라는 메시지가 표시됩니다. 우리는 제안을 받아들입니다:

5. 빌드 시스템이 없고 이것이 기사의 범위가 아니므로 기존 소스에서 프로젝트 생성을 선택합니다 .

6. 다음에는 다음과 같은 유화가 있을 것입니다. 복제를 정리했으니 이제 둘러볼 수 있습니다.

Intellij IDEA를 Git UI로 먼저 살펴보세요.

복제된 프로젝트를 다시 한 번 자세히 살펴보세요. 이미 거기에서 버전 제어 시스템에 대한 많은 정보를 얻을 수 있습니다. 첫 번째는 왼쪽 하단에 있는 버전 제어 패널입니다. 여기에서 모든 로컬 변경 사항을 찾고 커밋 목록을 얻을 수 있습니다(git log와 유사). Log 강의 로 넘어가겠습니다 . 개발 프로세스가 어떻게 진행되었는지 정확히 이해하는 데 도움이 되는 특정 시각적 구성 요소가 있습니다. 예를 들어, txt 에 헤더가 추가된 커밋을 사용하여 새 브랜치가 생성 된 후 마스터 브랜치에 병합된 것을 볼 수 있습니다 . 커밋을 클릭하면 오른쪽 모서리에서 커밋에 대한 모든 정보(모든 변경 사항 및 메타데이터)를 볼 수 있습니다. 또한 어떤 변경 사항이 적용되었는지 확인할 수 있습니다. 게다가 그곳에서 갈등이 해결되었습니다. IDEA도 이를 완벽하게 보여줍니다. 이 커밋 중에 변경된 파일을 두 번 클릭하면 충돌이 어떻게 해결되었는지 확인할 수 있습니다. 오른쪽과 왼쪽에는 하나로 병합해야 하는 동일한 파일의 두 가지 버전이 있는 것이 눈에 띕니다. 그리고 중간에는 최종 결과가 있습니다. 프로젝트에 프로젝트에 참여하는 브랜치, 커밋, 사용자가 많은 경우 브랜치(branch), 사용자(user), 날짜(date)별로 별도로 검색해야 합니다. 그리고 시작하기 전에 마지막으로 설명하고 싶은 것은 이해하는 방법입니다. 우리가 어느 지점에 있는지. 검색할 시간을 잠시 드리겠습니다... 찾으셨나요? 포기하고 있나요? :D 오른쪽 하단에는 Git: 마스터 버튼이 있는데 , Git: 뒤에는 프로젝트가 현재 어느 브랜치에 있는지 표시됩니다. 버튼을 클릭하면 다른 분기로 이동, 새 분기 생성, 기존 분기 이름 바꾸기 등 많은 유용한 작업을 수행할 수 있습니다.

저장소 작업

유용한 단축키

계속 작업하려면 몇 가지 매우 유용한 단축키를 기억해야 합니다.

0. ctrl + t - 원격 저장소에서 최신 변경 사항 가져오기(git pull)
1. ctrl + k - 현재 사용 가능한 모든 변경 사항을 커밋/확인합니다. 여기에는 추적되지 않은 파일과 수정된 파일이 모두 포함됩니다(git에 대한 내 기사 참조, 여기에 설명되어 있음)(git commit).
2. ctrl + Shift + k는 변경 사항을 원격 저장소에 푸시하는 명령입니다. 로컬에서 생성되었지만 아직 원격 커밋에 없는 모든 커밋은 푸시(git push)용으로 제공됩니다.
3. alt + ctrl + z - 특정 파일의 변경 사항을 로컬 저장소에서 마지막으로 생성된 커밋 상태로 롤백합니다. 왼쪽 상단에서 전체 프로젝트를 선택하면 모든 파일에 대한 변경 사항을 롤백할 수 있습니다.

우리는 무엇을 원합니까?

작업을 하려면 어디에서나 사용되는 기본 스크립트를 마스터해야 합니다. 작업은 별도의 브랜치에 새로운 기능을 구현하고 이를 원격 저장소에 푸시하는 것입니다(그런 다음 메인 브랜치에 대한 또 다른 풀 요청을 생성해야 하지만 이는 이 기사의 범위를 벗어납니다). 내가 무엇을해야 하나?

1. 현재 기본 분기(예: 마스터)에 있는 모든 변경 사항을 가져옵니다.

2. 이 주요 항목을 기반으로 작업용으로 별도의 항목을 만듭니다.

3. 새로운 기능을 구현합니다.

4. 메인 브랜치로 이동하여 작업하는 동안 새로운 변경 사항이 있는지 확인하세요. 그렇지 않다면 모든 것이 정상이고, 그렇다면 다음을 수행합니다. 작업 브랜치로 이동하여 메인 브랜치의 변경 사항을 우리의 브랜치로 리 베이스합니다. 모든 것이 잘 되었다면 좋습니다. 그러나 갈등이 있을 수도 있습니다. 그리고 원격 저장소에서 시간을 낭비하지 않고 미리 해결할 수 있습니다.

   왜 이러는 것 같나요? 이는 브랜치를 로컬 저장소로 푸시한 후 충돌이 발생하는 것을 방지하는 좋은 형식의 규칙입니다(물론 충돌이 여전히 존재할 가능성은 있지만 훨씬 적습니다).

5. 변경 사항을 원격 저장소에 푸시합니다.

다음에 일어날 일은 당신의 목표와 상상력에 달려 있습니다.

원격 서버에서 변경 사항을 받으시겠습니까?

새로운 커밋으로 README에 설명을 추가했고 이러한 변경 사항을 받고 싶습니다. 로컬 저장소와 원격 저장소 모두에서 변경 사항이 발생한 경우 병합과 리베이스 중에서 선택할 수 있습니다. 병합을 선택합니다. Ctrl + t를 입력하세요 . 결과적으로 README가 어떻게 변경되었는지 확인할 수 있습니다. 원격 저장소의 변경 사항이 표시되고 오른쪽 하단에서 서버에서 발생한 변경 사항에 대한 모든 세부 정보를 볼 수 있습니다.

마스터를 기반으로 새 브랜치를 생성합니다.

여기에서는 모든 것이 간단합니다.

1. 오른쪽 하단으로 이동하여 Git: master 를 클릭하고 + New Branch 를 선택합니다 .

Checkout 지점 확인란을 그대로 두고 새 지점의 이름을 적습니다. 나에게는 readme-improver 가 될 것입니다 .

그 후 Git: master는 Git: readme-improver 로 변경됩니다 .

병렬 작업 시뮬레이션

충돌이 나타나려면 누군가 충돌을 생성해야 합니다. :D 브라우저를 통해 새 커밋으로 README를 편집하여 병렬 작업을 시뮬레이션하겠습니다. 내가 작업하는 동안 누군가가 나와 동일한 파일을 변경하여 충돌이 발생할 것이라고 합니다. 10행에서 "완전히"라는 단어를 삭제하겠습니다.

기능 구현

작업은 README를 변경하고 새 기사에 설명을 추가하는 것입니다. 즉, git의 작업은 Intellij IDEA를 통해 수행됩니다. 다음을 추가하세요. 변경이 완료되었습니다. 이제 커밋을 생성할 수 있습니다. 단축키 ctrl + k 를 누르면 다음을 얻을 수 있습니다. 커밋을 생성하기 전에 이 창에 제공되는 내용을 주의 깊게 살펴봐야 합니다. 어디를 볼지 보여주기 위해 특별히 화살표를 추가했습니다. 거기에는 흥미로운 것들이 많이 있습니다. 커밋 메시지 섹션 에서 커밋 텍스트를 작성하고 커밋을 생성하려면 커밋 버튼을 클릭해야 합니다 . 아직 단축키로 이 작업을 수행하는 방법을 찾지 못했기 때문에 누군가 발견하면 글을 써주시면 매우 기쁠 것입니다. README가 변경되었다고 쓰고 커밋을 생성합니다. 결과적으로 왼쪽 하단에 커밋 이름과 함께 경고가 표시됩니다.

마스터 브랜치가 변경되었는지 확인하세요.

우리는 작업을 완료했고, 작동했고, 테스트를 작성했고, 모든 것이 괜찮습니다. 하지만 서버에 푸시하기 전에 이 기간 동안 메인 브랜치에 변경 사항이 있었는지 확인해야 합니다. 어떻게 이런 일이 일어날 수 있습니까? 그것은 매우 간단합니다. 누군가가 당신 이후에 작업을 맡았고, 이 누군가가 당신보다 더 빨리 해냈습니다. 따라서 마스터 브랜치로 이동합니다. 이렇게 하려면 아래 그림에 표시된 대로 오른쪽 하단에서 수행해야 합니다. 마스터 분기에서 ctrl + t를 눌러 원격 서버에서 최신 변경 사항을 가져옵니다. 어떤 변화가 있었는지를 보면 무슨 일이 일어났는지 쉽게 알 수 있습니다. 보시다시피 "완전히"라는 단어가 제거되었습니다. 아마도 그렇게 작성할 수 없다고 판단하고 개발자에게 업데이트 작업을 맡긴 것은 마케팅 담당자였을 것입니다. 이제 로컬에 최신 버전의 마스터 브랜치가 생겼습니다. readme-improver 로 돌아가 보겠습니다 . 이제 마스터 브랜치의 변경 사항을 우리 브랜치로 리베이스해야 합니다. 우리는 그렇습니다. 저와 함께 모든 것을 올바르게 따라오셨다면 결과적으로 README 파일에서 충돌이 발생하게 될 것입니다. 여기에는 이해하고 흡수해야 할 정보도 많이 있습니다. 충돌이 있는 파일의 목록(여기서는 한 요소의 경우)이 표시됩니다. 세 가지 옵션을 선택할 수 있습니다.

1. 귀하의 것을 수락하세요 - readme-improver의 변경 사항만 수락하세요.
2. 수락 - 마스터의 변경 사항만 수락합니다.
3. 병합 - 유지할 항목과 제거할 항목을 직접 선택하세요.

거기에서 무엇이 변경되었는지 명확하지 않으며 변경 사항이 마스터에 있는 경우 마스터에 필요하며 변경 사항을 그대로 적용할 수 없으므로 병합을 선택합니다 . 여기에 세 부분이 있음을 볼 수 있습니다.

1. 이는 readme-improver의 변경 사항입니다.
2. 결과. 현재는 변경 전과 동일합니다.
3. 마스터 브랜치의 변경 사항입니다.

모두가 만족할 수 있는 방식으로 결과를 수집해야 합니다. 그러므로 우리는 그들이 우리보다 먼저 무엇을 했는지 연구했고, 그들이 단순히 "완전히"라는 단어를 제거했다는 것을 깨달았습니다. 좋아요, 문제없어요. 이는 결과적으로 해당 항목을 제거하고 변경 사항을 추가한다는 의미입니다. 결과를 수정하자마자 Apply 를 클릭할 수 있습니다 . 그 후 리베이스가 성공했다는 알림이 표시됩니다. 이것이 Intellij IDEA를 통해 첫 번째 충돌을 해결한 방법입니다. :D

원격 서버에 변경 사항 푸시

다음 단계는 변경 사항을 원격 서버에 푸시하고 풀 요청을 생성하는 것입니다. 이렇게 하려면 ctrl + Shift + k를 누르면 됩니다. 왼쪽에는 원격 저장소에 푸시되지 않은 커밋 목록이 있고 오른쪽에는 푸시된 모든 파일이 있습니다. 변경되었습니다. 그게 전부입니다. Push를 클릭 하면 행복해집니다. :) Push가 성공하면 오른쪽 하단에 다음과 같은 알림이 표시됩니다.

보너스 부분

처음에는 끌어오기 요청 생성을 기사에 추가하고 싶지 않았지만 이로 인해 완전하지 않은 것으로 나타났습니다. 따라서 우리는 GitHub 저장소(물론 귀하의 저장소인 경우)))로 이동하여 GitHub가 우리에게 무엇을 제공할 것인지 이미 알고 있는지 확인합니다. Compare & pull request 를 클릭 한 다음 Create pull request 를 클릭합니다 . 충돌을 미리 해결했기 때문에 이제 끌어오기 요청을 생성할 때 즉시 병합할 수 있습니다. 이것이 제가 이번에 말씀드리고 싶은 전부입니다. 물론, 방금 문을 열고 작은 부분을 보여 드렸을 뿐입니다. 필요에 따라 나머지 부분을 직접 찾을 수 있습니다. 평소와 마찬가지로 직장에서 사용하는 다양한 기술을 기반으로 한 프로젝트를 게시하는 GitHub 계정을 구독해 주시기 바랍니다 . 나는 최근에 개인적인 성취를 이루었습니다. 내 프로젝트는 이미 100명 이상의 개발자로부터 평가를 받았습니다. 당신이 만든 것을 누군가가 사용한다는 것은 믿을 수 없을 만큼 큰 기쁨입니다. 그리고 그것을 좋은 일에 사용합니다.

유용한 링크

1. JavaRush: Git 시작하기: 초보자를 위한 자세한 가이드
2. GitHub: 작업할 데모 프로젝트
3. JavaRush: Git에서 분기 전략 분석
4. JetBrains: Git 저장소 설정
5. Habr: Git 리베이스
6. GitHub: 내 계정