Git 자습서 : Git 버전 제어 시작

이 기사에서는 소프트웨어 프로젝트가 저장 될 Git 서버에 액세스하는 데 필요한 소프트웨어를 설치하는 방법을 포함하여 Git을 소개합니다.

버전 제어 개념

Git과 버전 제어의 개념을 이해하려면 기록적인 관점에서 버전 제어를 살펴 보는 것이 도움이됩니다. 버전 관리 소프트웨어에는 3 세대가 있습니다.

1 세대

1 세대는 매우 단순했습니다. 개발자는 동일한 물리적 시스템에서 작업하고 한 번에 하나의 파일을 "체크 아웃"했습니다.

이 버전 제어 소프트웨어는 파일 잠금 이라는 기술을 사용했습니다 . 개발자가 파일을 체크 아웃하면 다른 개발자가 파일을 편집 할 수 없도록 잠겼습니다. 

1 세대 버전 제어 소프트웨어의 예로는 RCS (Revision Control System) 및 SCCS (Source Code Control System)가 있습니다.

2 세대

1 세대의 문제점은 다음과 같습니다.

  • 한 번에 한 명의 개발자 만 파일에서 작업 할 수 있습니다. 이로 인해 개발 프로세스에 병목 현상이 발생했습니다.

  • 개발자는 버전 제어 소프트웨어가 포함 된 시스템에 직접 로그인해야했습니다.

이러한 문제는 2 세대 버전 관리 소프트웨어에서 해결되었습니다. 2 세대에서는 파일이 저장소의 중앙 서버에 저장됩니다. 개발자는 파일의 별도 사본을 확인할 수 있습니다. 개발자가 파일 작업을 완료하면 파일이 저장소에 체크인됩니다. 

두 명의 개발자가 동일한 버전의 파일을 체크 아웃하면 문제가 발생할 가능성이 있습니다. 이것은 merge 라는 프로세스에 의해 처리됩니다 .

병합이란 무엇입니까? 두 명의 개발자 인 Bob과 Sue가 abc.txt. Bob이 작업을 완료 한 후 파일을 다시 체크인합니다. 일반적으로 파일의 새 버전 인 버전 6이 생성됩니다.

얼마 후 수는 ​​자신의 파일을 확인합니다. 이 새 파일은 그녀의 변경 사항과 Bob의 변경 사항을 통합해야합니다. 이것은 병합 프로세스를 통해 수행됩니다.

사용하는 버전 제어 소프트웨어에 따라이 병합을 처리하는 다른 방법이있을 수 있습니다. Bob과 Sue가 파일의 완전히 다른 부분을 작업 한 경우와 같은 경우에는 병합 프로세스가 매우 간단합니다. 그러나 Sue와 Bob이 파일에서 동일한 코드 줄로 작업 한 경우 병합 프로세스가 더 복잡 할 수 있습니다. 이 경우 Sue는 Bob의 코드가 새 버전의 파일에 포함될 것인지 여부와 같은 결정을 내려야합니다.

병합 프로세스가 완료된 후 파일을 저장소에 커밋하는 프로세스가 발생합니다. 파일을 커밋한다는 것은 본질적으로 저장소에 새 버전을 만드는 것을 의미합니다. 이 경우 파일의 버전 7입니다.

2 세대 버전 관리 소프트웨어의 예로는 CVS (Concurrent Versions System) 및 Subversion이 있습니다.

3 세대

3 세대를 DVCS (분산 버전 제어 시스템)라고합니다. 2 세대와 마찬가지로 중앙 저장소 서버에는 프로젝트의 모든 파일이 포함됩니다. 그러나 개발자는 저장소에서 개별 파일을 체크 아웃하지 않습니다. 대신 전체 프로젝트가 체크 아웃되어 개발자가 개별 파일이 아닌 전체 파일 집합에 대해 작업 할 수 있습니다. 

2 세대와 3 세대 버전 제어 소프트웨어의 또 다른 (매우 큰) 차이점은 병합 및 커밋 프로세스의 작동 방식과 관련이 있습니다. 앞서 언급했듯이 2 세대 단계는 병합을 수행 한 다음 새 버전을 저장소에 커밋하는 것입니다.

3 세대 버전 관리 소프트웨어를 사용하면 파일이 체크인 된 다음 병합됩니다. 

예를 들어 두 명의 개발자가 세 번째 버전을 기반으로하는 파일을 체크 아웃했다고 가정 해 보겠습니다. 한 개발자가 해당 파일을 체크인하여 파일 버전 4가되는 경우 두 번째 개발자는 먼저 체크 아웃 한 복사본의 변경 사항을 버전 4 (및 잠재적으로 다른 버전)의 변경 사항과 병합해야합니다. 병합이 완료되면 새 버전을 버전 5로 저장소에 커밋 할 수 있습니다.

저장소 (각 단계의 중앙 부분)에있는 것에 초점을 맞추면 매우 직선적 인 개발 (ver1, ver2, ver3, ver4, ver5 등)이 있음을 알 수 있습니다. 소프트웨어 개발에 대한 이러한 간단한 접근 방식은 몇 가지 잠재적 인 문제를 제기합니다.

  • 개발자가 커밋하기 전에 병합하도록 요구하면 종종 개발자가 변경 사항을 정기적으로 커밋하기를 원하지 않습니다. 병합 프로세스는 고통 스러울 수 있으며 개발자는 나중에까지 기다렸다가 정기적으로 병합하는 대신 하나의 병합을 수행하기로 결정할 수 있습니다. 갑자기 엄청난 양의 코드가 파일에 추가되므로 소프트웨어 개발에 부정적인 영향을 미칩니다. 또한 문서를 작성하는 사람에게 정기적으로 저장하도록 장려하는 것처럼 개발자가 저장소에 변경 사항을 커밋하도록 장려하고 싶습니다.
  • 매우 중요합니다.이 예제의 버전 5는 개발자가 원래 완료 한 작업 일 필요는 없습니다. 병합 프로세스 중에 개발자는 병합 프로세스를 완료하기 위해 자신의 작업 중 일부를 버릴 수 있습니다. 이것은 잠재적으로 좋은 코드가 손실되기 때문에 이상적이지 않습니다.

틀림없이 더 복잡하지만 더 나은 기술을 사용할 수 있습니다. 이를 DAG (Directed Acyclic Graph )라고 합니다.

두 명의 개발자가 파일의 버전 3을 확인하는 위와 동일한 시나리오를 상상해보십시오. 여기에서 한 개발자가 해당 파일을 체크인해도 파일 버전 4가 생성됩니다. 그러나 두 번째 체크인 프로세스에서는 버전 4를 기반으로하지 않고 오히려 버전 4와 독립적 인 버전 5 파일이 생성됩니다. 프로세스의 다음 단계에서 파일의 버전 4와 5가 병합되어 버전이 생성됩니다. 6.

이 프로세스는 더 복잡하지만 (개발자가 많은 경우 잠재적으로 훨씬 더 복잡함) 단일 개발 라인에 비해 몇 가지 이점을 제공합니다.

  • 개발자는 변경 사항을 정기적으로 커밋 할 수 있으며 나중에 병합하는 것에 대해 걱정할 필요가 없습니다.
  • 병합 프로세스는 다른 개발자보다 전체 프로젝트 또는 코드에 대해 더 잘 알고있는 특정 개발자에게 위임 될 수 있습니다.
  • 언제든지 프로젝트 관리자는 돌아가서 각 개발자가 만든 작업을 정확히 볼 수 있습니다.

확실히 두 메서드에 대한 인수가 존재합니다. 그러나이 기사는 3 세대 버전 제어 시스템의 방향성 비순환 그래프 방법을 사용하는 Git에 초점을 맞추고 있음을 명심하십시오.

Git 설치

때때로 기본적으로 설치되기 때문에 (또는 다른 관리자가 설치했을 수 있으므로) 시스템에 이미 Git이있을 수 있습니다. 일반 사용자로 시스템에 액세스 할 수있는 경우 다음 명령을 실행하여 Git이 설치되어 있는지 확인할 수 있습니다.

ocs @ ubuntu : ~ $ 어느 자식 / usr / bin / git

If Git is installed, then the path to the git command is provided, as shown in the preceding command. If it isn’t installed, then you either get no output or an error like the following:

[[email protected] ~]# which git /usr/bin/which: no git in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/ bin:/usr/sbin:/bin:/sbin:/root/bin)

As an administrator on a Debian-based system, you can use the dpkg command to determine whether the Git package has been installed:

[email protected]:~# dpkg -l git Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/ ➥Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-========-=============-=============-======================================== ii git 1:1.9.1-1ubun amd64 fast, scalable, distributed ➥revision con

As an administrator on a Red Hat–based system, you could use the rpm command to determine whether the git package has been installed:

[[email protected] ~]# rpm -q git git-1.8.3.1-6.el7_2.1.x86_64

If Git isn’t installed on your system, you must either log in as the root user or use sudo or su to install the software. If you are logged in as the root user on a Debian-based system, you can use the following command to install Git:

apt-get install git

If you are logged in as the root user on a Red Hat–based system, you can use the following command to install Git:

yum install git

Get more than Git

Consider installing the software package git-all. This package includes some additional dependency packages that add more power to Git. Although you might not use these features in the beginning, having them available when you are ready to perform more advanced Git functions will be good.

Git concepts and features

One of the challenges to using Git is just understanding the concepts behind it. If you don’t understand the concepts, then all the commands just seem like some sort of black magic. This section focuses on the critical Git concepts as well as introduces you to some of the basic commands.

Git stages

It is very important to remember that you check out an entire project and that most of the work you do will be local to the system that you are working on. The files that you check out will be placed in a directory under your home directory.

To get a copy of a project from a Git repository, you use a process called cloning. Cloning doesn’t just create a copy of all the files from the repository; it actually performs three primary functions:

  • Creates a local repository of the project under the project_name/.git directory in your home directory. The files of the project in this location are considered to be checked out from the central repository.
  • Creates a directory where you can directly see the files. This is called the working area. Changes made in the working area are not immediately version controlled.
  • Creates a staging area. The staging area is designed to store changes to files before you commit them to the local repository.

This means that if you were to clone a project called Jacumba, the entire project would be stored in the Jacumba/.git directory under your home directory. You should not try to modify these directly. Instead, look directly in the ~/Jacumba directory tol see the files from the project. These are the files that you should change.

Suppose you made a change to a file, but you have to work on some other files before you were ready to commit changes to the local repository. In that case, you would stage the file that you have finished working on. This would prepare it to be committed to the local repository.

After you make all changes and stage all files, then you commit them to the local repository. 

Realize that committing the staged files only sends them to the local repository. This means that only you have access to the changes that have been made. The process of checking in the new versions to the central repository is called a push.

Choosing your Git repository host

First, the good news: Many organizations provide Git hosting—at the time of this writing, there are more than two dozen choices. This means you have many options to choose from. That’s the good news … and the bad news.

It is only bad news because it means you really need to spend some time researching the pros and cons of the hosting organizations. For example, most don’t charge for basic hosting but do charge for large-scale projects. Some only provide public repositories (anyone can see your repository) whereas others let you create private repositories. There are many other features to consider.

One feature that might be high on your list is a web interface. Although you can do just about all repository operations locally on your system, being able to perform some operations via a web interface can be very useful. Explore the interface that is provided before making your choice.

At the very least, I recommend considering the following:

  • //bitbucket.org
  • //www.cloudforge.com
  • //www.codebasehq.com
  • //github.com
  • //gitlab.com

Note that I chose Gitlab.com for the examples below. Any of the hosts in the preceding list would have worked just as well; I chose Gitlab.com simply because it happened to be the one I used on my last Git project.

Configuring Git

Now that you have gotten through all the theory, it is time to actually do something with Git. This next section assumes the following:

  • You have installed the git or git-all software package on your system.
  • You have created an account on a Git hosting service.

The first thing you want to do is perform some basic setup. Whenever you perform a commit operation, your name and email address will be included in the metadata. To set this information, execute the following commands:

ocs @ ubuntu : ~ $ git config --global user.name "Bo Rothwell"ocs @ ubuntu : ~ $ git config --global user.email "[email protected]"

분명히 당신은 "Bo Rothwell"당신의 이름과 "[email protected]"이메일 주소로 대체 할 것 입니다. 다음 단계는 Git 호스팅 서비스에서 프로젝트를 복제하는 것입니다. 복제하기 전에 사용자의 홈 디렉토리에는 하나의 파일 만 있습니다.

ocs @ ubuntu : ~ $ ls first.sh

다음은 ocs라는 프로젝트를 복제했습니다.