소개 대신
안녕하세요, 미래의 수석 소프트웨어 엔지니어입니다.힘내 기초
Git은 우리 코드의 분산 버전 제어 시스템입니다. 왜 필요한가요? 분산된 팀에는 일종의 작업 관리 시스템이 필요합니다. 시간이 지남에 따라 발생하는 변경 사항을 추적하는 데 필요합니다. 즉, 단계별로 어떤 파일이 어떻게 변경되었는지 확인합니다. 이는 한 작업 내에서 수행된 작업을 분석할 때 특히 중요합니다. 이를 통해 돌아갈 수 있습니다. 상황을 상상해 봅시다. 작동하는 코드가 있었고 모든 것이 좋았지만 우리는 무언가를 개선하고 여기에서 조정하고 저기서 조정하기로 결정했습니다. 다 괜찮았는데 이번 개선으로 기능이 절반이 망가져 작업이 불가능해졌습니다. 그럼 다음은 무엇입니까? Gita가 없으면 몇 시간 동안 앉아서 모든 것이 원래 어땠는지 기억해야 할 것입니다. 그래서 우리는 커밋으로 롤백하기만 하면 됩니다. 아니면 두 명의 개발자가 동시에 코드를 변경하는 경우에는 어떻게 되나요? Git이 없으면 다음과 같습니다. 원본에서 코드를 복사하고 필요한 작업을 수행했습니다. 순간이 다가오고 두 사람 모두 변경 사항을 기본 폴더에 추가하려고 합니다. 그리고 이런 상황에서는 어떻게 해야 할까요?.. 감히 이 작업을 하는데 소요되는 시간을 짐작조차 할 수 없습니다. Git을 사용하면 전혀 그런 문제가 없습니다.힘내 설치
컴퓨터에 Git을 설치해 보겠습니다. 사람마다 OS가 다르다는 것을 알고 있으므로 몇 가지 경우에 대해 설명하겠습니다.Windows용 설치
평소와 마찬가지로 exe 파일을 다운로드하여 실행해야 합니다. 여기에서는 모든 것이 간단합니다. 첫 번째 Google 링크를 클릭 하고 설치하면 끝입니다. 작업을 위해 우리는 그들이 제공하는 bash 콘솔을 사용할 것입니다. Windows에서 작업하려면 Git Bash를 실행해야 합니다. 시작 메뉴의 모습은 다음과 같습니다.
그리고 이것은 이미 작업할 수 있는 콘솔입니다. Git을 열 때마다 프로젝트가 있는 폴더로 이동하지 않으려면 폴더를 마우스 오른쪽 버튼으로 클릭하여 필요한 경로로 콘솔을 열 수 있습니다. 
리눅스용 설치
일반적으로 git은 원래 Linux 커널 개발용으로 작성된 도구이기 때문에 Linux 배포판에 이미 설치되어 포함되어 있습니다. 하지만 그렇지 않은 상황도 있습니다. 이를 확인하려면 터미널을 열고 git --version을 입력해야 합니다. 명확한 대답이 있다면 아무것도 설치할 필요가 없습니다. 터미널을 열고 설치하세요. 저는 Ubuntu에서 작업하므로 이에 대해 무엇을 작성해야 할지 알려드릴 수 있습니다. sudo apt-get install git. 그게 전부입니다. 이제 모든 터미널에서 Git을 사용할 수 있습니다.macOS에 설치
여기에서도 먼저 Git이 이미 존재하는지 확인해야 합니다(Linux의 경우 위 참조). 그렇지 않은 경우 가장 쉬운 방법은 최신 버전을 다운로드하는 것 입니다 . XCode가 설치되면 Git이 자동으로 설치됩니다.힘내 설정
git에는 작업을 수행할 사용자 설정이 있습니다. 이는 커밋이 생성될 때 Git이 Author 필드에 대해 정확히 이 정보를 가져오기 때문에 합리적이고 필요한 것입니다. 모든 프로젝트에 대한 사용자 이름과 비밀번호를 설정하려면 다음 명령을 입력해야 합니다.
git config --global user.name ”Ivan Ivanov”
git config --global user.email ivan.ivanov@gmail.com
git config user.name ”Ivan Ivanov”
git config user.email ivan.ivanov@gmail.com약간의 이론..
주제를 계속 유지하려면 메시지에 몇 가지 새로운 단어와 행동을 추가하는 것이 좋습니다.... 그렇지 않으면 이야기할 내용이 없습니다. 물론 이것은 약간의 전문용어이고 영어의 카피이므로 영어로 의미를 추가하겠습니다. 어떤 말과 행동이 있나요?- Git 저장소;
- 커밋(커밋);
- 나뭇가지;
- 병합;
- 갈등;
- 당기다;
- 푸시;
- 일부 파일(.gitignore)을 무시하는 방법.
Git의 상태
기타에는 이해하고 기억해야 할 몇 가지 상태가 있습니다.- 추적되지 않음;
- 수정됨;
- 준비(단계);
- 헌신적인.
무슨 뜻이에요?
이는 우리 코드의 파일이 위치한 상태입니다. 즉, 그들의 생활 경로는 일반적으로 다음과 같습니다.- 생성되었지만 저장소에 추가되지 않은 파일은 추적되지 않는 상태가 됩니다.
- Git 저장소에 이미 추가된 파일을 변경합니다. 해당 파일은 수정된 상태입니다.
- 변경한 파일 중에서 필요한 파일만(또는 모두) 선택하고(예: 컴파일된 클래스는 필요하지 않음) 변경 사항이 있는 이러한 클래스는 Staged 상태가 됩니다.
- 커밋은 준비된 상태의 준비된 파일에서 생성되어 Git 저장소로 이동됩니다. 이후에는 Staged 상태가 비어 있습니다. 그러나 수정된 내용에는 여전히 뭔가가 포함될 수 있습니다.
커밋이란 무엇입니까?
커밋은 버전 제어의 주요 개체입니다. 여기에는 해당 커밋 이후의 모든 변경 사항이 포함됩니다. 커밋은 단일 연결 목록처럼 서로 연결됩니다. 즉, 첫 번째 커밋이 있습니다. 두 번째 커밋이 생성되면 두 번째 커밋은 첫 번째 커밋 다음에 온다는 것을 알게 됩니다. 그리고 이 방법으로 정보를 추적할 수 있습니다. 커밋에는 메타데이터라는 자체 정보도 있습니다.- 찾을 수 있는 고유한 커밋 식별자
- 커밋을 만든 커밋 작성자의 이름
- 커밋 생성 날짜;
- 이 커밋 중에 수행된 작업을 설명하는 주석입니다.
지점이란 무엇입니까?
브랜치는 커밋에 대한 포인터입니다. 커밋은 어떤 커밋이 앞에 왔는지 알기 때문에 브랜치가 커밋을 가리키면 모든 이전 커밋도 이를 참조합니다. 이를 바탕으로 동일한 커밋을 가리키는 브랜치가 여러 개 있을 수 있다고 말할 수 있습니다. 작업은 분기에서 발생하므로 새 커밋이 생성되면 분기는 해당 포인터를 최신 커밋으로 이동합니다.
Git 시작하기
로컬 저장소나 원격 저장소에서만 작업할 수 있습니다. 필요한 명령을 실행하려면 로컬 저장소만 사용할 수 있습니다. 모든 정보는 프로젝트의 로컬로만 .git 폴더에 저장됩니다. 원격에 관해 이야기하면 모든 정보가 원격 서버 어딘가에 저장됩니다. 프로젝트의 복사본만 로컬에 저장되고 변경 사항은 원격 저장소로 푸시(git push)될 수 있습니다. 여기서는 콘솔에서 git으로 작업하는 방법에 대해 논의하겠습니다. 물론 일부 그래픽 솔루션(예: Intellij IDEA)을 사용할 수 있지만 먼저 어떤 명령이 발생하고 그 의미가 무엇인지 파악해야 합니다.로컬 저장소에서 Git 작업하기
다음으로, 기사를 읽는 동안 제가 수행한 모든 단계를 따르시기 바랍니다. 이렇게 하면 자료에 대한 이해와 기억력이 향상됩니다. 맛있게 드세요 :) 로컬 저장소를 생성하려면 다음을 작성해야 합니다:
git init
그러면 콘솔이 있는 위치에 .git 폴더가 생성됩니다. .git은 Git 저장소에 대한 모든 정보를 저장하는 폴더입니다. 삭제할 필요가 없습니다. ;) 다음으로 이 프로젝트에 파일이 추가되고 상태가 Untracked가 됩니다. 현재 작업 상태를 확인하려면 다음을 작성하세요.
git status
우리는 마스터 브랜치에 있으며 다른 브랜치로 이동할 때까지 모든 것이 그대로 유지됩니다. 이렇게 하면 변경되었지만 아직 Staged 상태에 추가되지 않은 파일을 확인할 수 있습니다. Staged 상태에 추가하려면 git add를 작성해야 합니다. 여기에는 다음과 같은 몇 가지 옵션이 있을 수 있습니다.
- git add -A - 준비된 상태의 모든 파일을 추가합니다.
- 자식 추가 . — 이 폴더와 모든 내부 파일의 모든 파일을 추가합니다. 본질적으로 이전 것과 동일합니다.
- git add <filename> - 특정 파일만 추가합니다. 여기에서는 정규식을 사용하여 일부 패턴에 따라 추가할 수 있습니다. 예를 들어 git add *.java는 java 확장자를 가진 파일만 추가하면 된다는 의미입니다.
git add *.txt
git status
이를 통해 정규식이 올바르게 작동했으며 이제 test_resource.txt가 단계적 상태에 있음을 알 수 있습니다. 그리고 마지막으로 마지막 단계(로컬 저장소가 있고 원격 저장소가 하나 더 있습니다.)) - 커밋하고 새 커밋을 만듭니다.
git commit -m “all txt files were added to the project”
다음으로, 브랜치의 커밋 기록을 볼 수 있는 훌륭한 명령이 있습니다. 그것을 사용해 보자:
git log
여기에서 우리가 전송한 텍스트와 함께 첫 번째 커밋이 나타난 것을 이미 볼 수 있습니다. 우리가 전달하는 텍스트는 이 커밋 중에 수행된 작업을 최대한 정확하게 정의해야 한다는 점을 이해하는 것이 매우 중요합니다. 이것은 앞으로 여러 번 도움이 될 것입니다. 아직 잠들지 않은 호기심 많은 독자는 다음과 같이 말할 수 있습니다. GitTest.java 파일에 무슨 일이 일어났나요? 이제 우리는 이것을 알아낼 것입니다.
git status
보시다시피, 추적되지 않은 상태로 남아 있으며 날개에서 기다리고 있습니다. 아니면 프로젝트에 전혀 추가하고 싶지 않을 수도 있나요? 때로는 그런 일이 발생합니다. 다음으로, 더 흥미롭게 만들기 위해 텍스트 파일 test_resource.txt를 변경해 보겠습니다. 거기에 텍스트를 추가하고 상태를 확인해 보겠습니다.
git status
여기서는 추적되지 않은 상태와 수정된 상태라는 두 가지 상태의 차이를 명확하게 볼 수 있습니다. GitTest.java는 추적되지 않은 상태이고 test_resource.txt는 수정된 상태입니다. 이제 수정된 상태의 파일이 이미 있으므로 해당 파일에 대한 변경 사항을 확인할 수 있습니다. 이 작업은 다음 명령을 사용하여 수행할 수 있습니다.
git diff
즉, 여기서 텍스트 파일에 hello world!를 추가했음을 분명히 알 수 있습니다. 텍스트 파일에 변경 사항을 추가하고 커밋합니다.
git add test_resource.txt
git commit -m “added hello word! to test_resource.txt”
git log
보시다시피 이미 두 개의 커밋이 있습니다. 같은 방식으로 GitTest.java를 추가합니다. 이제 코멘트는 없고 다음 명령만 사용하면 됩니다.
git add GitTest.java
git commit -m “added GitTest.java”
git status
.gitignore 작업
저장소에 소스 코드만 저장하고 다른 것은 저장하지 않으려는 것이 분명합니다. 또 무엇이 있을까요? 최소한 개발 환경을 생성하는 컴파일된 클래스 및/또는 파일입니다. Git이 이를 무시하려면 특별한 파일을 만들어야 합니다. 우리는 이렇게 합니다. 프로젝트의 루트에 .gitignore라는 파일을 생성하고 이 파일의 각 줄은 무시할 패턴이 됩니다. 이 예에서 gitignore는 다음과 같습니다.
```
*.class
target/
*.iml
.idea/
```- 첫 번째 줄은 .class 확장자를 가진 모든 파일을 무시하는 것입니다.
- 두 번째 줄은 대상 폴더와 그 안에 포함된 모든 것을 무시하는 것입니다.
- 세 번째 줄은 .iml 확장자를 가진 모든 파일을 무시하는 것입니다.
- 네 번째 줄은 .idea 폴더를 무시하는 것입니다.
git status
분명히 우리는 실수로(git add -A를 사용하는 경우) 컴파일된 클래스를 프로젝트에 추가하는 것을 원하지 않습니다. 이렇게 하려면 .gitignore 파일을 만들고 앞에서 설명한 모든 내용을 추가하세요. 
이제 새 커밋으로 프로젝트에 gitignore를 추가해 보겠습니다.
git add .gitignore
git commit -m “added .gitignore file”
git status
모든 것이 명확합니다) Git 무시 +1)
지점 등을 이용한 작업
물론 한 지점에서 일하는 것은 한 사람에게 불편하고 팀에 두 명 이상의 사람이 있으면 불가능합니다. 이를 위한 지점이 있습니다. 앞서 말했듯이 브랜치는 커밋에 대한 이동 포인터일 뿐입니다. 이 부분에서는 다양한 브랜치에서 작업하는 방법, 즉 한 브랜치에서 다른 브랜치로 변경 사항을 병합하는 방법, 발생할 수 있는 충돌 등을 살펴보겠습니다. 저장소의 모든 브랜치 목록을 보고 어느 브랜치에 있는지 이해하려면 다음을 작성해야 합니다.
git branch -a
마스터 브랜치가 하나만 있고 그 앞에 있는 별표는 우리가 마스터 브랜치에 있다는 것을 의미합니다. 그런데 우리가 어느 브랜치에 있는지 알아보려면 상태 확인(git status)을 사용할 수도 있습니다. 다음으로 브랜치를 생성하는 데는 몇 가지 옵션이 있습니다(더 있을 수도 있습니다. 저는 다음을 사용합니다).
- 현재 있는 분기를 기반으로 새 분기를 만듭니다(99% 사례).
- 특정 커밋(1%)을 기반으로 브랜치를 생성합니다.
특정 커밋을 기반으로 브랜치 생성
우리는 고유한 커밋 식별자에 의존할 것입니다. 그것을 찾으려면 다음과 같이 작성합니다.
git log
나는 "add hello world..."라는 코멘트로 커밋을 강조했습니다. 고유 식별자는 "6c44e53d06228f888f2f454d3cb8c1c976dd73f8"입니다. 이 커밋에서 시작하는 개발 브랜치를 만들고 싶습니다. 이를 위해 나는 다음과 같이 쓸 것이다:
git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8
git status
git log
그리고 그것은 사실입니다. 우리에게는 두 개의 커밋이 있다는 것이 밝혀졌습니다. 그런데 흥미로운 점은 이 브랜치에는 아직 .gitignore 파일이 없기 때문에 컴파일된 파일(GitTest.class)이 이제 추적되지 않은 상태로 강조 표시된다는 것입니다. 이제 다음과 같이 작성하여 브랜치를 다시 수정할 수 있습니다.
git branch -a
마스터와 개발이라는 두 가지 분기가 있음을 알 수 있으며 이제 우리는 개발 중입니다.
현재 분기를 기반으로 분기 만들기
브랜치를 생성하는 두 번째 방법은 다른 브랜치를 기반으로 구축하는 것입니다. 마스터 브랜치를 기반으로 브랜치를 생성하고 싶어서 먼저 마스터 브랜치로 전환하고 다음 단계는 새로운 브랜치를 생성하는 것입니다. 한번 보자:- git checkout master - 마스터 브랜치로 이동합니다.
- git status - 마스터에 있는지 확인합니다.
여기서는 마스터 브랜치로 이동했고, gitignore가 이미 여기에서 작동하고 있으며, 컴파일된 클래스가 더 이상 추적되지 않는 것으로 표시되지 않는다는 것을 알 수 있습니다. 이제 마스터 브랜치를 기반으로 새 브랜치를 생성합니다.
git checkout -b feature/update-txt-files
이 브랜치가 마스터와 같지 않을지 의심스러우면 git log를 작성하고 모든 커밋을 살펴보면 쉽게 확인할 수 있습니다. 4개가 있어야 합니다.
갈등 해결
충돌이 무엇인지 이해하기 전에 한 가지를 다른 가지로 병합(병합)하는 것에 대해 이야기해야 합니다. 이 그림은 한 가지가 다른 가지로 병합될 때의 과정을 보여줍니다.
즉, 주 가지가 있습니다. 어느 시점에서 변경 사항이 발생하는 보조 항목이 생성됩니다. 작업이 완료되면 한 분기를 다른 분기로 병합해야 합니다. 다양한 기능에 대해서는 설명하지 않겠습니다. 이 기사의 틀 안에서만 이해를 전달하고 싶고 필요한 경우 세부 사항을 직접 알아볼 수 있습니다. 따라서 이 예에서는 feature/update-txt-files 분기를 만들었습니다. 지점명으로 적혀있는대로 본문 업데이트 하겠습니다. 
이제 이 문제에 대한 새 커밋을 만들어야 합니다.
git add *.txt
git commit -m “updated txt files”
git log
이제 feature/update-txt-files 분기를 master로 병합하려면 master로 이동하여 git merge feature/update-txt-files를 작성해야 합니다.
git checkout master
git merge feature/update-txt-files
git log
결과적으로 이제 마스터 브랜치에도 feature/update-txt-files에 추가된 커밋이 있습니다. 이 기능은 기능 분기를 삭제할 수 있도록 추가되었습니다. 이를 위해 다음과 같이 작성합니다.
git branch -D feature/update-txt-files
git checkout -b feature/add-header
... делаем изменения в файле
git add *.txt
git commit -m “added header to txt”
마스터 브랜치로 이동하여 기능 브랜치와 같은 줄에 있는 이 텍스트 파일도 업데이트하세요.
git checkout master
… обновor test_resource.txt
git add test_resource.txt
git commit -m “added master header to txt”
git merge feature/add-header
여기서 Git은 이 코드를 병합하는 방법을 독립적으로 결정할 수 없으며 먼저 충돌을 해결한 다음 커밋해야 한다고 말합니다. 좋아, 텍스트 편집기에서 충돌이 포함된 파일을 열고 살펴보겠습니다. 
여기서 git이 수행한 작업을 이해하려면 어디에 무엇을 썼는지 기억하고 비교해야 합니다.
- "<<<<<<< HEAD"와 "=======" 사이는 마스터 브랜치의 이 줄에 있었던 마스터 변경 사항입니다.
- "======="과 ">>>>>>> feature/add-header" 사이에는 feature/add-header 분기에 변경 사항이 있습니다.
변경 사항 상태를 살펴보겠습니다. 설명이 약간 다를 것입니다. 수정된 상태는 없지만 병합되지 않은 상태는 없습니다. 그러면 다섯 번째 상태를 안전하게 추가할 수 있습니다... 하지만 제 생각에는 이것이 불필요하다고 생각합니다.
git status
우리는 이것이 다른 특이한 사례라고 확신했습니다. 계속하자:
git add *.txt
설명에서 git commit 작성만 제안한다는 것을 알 수 있습니다. 우리는 듣고 씁니다:
git commit
그게 전부입니다. 이것이 우리가 한 방법입니다. 콘솔에서 충돌을 해결했습니다. 물론 개발 환경에서는 이 작업을 좀 더 쉽게 수행할 수 있습니다. 예를 들어 Intellij IDEA에서는 모든 것이 잘 설정되어 있어 필요한 모든 작업을 수행할 수 있습니다. 그러나 개발 환경은 내부적으로 많은 일을 수행하므로 우리는 그곳에서 정확히 무슨 일이 일어났는지 이해하지 못하는 경우가 많습니다. 그리고 이해가 없으면 문제가 발생할 수 있습니다.
원격 저장소 작업
마지막 단계는 원격 저장소로 작업하는 데 필요한 몇 가지 추가 명령을 이해하는 것입니다. 이미 말했듯이 원격 저장소는 저장소가 저장되고 이를 복제할 수 있는 장소입니다. 어떤 유형의 원격 저장소가 있습니까? 수많은 예가 있습니다:-
GitHub 는 리포지토리 및 공동 개발을 위한 가장 큰 리포지토리입니다. 이미 이전 기사에서 설명했습니다. 내 Github 계정을
구독하세요 . 나는 일하면서 공부했던 분야에 내 작품을 자주 전시한다. -
GitLab은 자체 위키, 문제 추적 시스템 , CI/CD 파이프라인 및 기타 기능을 갖춘 Git 용 코드 저장소 관리 시스템을 제공하는 오픈 소스 웹 기반 DevOps 라이프사이클 도구 입니다 . Microsoft가 GitHub를 인수했다는 소식이 나온 후 일부 개발자는 GitLab에서 작업을 복제했습니다.
-
BitBucket은 Mercurial 및 Git 버전 제어 시스템을 기반으로 프로젝트 호스팅 및 공동 개발을 위한 웹 서비스입니다. 한때 GitHub에 비해 무료 개인 저장소가 있다는 점에서 큰 이점이 있었습니다. 작년에 GitHub는 이 기능을 모든 사람에게 무료로 제공했습니다.
-
등등…
git clone https://github.com/romankh3/git-demo
git pull
우리의 경우 현재 원격으로 변경된 사항이 없으므로 대답은 다음과 같습니다. 이미 최신 상태입니다. 하지만 원격 저장소에서 일부 변경 사항을 적용하면 이를 가져온 후 로컬 저장소가 업데이트됩니다. 마지막으로 마지막 명령은 데이터를 원격 저장소로 푸시하는 것입니다. 로컬에서 수행한 작업을 원격 저장소로 전송하려면 먼저 로컬에서 새 커밋을 만들어야 합니다. 이를 위해 텍스트 파일에 다른 것을 추가해 보겠습니다. 
이제 이것은 우리에게 일반적인 일입니다. 우리는 이 문제에 대한 커밋을 만듭니다.
git add test_resource.txt
git commit -m “prepated txt for pushing”
git push
그것이 내가 당신에게 말하고 싶은 전부입니다. 관심을 가져주셔서 감사합니다. 내 GitHub 계정을 구독하면 직장에서 공부하고 사용하는 것과 다른 멋진 예제 프로젝트를 게시할 수 있습니다.
유용한 링크
- Git의 공식 문서는 러시아어로 되어 있습니다 . 참고자료로 추천드립니다.
- 힘내
GO TO FULL VERSION