Git version что это за программа: контроль версий для самых маленьких

контроль версий для самых маленьких

Про основы Git было сказано немало. Здесь же собрана информация, обязательная к изучению тем, кто знакомится с этим инструментом с нуля.

Контроль версий помогает разработчикам отслеживать изменения в коде программного проекта и управлять ими. Чем больше размер проекта, тем важнее становится использование контроля версий.

Возьмем, к примеру, Facebook. Над ним одновременно работают тысячи разработчиков, но никто из них не переписывает код друг друга. Контроль версий гарантирует, что софт всегда будет иметь одну рабочую, или «master» версию. Было бы небезопасно, если бы все разработчики имели возможность редактировать основной исходный код.

Каждый разработчик может скопировать кусок основного исходного кода (он же ветвь). Затем внести изменения в эту часть кода, не затрагивая остальную часть проекта. Эти правки передаются на слияние с основной версией. Все изменения, внесенные в каждый файл, отслеживаются, журналируются и при необходимости могут быть восстановлены.

Пока ничего сложного, правда? 😉 Идем дальше.

Git – это система управления версиями с открытым исходным кодом, созданная Линусом Торвальдсом в 2005 году.

В частности, Git – это распределенная система управления версиями, а значит, вся кодовая база и история доступны на каждом компьютере разработчика, и это позволяет легко «ветвиться и сливаться».

GitHub – это некоммерческая компания, предлагающая облачный сервис хранения Git-репозиториев, что позволяет без лишних усилий использовать Git для совместной работы.

GitHub имеет user-friendly интерфейс, поэтому даже начинающие разработчики смогут с ним работать. Можно использовать «чистый» Git без GitHub, но такой подход требует больше знаний и опыта работы с командной строкой.

Кроме того, каждый может бесплатно зарегистрироваться и опубликовать любое количество публичных и ограниченное количество приватных репозиториев, что делает GitHub особенно популярным среди проектов с открытым исходным кодом.

Чтобы дать вам общее представление о том, как выглядит интерфейс GitHub, вот исходный код небольшого проекта:

Здесь вы можете видеть различные ветки, над которыми работают в данный момент, а также кто и когда сделал коммит. Коммиты важны, потому что они представляют информацию о том, что было изменено в файле. Этот процесс похож на сохранение файла, но более информативен. В зависимости от настроек репозитория, вы можете создать свою собственную ветку и делать там коммиты.

Каждый коммит создает слепок репозитория со своим порядковым номером. Если в проекте было что-то изменено, Git обязательно сообщит об этом и предложит некоторые действия.

Если вы удалите данные из рабочей копии, информация о ней сохранится в папке .git – это ключевая особенность, позволяющая откатиться по истории, сделать откат изменений и т. д.

Когда вы внесли изменения, нужно отправить код обратно в ветку с помощью pull request.

Вы также можете редактировать часть или весь исходный код в своей учетке «на постоянной основе», нажав кнопку «fork» в правом углу. Fork похож по концепции на ветку, но он копирует репозиторий в вашу собственную учетку GitHub.

Файлы Git могут быть в трех состояниях: staged, modified и untracked.

Вся эта информация обретет смысл, когда вы поближе познакомитесь с ветками.

Чтобы начать работу с GitHub:

Также не забывайте о том, что Git репозитории следует держать в чистоте.

Оригинал

Расскажите, что вам помогло освоить Git на первых этапах?

Локальная настройка репозитория Git — Contributor Guide

• 
  01/18/2018
• Чтение занимает 5 мин
• 
  

В этой статье

В этой статье показано, как настроить репозиторий Git на локальном компьютере для создания документации по продуктам Майкрософт.This article describes the steps to set up a Git repository on your local machine, with the intent to contribute to Microsoft documentation. Добавлять новые статьи, вносить значительные правки в существующие и изменять графическое оформление можно при помощи локально клонированного репозитория.Contributors may use a locally cloned repository to add new articles, do major edits on existing articles, or change artwork.

Чтобы приступить к работе с документацией, необходимо однократно выполнить следующие действия:You run these one-time setup activities to start contributing:

• определить соответствующий репозиторий;Determine the appropriate repository
• создать вилку репозитория Git в учетной записи GitHub;Fork the repository to your GitHub account
• выбрать локальную папку для клонированных файлов;Choose a local folder for the cloned files
• клонировать репозиторий на локальный компьютер;Clone the repository to your local machine
• настроить значение вышестоящего удаленного источника.Configure the upstream remote value

Общие сведенияOverview

Для участия в разработке документации на сайте Майкрософт вы можете локально создавать и редактировать файлы Markdown, клонировав соответствующий репозиторий документации.To contribute to Microsoft’s documentation site, you can make and edit Markdown files locally by cloning the corresponding documentation repository. Чтобы получить разрешения Майкрософт на чтение и запись для соответствующего репозитория, нужно создать его вилку в учетной записи GitHub. Это позволит сохранять предлагаемые изменения.Microsoft requires you to fork the appropriate repository into your own GitHub account so that you have read/write permissions there to store your proposed changes. Затем изменения объединяются в центральном общем репозитории, доступном только для чтения, с помощью запросов на вытягивание.Then you use pull requests to merge changes into the read-only central shared repository.

Если вы раньше не работали с GitHub, посмотрите следующее видео, где представлен концептуальный обзор процесса создания вилок и клонирования репозиториев:If you’re new to GitHub, watch the following video for a conceptual overview of the forking and cloning process:

Определение репозиторияDetermine the repository

Документация, размещенная на сайте docs.microsoft.com, находится в нескольких разных репозиториях на github.com.Documentation hosted at docs.microsoft.com resides in several different repositories at github.com.

1. Если вы точно не знаете, какой репозиторий использовать, откройте статью на сайте docs.microsoft.com в своем веб-браузере.If you are unsure of which repository to use, then visit the article on docs.microsoft.com using your web browser. Справа над статьей выберите ссылку Правка (значок карандаша).Select the Edit link (pencil icon) on the upper right of the article.

2. По этой ссылке вы перейдете к расположению нужного файла Markdown в соответствующем репозитории на сайте github.com.That link takes you to github.com location for the corresponding Markdown file in the appropriate repository. Запишите URL-адрес, чтобы узнать имя репозитория.Note the URL to view the repository name.

   Например, для участия в создании документации можно использовать следующие популярные репозитории:For example, these popular repositories are available for public contributions:

Создание вилки репозиторияFork the repository

Используя соответствующий репозиторий, создайте его вилку в своей учетной записи GitHub на сайте GitHub.Using the appropriate repository, create a fork of the repository into your own GitHub account by using the GitHub website.

Персональная вилка необходима, поскольку все основные репозитории документации предоставляют доступ только для чтения.A personal fork is required since all main documentation repositories provide read-only access. Чтобы внести изменение, вам нужно отправить из вилки в основной репозиторий запрос на вытягивание.To make changes, you must submit a pull request from your fork into the main repository. Чтобы ускорить этот процесс, сначала следует создать копию репозитория с доступом на запись.To facilitate this process, you first need your own copy of the repository, in which you have write access. Вилка в GitHub решает эту задачу.A GitHub fork serves that purpose.

1. Перейдите в GitHub на страницу главного репозитория, а затем нажмите кнопку Fork (Создать вилку) вверху справа.Go to the main repository’s GitHub page and click the Fork button on the upper right.

2. Если будет предложено, выберите плитку своей учетной записи GitHub в качестве расположения для создаваемой вилки.If you are prompted, select your GitHub account tile as the destination where the fork should be created. После этого в вашей учетной записи GitHub будет создана копия репозитория, называемая вилкой.This prompt creates a copy of the repository within your GitHub account, known as a fork.

Выбор локальной папкиChoose a local folder

Создайте локальную папку для локального хранения копии репозитория.Make a local folder to hold a copy of the repository locally. Размер некоторых репозиториев может быть значительным, например до 5 ГБ для azure-docs.Some of the repositories can be large; up to 5 GB for azure-docs for example. Выберите расположение с доступным местом на диске.Choose a location with available disk space.

1. Выберите имя папки — оно должно быть простым для запоминания и ввода.Choose a folder name should be easy for you to remember and type. Например, можно использовать корневую папку C:\docs\ или создать папку в каталоге профиля пользователя ~/Documents/docs/For example, consider a root folder C:\docs\ or make a folder in your user profile directory ~/Documents/docs/

   Важно!

   Не следует выбирать путь к локальной папке, вложенной в другую папку репозитория Git.Avoid choosing a local folder path that is nested inside of another git repository folder location. Несмотря на то что, что клонированные папки Git можно хранить рядом друг с другом, вложение папок Git приводит к ошибкам отслеживания файлов.While it is acceptable to store the git cloned folders adjacent to each other, nesting git folders inside one another causes errors for the file tracking.

2. Запустите Git BashLaunch Git Bash

   Расположением по умолчанию, в котором обычно запускается Git Bash, является домашний каталог (~) или /c/users/<Windows-user-account>/ в ОС Windows.The default location that Git Bash starts in is typically the home directory (~) or /c/users/<Windows-user-account>/ on Windows OS.

   Чтобы определить текущий каталог, ведите pwd в запросе $.To determine the current directory, type pwd at the $ prompt.

3. Преобразуйте каталог (cd) в папку, созданную для локального размещения репозитория.Change directory (cd) into the folder that you created for hosting the repository locally. Обратите внимание, что Git Bash поддерживает соглашение Linux по использованию в путях к папкам прямых, а не обратных косых черт.Note that Git Bash uses the Linux convention of forward-slashes instead of back-slashes for folder paths.

   Например, cd /c/docs/ или cd ~/Documents/docs/.For example, cd /c/docs/ or cd ~/Documents/docs/

Создание локального клонаCreate a local clone

С помощью Git Bash подготовьтесь выполнить команду клонирования для вытягивания копии репозитории (вашей вилки) в текущий каталог на устройстве.Using Git Bash, prepare to run the clone command to pull a copy of a repository (your fork) down to your device on the current directory.

Проверка подлинности с использованием Git Credential ManagerAuthenticate by using Git Credential Manager

Если вы установили последнюю версию Git для Windows и согласились на установку по умолчанию, будет по умолчанию активирован диспетчер учетных данных Git Credential Manager.If you installed the latest version of Git for Windows and accepted the default installation, Git Credential Manager is enabled by default. Git Credential Manager упрощает проверку подлинности, избавляя от необходимости отзывать личный маркер доступа при повторной установке подключений с проверкой подлинности и удаленных подключений с GitHub.Git Credential Manager makes authentication much easier because you don’t need to recall your personal access token when re-establishing authenticated connections and remotes with GitHub.

1. Выполните команду клонирования, указав имя репозитория.Run the clone command, by providing the repository name. Во время клонирования разветвленный репозиторий скачивается (клонируется) на локальный компьютер.Cloning downloads (clone) the forked repository on your local computer.

   Совет

   Чтобы получить URL-адрес своей вилки GitHub для команды клонирования, нажмите кнопку Clone or download (Клонировать или скачать) в пользовательском интерфейсе GitHub:You can get your fork’s GitHub URL for the clone command from the Clone or download button in the GitHub UI:

   В процессе клонирования обязательно укажите путь к своей вилке, а не к главному репозиторию, из которого вы ее создали.Be sure to specify the path to your fork during the cloning process, not the main repository from which you created the fork. В противном случае вы не сможете вносить изменения.Otherwise, you cannot contribute changes. Ссылки на вашу вилку осуществляются по имени вашей личной учетной записи GitHub, например github.com/<github-username>/<repo>.Your fork is referenced through your personal GitHub user account, such as github.com/<github-username>/<repo>.

   git clone https://github.com/<github-username>/<repo>.git
   

   Команда клонирования должна выглядеть приблизительно следующим образом.Your clone command should look similar to this example:

   git clone https://github.com/smithj/azure-docs.git
   

2. При появлении запроса введите учетные данные GitHub.When you’re prompted, enter your GitHub credentials.

3. При появлении запроса введите код двухфакторной проверки подлинности.When you’re prompted, enter your two-factor authentication code.

   Примечание

   Ваши учетные данные будут сохранены для проверки подлинности последующих запросов GitHub.Your credentials will be saved and used to authenticate future GitHub requests. Проверка подлинности выполняется на каждом компьютере один раз.You only need to do this authentication once per computer.

4. Запущенная команда клонирования скачивает копию файлов репозитория из вашей вилки в новую папку на локальном диске.The clone command runs and downloads a copy of the repository files from your fork into a new folder on the local disk. Новая папка создается в текущей папке.A new folder is made within the current folder. В зависимости от размера репозитория этот процесс может занять несколько минут.It may take a few minutes, depending on the repository size. По его окончании вы можете открыть папку, чтобы просмотреть ее структуру.You can explore the folder to see the structure once it is finished.

Настройка удаленного вышестоящего подключенияConfigure remote upstream

После клонирования репозитория следует установить удаленное подключение только для чтения, называемое вышестоящим, к основному репозиторию.After cloning the repository, set up a read-only remote connection to the main repository named upstream. С помощью URL-адреса вышестоящего подключения вы сможете обеспечить синхронизацию вашего локального репозитория с последними правками, внесенными другими участниками.You use the upstream URL to keep your local repository in sync with the latest changes made by others. Команда git remote служит для задания значения конфигурации.The git remote command is used to set the configuration value. С помощью команды принесения можно обновить сведения о ветви из вышестоящего репозитория.You use the fetch command to refresh the branch info from the upstream repository.

1. Если вы используете Git Credential Manager, выполните следующие команды.If you’re using Git Credential Manager, use the following commands. Замените заполнители <repo> и <organization> .Replace the <repo> and <organization> placeholders.

   cd <repo>
   git remote add upstream https://github.com/<organization>/<repo>.git
   git fetch upstream
   

2. Просмотрите настроенные значения и проверьте правильность URL-адресов.View the configured values and confirm the URLs are correct. Убедитесь, что URL-адреса исходного подключения ведут к вашей персональной вилке.Ensure the origin URLs point to your personal fork. Убедитесь, что URL-адреса вышестоящего подключения ведут к основному репозиторию, например MicrosoftDocs или Azure.Ensure the upstream URLs point to the main repository, such as MicrosoftDocs or Azure.

   git remote -v 
   

   Далее приводится пример выходных данных для подключения к удаленному репозиторию.Example remote output is shown. Здесь вымышленная учетная запись Git с именем MyGitAccount настраивается с личным маркером доступа для обращения к репозиторию azure-docs.A fictitious git account named MyGitAccount is configured with a personal access token to access the repo azure-docs:

   origin  https://github.com/MyGitAccount/azure-docs.git (fetch)
   origin  https://github.com/MyGitAccount/azure-docs.git(push)
   upstream        https://github.com/MicrosoftDocs/azure-docs.git (fetch)
   upstream        https://github.com/MicrosoftDocs/azure-docs.git (push)
   

3. Если вы допустили ошибку, значение удаленного подключения можно очистить.If you made a mistake, you can remove the remote value. Чтобы удалить значение вышестоящего подключения, выполните команду git remote remove upstream.To remove the upstream value, run the command git remote remove upstream.

Дальнейшие действияNext steps

«git» не распознается как внутренняя или внешняя команда

Windows 7 32 — бит

Я использую git для моего приложения Ruby on Rails. В первый раз…

Я создал .файл bat для загрузки моих приложений RoR с путями, набранными вручную с помощью этого урока в»http://www.youtube.com/watch?v=-eFwV8lRu1w » Если вы новичок в Ruby on Rails, вы можете проверить его, поскольку я следовал всем шагам, и он работает безупречно после нескольких проб и ошибок.

(The .bat файл для редактирования использование notepad++, следовательно, нет необходимости в длительном процессе всякий раз, когда вам нужно отредактировать путь, вы можете следовать этим простым процессом после создания.файл bat после учебных пособий по ссылке выше » файл называется row.летучая мышь.»)

1. щелкните правой кнопкой мыши на .bat file,
2. редактировать с помощью notepad++.
3. найти путь.

4. вставьте путь ниже последнего пути, который вы ввели.

   )
   Во время уроков я не помню, что было сказано в что касается использования команды git, поэтому при запуске нового проекта у меня была такая же проблема после установки git. Основная проблема, которую я имел, заключалась в поиске папки с bin/git.exe (git.exe не появился в поиске с помощью меню «Пуск «»поиск программ и файлов» ) Примечание.теперь я понял, что местоположение может сильно отличаться — см. ниже.

чтобы найти bin / git.exe я выполнил эти шаги

1 щелкните левой кнопкой мыши меню «Пуск» и найдите ->> все программы ->> Гитхаб Инк.
2 щелкните правой кнопкой мыши git shell и выберите Открыть файл
3 щелкните по папкам в папке в папку «bin»

(У меня было 4 папки с именами
1. IgnoreTemplates_fdbf2020839cde135ff9dbed7d503f8e03fa3ab4
2. lfs-x86_0.5.1
3. PortableGit_c2ba306e536fdf878271f7fe636a147ff37326ad («bin / exe, найдено здесь

скопируйте полную ссылку, нажав на url-адрес исследователей
(мой был «C:\Users\username\AppData\Local\GitHub\PortableGit_c2ba306e536fdf878271f7fe636a147ff37326ad\bin») открыть .bat файл в Notepad++ и вставить, используя инструкции о том, как добавить путь к вашей .bat файл из учебников выше. Проблема решена!

Сам по себе Git — это эффективная технология с открытым исходным кодом, позволяющая отслеживать локальные изменения при разработке кода, особенно при создании сложного программного обеспечения.

И хотя в инструмент встроены распределенные средства, многие разработчики используют Git исключительно как механизм для локального и частного отслеживания изменений.

Когда разработчики хотят взять свой локальный репозиторий Git и поделиться им с другим разработчиком или отправить код в облачную распределенную службу контроля версий, такую как GitHub или GitLab, они могут использовать команду git remote add origin.

Три файла и два коммита

Прежде чем следовать этому учебнику по git remote add origin, настройте локальную установку Git, локально инициализированный репозиторий по крайней мере с одним коммитом Git и учетную запись в GitHub или GitLab.

Для этого урока мы будем использовать GitHub, но процесс с GitLab практически идентичен.

Начните с локального репозитория, хранящегося в папке с именем my-local-repo, в которой находятся три файлов:

Сам репозиторий имеет только две коммита, которые вы можете увидеть, выполнив команду git reflog, как показано на рисунке ниже.

Reflog — это сокращение от reference logs.

Создайте удаленный репозиторий на GitHub

После проверки локального репозитория следующим шагом является создание удаленного репозитория, к которому будет подключаться локальный.

Создать удаленный репозиторий легко.

Войдите в GitHub и воспользуйтесь мастером «Create a new repository».

В этом примере я назвал репозиторий GitHub my-github-repo, чтобы четко отличить его от репозитория Git, который хранится локально в папке с именем my-local-repo.

Поскольку вы будете передавать информацию в репозиторий GitHub, не инициализируйте ее с помощью README, настройте файл gitignore или добавьте лицензию.

Все эти вещи будут существовать в локальном репозитории и будут впоследствии перенесены в удаленный GitHub.

Если эти ресурсы существуют в обоих репозиториях до запуска команды git remote add origin, это создаст дополнительные шаги слияния и разрешения конфликтов, которых легко избежать.

Скопируйте и измените URL удаленного добавления GitHub

Когда GitHub создает ваш репозиторий, он представляет ссылку HTTP, которая требуется как часть команды git remote add origin.

При условии, что URL-адрес уникально идентифицирует созданный мной репозиторий GitHub:

http://github.com/cameronmcnz/my-github-repo.git

Скопируйте и вставьте этот URL-адрес в текстовый редактор, а затем добавьте свое имя пользователя и пароль в начало URL-адреса:

http://cameronmcnz:[email protected]/cameronmcnz/my-github-repo.git

Эта настройка URL позволяет аутентифицировать файл без использования диспетчера учетных данных или другого инструмента управления паролями.

Запустите команду git remote add origin

С URL-адресом GitHub, сохраненным в буфере обмена в папке, содержащей локальный репозиторий Git, откройте окно терминала и выполните следующую команду git remote add origin:

git remote add origin http://cameronmcnz:T55tutorial@github.com/cameronmcnz/my-github-repo.git

Эта команда будет выполнена, но система не предоставит никакой обратной связи в окне терминала.

Чтобы убедиться, что удаленное хранилище было добавлено в вашу конфигурацию, используйте команду git remote –v.

Эта команда покажет, что GitHub является целью выборки и отправки локального репозитория.

Выполните git push

Наконец, с настроенной службой GitHub отправьте все свои локальные изменения кода, историю изменений на удаленный сервер с помощью команды git push.

Убедитесь, что вы указали опцию —set-upstream, иначе удаленный сервер отклонит операцию.

Также включите название ветки, которую нужно нажать, которая в этом случае является master.

git push --set-upstream origin master

По завершении этого действия в окне терминала отображается количество объектов, отправленных на сервер, и указывается, что ваш локальный репозиторий настроен на отслеживание ветки с именем master на сервере GitHub.

Убедитесь, что прошел git push на GitHub

После завершения команд git remote add и push вернитесь к экземпляру GitHub и посмотрите на содержимое недавно созданного репозитория.

Результат локальной команды git remote add и push отражается в удаленном репозитории GitHub.

Удаленный репозиторий GitHub должен содержать все файлы, которые составляют ваш локальный репозиторий, и в то же время хранить копию вашей истории коммитов.

Если вы посмотрите на мой репозиторий GitHub, вы увидите файлы HelloWorld.java, index.html и style.css, а также указание на то, что репозиторий содержит две фиксации.

Эти файлы и коммиты соответствуют выводу команды git reflog с самого начала этого урока.

Поделитесь статьей:

Разбираемся с GIT

Git — это распределенная система управления версиями.

Для начала установим GIT

Первоначальные настройки

git config --list

Выводит список всех настроек.

Для начала зададим имя:

git config --global user.name "Dmitriy"

И зададим e-mail в глобальную настройку:

git config --global user.email "[email protected]"

Параметры установки окончаний строк:

Для предотвращения проблем, при работе на разных операционных системах.

для unix/mac:

git config --global core.autocrlf input
git config --global core.safecrlf warn

для виндовс:

git config --global core.autocrlf true
git config --global core.safecrlf warn

Установка отображения unicode

git config --global core.quotepath off

Создание репозитория

Для создания репозитория, нужно из папки проекта, набрать команду:

git init

Для добавления файлов в репозиторий:

git add index.html
git commit -m "create file"

Проверка состояния репозитория

git status

После внесения изменений в файл, например index.html

Можно или проиндексировать их командой

git add index.html

Или использовать команду, для отмены изменений:

git checkout --index.html

После индексации изменений, можно:

Снять индексацию изменений, командой:

git reset HEAD index.html

Командой commit — можно закомитить все проиндексированные изменения.

Для индексации всех изменений в каталоге и подкаталогах, можно использовать команду

git add .

Просмотр истории

git log

Формат истории настраивается, допустим будем использовать такой:

git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short

Чтобы не набирать такую длинную команду, можно задать алиас:

git config --global alias.hist "log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short"

Получение старых версий

Для получения старой версии, нужно ввести команду:

git checkout <hash>

В качестве hash, используется версия, которая выводится при git config, достаточно использовать первые 7 знаков хэш-кода.

Для возврата к последней версии в ветке master, используется команда

git checkout master

Создаем теги версий

git tag v1

После этого можно использовать при откатывании название тега, вместо хэша:

git checkout v1

Для откатывания на предыдущую версию, которая перед тегом v1, можно использовать такую команду:

git checkout v1~1

Для того чтобы сделать коммит, который отменит предыдущий, можно набрать команду:

git revert HEAD --no-edit

Сброс коммитов до определенного:

git reset --hard v1

Изменение предыдущего коммита:

git commit --amend -m "Add fishka"

Создаем ветку

git branch <имяветки>

Переключаемся на созданную ветку

git checkout <имяветки>

Слияние веток

git merge master

Перебазирование

git rebase master

Лучше не использовать перебазирование, если ветка является публичной или расшаренной.

Клонирование репозиториев

git clone hello cloned_hello

Посмотреть ветки

git branch

Или все ветки

git branch -a

Извлечение изменений в клонированном репозитории

git fetch

Слияние извлеченных изменений

git merge origin/master

Или для слияния можно использовать

git pull

что эквивалентно:

git fetch
git merge origin/master

Добавление ветки наблюдения

git branch --track styles origin/styles

Создание чистого репозитория

git clone --bare hello hello.git

Добавление удаленного репозитория

git remote add shared ../hello.git

Отправка изменений в удаленный репозиторий

git push shared master

Извлечение общих изменений

git remote add shared ../hello.git
git branch --track shared master
git pull shared master

Далее запускаем git сервер и можно использовать совместно.

Что такое Git? Первоначальная настройка git | kychka-pc

Вместо вступления

Прежде всего, нужно понять, что Git – не такая уж и страшная вещь, как может поначалу показаться. Да, вы можете заметить, что объем «небольшого» туториала вышел более чем внушительным, но, уверяю вас, это отнюдь не показатель сложности! Скорее возможностей, которые Git способен предоставить разработчику. Поэтому будьте мужественным и дочитайте статью до конца.

В данной статье я не стану говорить о работе, с какими бы там ни было сторонними оболочками (TortoiseGit, SourceTree) – только со стандартными интерфейсами. Освещения особых тонкостей Git тоже не ждите – здесь только самое необходимое. Задача этой статьи: дать читателю базовые представления о Git и работе с ним, рассказать об основных операциях, помочь освоиться, а далее читатель сам сможет выбрать тот интерфейс, который сочтет удобным, и углубить свои знания самостоятельно, если сочтет нужным.

Пожалуй, пора приступать к самой сути. А начну с того, что расскажу немного о…

Немного о Git

Как вы уже могли прочитать в Википедии (вы ведь любознательный юзер, не так ли?), Git – система управления версиями некоторого проекта. Что же скрывается под этой весьма туманной формулировкой? Попробую объяснить «на пальцах»:

Давайте представим, что вы играете в видео игру. Например, в RPG. Ваш персонаж развивается, получает экспу, совершенствуется. Вы косите недругов налево и направо несколькими кликами мышки.

Но кто не делает ошибок? Однажды вы заворачиваете за очередной угол очередного подземелья и (OMG) натыкаетесь на соперника, который слишком силен! И в момент, когда ваше поражение уже совсем очевидно вы просто – что делаете? Правильно! Загружаете свое последнее сохранение! Если у вас есть привычка сохраняться часто и к месту, то ваш игровой прогресс не слишком пострадает.

Теперь все снова хорошо: вы живы и здоровы, и больше не пойдете туда, где вас поджидает смерть. Или пойдете, в надежде все же одолеть врага? Впрочем, это уже не важно. А важно то, что каких бы ошибок вы не наделали, у вас всегда есть возможность все исправить, просто откатившись немного назад. Именно эту возможность, «просто откатиться» до прошлой версии, если что-то испортили, и предоставляет Git, с той лишь разницей, что речь идет не о видео игре, а об IT-проекте, и играть вы можете не один, а в компании, причем каждый из участников также сможет играть вашим персонажем и сохранять свой прогресс.

Каждое «сохранение» в Git не перезаписывает предыдущее, поэтому в любой момент вы можете вернуться к любой версии своего проекта, а не только к последней. Такие «сохранения» называются коммитами (commit) или фиксациями. Ряд идущих друг за другом коммитов образуют ветвь (branch). Для наглядности я набросал в графическом редакторе рисунок:

Здесь мы видим четыре коммита, образующих ветвь master: первый коммит – состояние проекта на момент старта, второй и третий коммиты – промежуточные состояния, а четвертый коммит – текущее состояние проекта (его актуальная версия). Название master носит основная ветвь проекта. Если бы проект был деревом, а на самом деле так оно и есть, то ветвь master была бы стволом этого дерева.

Все дерево проекта хранится в специальном хранилище – репозитории (repository), который физически может располагаться на вашем жестком диске (локальный репозиторий) или на удаленном сервере (глобальный репозиторий). Правом доступа к локальному репозиторию обладает только один человек; с глобальным могут оперировать несколько персон.

От любой ветви могут быть ответвлены и другие ветви, которые также будут состоять из коммитов. Здесь у пытливого читателя должен возникнуть вопрос: «А зачем от основной ветви может понадобиться ответвлять другие?» Чтобы дать на этот вопрос исчерпывающий ответ, снова смоделируем ситуацию:

Некто Вася пишет калькулятор. Это очень сложный калькулятор, и одному Васе просто не справиться! Именно поэтому он приглашает к себе в команду Петю. Петя охотно соглашается, он полон идей и желания трудиться (всем бы так). Поэтому он просит Васю поскорее выделить ему конкретную задачу, на которую он бы мог направить свою энергию. У Васи уже готов некоторый базовый код, и он решается поручить Пете внедрение некоторой крутой фичи. Сам же Вася, там временем, планирует продолжать работу с основным кодом.

И вот тут-то и начинаются проблемы. Если Вася и Петя будут работать одновременно, то у них могут появиться коллизии, т.е. такие строки кода, в которые оба участника внесут разные изменения. И чьи изменения, в таком случае, считать приоритетными? Правильный ответ: изменения обоих программистов! Ведь каждый из них менял проект, чтобы реализовать свою конкретную подзадачу. Именно поэтому под каждую подзадачу, выделенную одному из участников, удобно отводить отдельную ветвь.

Учитывая это, Петя ответвляет от master ветвь feature и продолжает работать уже в ней. Одновременно с ним Вася продолжает совершенствовать свою часть кода, и они не мешают друг другу.

В какой-то момент Петя заканчивает внедрять свою фичу и показывает ее Васе. Васе нравится код Пети, и он решает включить его в свою основную ветвь. Для этого он будет использовать слияние (merge). Процесс слияния нужно понимать как вставку строк, написанных Петей, в код, написанный Васей. Разумеется, при слиянии также образуются коллизии, и их придется устранять вручную (благо, Git сам способен отмечать какая строка куда вставится и что из этого получится), но лучше делать это один раз, чем с каждой новой фиксацией. В этом и есть основная цель ветвления и дальнейшего слияния.

После того, как Вася замерджил ветви master и feature, ветвь feature замыкается, но продолжает существовать. Примерный процесс разработки этого выдуманного Васей и Петей проекта я запечатлел в виде схемы, которую вы можете видеть ниже:

В более сложных проектах от ветви feature может быть ответвлена еще одна или несколько ветвей, а от них еще и еще… ровно столько, сколько понадобится. Если код, разрабатываемый в конкретной ветви, не оправдывает ожиданий, то ветвь может быть полностью удалена. Ветвление делает командную разработку более слаженной и удобной, что является еще одним преимуществом Git.

На этом можно считать теоретическую часть статьи законченной. Прежде, чем идти дальше, рекомендую перечитать ее еще раз, уделяя особое внимание основным понятиям: repository, commit, branch, merge. Как только почувствуете, что освоились, переходите к следующей части.

Установка

Для начала нужно скачать сам Git, представленный набором утилит. Скачать актуальную версию можно отсюда.

Я буду описывать работу с Git под Windows, используя стандартный графический интерфейс, включенный в поставку. Также каждое свое действие я буду дублировать в виде консольной команды для Git Bash (терминал Git). Ввиду того, что данное руководство предназначается для новичков, все объяснения механизма работы системы будут проходить на примере работы в Git Gui, а замечания относительно консоли я буду заключать в рамки кода. Объяснения будут вестись параллельно, поэтому вне зависимости от того, какой интерфейс вы решите использовать, это руководство окажется вам полезным. Если вам интересно, базовый список консольных команд можно посмотреть тут.

Скачав последнюю версию Git для используемой вами системы, переходим к установке. Я не вижу смысла заострять внимание на этом пункте, т.к. никаких настроек при установке производить не нужно – мы все настроим уже после нее. Единственное – укажите путь установки, не содержащий кириллицу. Все остальное оставьте по умолчанию. Если у вас возникнут какие-нибудь проблемы, не стесняйтесь, спрашивайте.

После установки вы уже можете создать свой собственный локальный репозиторий, в котором будете работать только вы. Для тренировки давайте так и сделаем.

Откройте проводник и создайте где-нибудь папку, в которой будет располагаться ваше хранилище. Я на своем ПК расположил ее по такому адресу: D:\MyTestProject

Далее нужно открыть эту папку и инициализировать в нее Git. Делается это правым кликом мышки по пустой области папки и выбором из контекстного меню пункта «Git Init Here».

После этого в нашей рабочей папке появится скрытая папка .git. Здесь я не стану описывать, что содержит эта папка, однако, если вам очень это интересно, вы можете почитать об этом в другой статье. Скажу лишь, что в ней содержатся некоторые файлы с параметрами данного хранилища.

Теперь ваш собственный репозиторий располагается в папке MyTestProject. Все файлы, которые будет содержать эта папка, могут быть проиндексированы и в дальнейшем закоммичены в хранилище.

Примечание: Папка, в которую вы инициализируете Git, должна быть пуста на момент инициализации! Также убедитесь, что у вас в настройках проводника включен показ скрытых файлов.

Для закрепления полученных знаний настоятельно рекомендую создать еще один репозиторий-«песочницу» в который вы будете самостоятельно вносить изменения в следующих разделах туториала, опять же, для тренировки.

Настройка

Теперь, когда наш репозиторий инициализирован и готов к работе, давайте откроем графический интерфейс и посмотрим, что там есть интересного. Кликните ПКМ на пустой области папки и выберете пункт «Git Gui». Появится окно графического интерфейса Git.

Если вы хотите использовать терминал Git, выберете не Git Gui,
а Git Bash из списка.
Внешний вид консоли вы можете наблюдать выше.
Здесь: a. Имя пользователя; b. Рабочая область.
Проверьте, правильно ли установлен Git. Для этого введите команду
git —version
В случае правильной установки в окне консоли будет показана версия Git.
Также проверьте, правильно ли установлена рабочая область.
Путь b. должен указывать на папку с репозиторием. В противном случае
измените рабочую область командой
cd D:/MyTestProject

Далее мы более подробно разберем, для чего нужна каждая из областей главного окна Git Gui, но для начала нужно настроить Git. Выберем пункт «Редактировать» в главном меню окна и кликнем на «Настройки…». В открывшемся меню нас интересуют только пункты «Имя пользователя» и «Адрес электронной почты».

Обратите внимание, что настройки разделены на две практически идентичные колонки: одна – настройки только для данного репозитория, другая – для всех репозиториев сразу. Рекомендуется заполнить указанные поля в обеих колонках, затем кликаем «Сохранить». После выполнения данных пунктов окно Git Gui можно временно свернуть.

Для настройки профиля пользователя через консоль используйте команды
git config —global user.name “имя_пользователя”
git config —global user.email адрес_почты
Параметр global означает, что настройка выполнится для всех
ваших репозиториев.

ПРОДОЛЖЕНИЕ

Что такое git gc и как он работает?

Команда git gc — это команда обслуживания репозитория. «Gc» означает сборку мусора. Выполнение git gc буквально говорит Git навести порядок в текущем репозитории. Сборка мусора — это концепция, которая происходит от интерпретируемых языков программирования, которые выполняют динамическое распределение памяти. Сборка мусора в интерпретируемых языках используется для восстановления памяти, которая стала недоступной для выполняющейся программы.

В репозиториях Git накапливается различный мусор. Один из видов мусора Git — это «осиротевшие» или недоступные коммиты. Коммиты Git могут стать недоступными при выполнении команд изменения истории, таких как git reset или git rebase . Чтобы сохранить историю и избежать потери данных, Git не удаляет отдельные коммиты. Отсоединенный коммит все еще может быть извлечен, выделен и исследован с помощью git log .

Помимо очистки отсоединенного коммита, git gc также выполняет сжатие сохраненных объектов Git, освобождая драгоценное дисковое пространство.Когда Git идентифицирует группу похожих объектов, он сжимает их в «упаковку». Пакеты похожи на zip-файлы объектов Git и находятся в каталоге ./git/objects/pack внутри репозитория.

Что на самом деле делает git gc?

Перед выполнением git gc сначала проверяет несколько значений git config . Эти значения помогут прояснить остальную часть ответственности git gc .

конфигурация git gc

Необязательная переменная, значение по умолчанию — 90 дней.Он используется для установки того, как долго должны храниться записи в журнале ссылок веток.

  gc.reflogExpireUnreachable  

Необязательная переменная, значение по умолчанию — 30 дней. Он используется для установки того, как долго должны храниться недоступные записи рефлога.

Необязательная переменная, значение по умолчанию которой равно 250. Она контролирует, сколько времени тратится на фазу дельта-сжатия упаковки объектов, когда git gc выполняется с параметром --aggressive .

Необязательная переменная, значение по умолчанию — 50.Он контролирует глубину сжатия git-repack , которое использует во время выполнения git gc --aggresive

Необязательная переменная, значение по умолчанию — «2 недели назад». Устанавливает, как долго будет храниться недоступный объект перед обрезкой

Необязательная переменная, значение по умолчанию — «3 месяца назад». Он устанавливает, как долго устаревшее рабочее дерево будет храниться перед удалением.

выполнение git gc

За кулисами git gc фактически выполняет набор других внутренних подкоманд, таких как git prune , git repack , git pack и git rerere .Эти команды отвечают за определение любых объектов Git, выходящих за пределы пороговых уровней, установленных в конфигурации git gc . После идентификации эти объекты затем сжимаются или удаляются соответственно.

git gc лучшие практики и часто задаваемые вопросы

Сборка мусора запускается автоматически для нескольких часто используемых команд:

Частота, с которой git gc должно выполняться вручную, соответствует уровню активности репозитория.Репозиторий с одним участвующим разработчиком должен будет выполнять git gc гораздо реже, чем часто обновляемый многопользовательский репозиторий.

git gc против git prune

git gc — родительская команда, а git prune — дочерняя. git gc будет внутренне запускать git prune . git prune используется для удаления объектов Git, которые были признаны недоступными конфигурацией git gc . Узнайте больше о git prune .

Что такое агрессивный git gc?

git gc можно вызвать с параметром командной строки --aggressive . Параметр --aggressive заставляет git gc тратить больше времени на оптимизацию. Из-за этого git gc будет работать медленнее, но после его завершения сэкономит больше места на диске. Эффекты --aggressive постоянны, и их нужно запускать только после большого объема изменений в репозитории.

Что такое git gc auto?

Вариант команды git gc --auto сначала проверяет, требуется ли какое-либо обслуживание репо перед выполнением.Если он обнаруживает, что уборка не нужна, он выходит, не выполняя никаких действий. Некоторые команды Git неявно запускают git gc --auto после выполнения для очистки всех созданных ими незакрепленных объектов.

Перед выполнением git gc --auto проверит конфигурацию git на предмет пороговых значений для свободных объектов и размера сжатия упаковки. Эти значения можно установить с помощью git config . Если репозиторий превышает какой-либо из пороговых значений, будет выполнено git gc --auto .

Начало работы с git gc

Вы, вероятно, уже используете git gc , не замечая этого. Как обсуждалось в разделе лучших практик, он автоматически вызывается через часто используемые команды. Если вы хотите вызвать его вручную, просто выполните git gc , и вы должны увидеть вывод, показывающий выполненную работу.

Глава — 2 Что такое КОНТРОЛЬ ВЕРСИИ «GIT» И ОСНОВЫ GIT.

Презентация на тему: «Глава — 2 Что такое КОНТРОЛЬ ВЕРСИИ« GIT »И ОСНОВЫ GIT.»- стенограмма презентации:

1

Глава — 2 Что такое КОНТРОЛЬ ВЕРСИИ GIT И ОСНОВЫ GIT

2

Контроль версий: что это такое? Система контроля версий (также известная как система контроля версий) — это хранилище файлов, часто файлов исходного кода компьютерных программ, с контролируемым доступом.Отслеживается каждое изменение, внесенное в источник, вместе с тем, кто внес это изменение, почему они это сделали, а также ссылки на исправленные проблемы или улучшения, внесенные в результате изменения. Репозиторий В основе системы контроля версий лежит репозиторий, который является центральным хранилищем данных этой системы. Репозиторий обычно хранит информацию в виде дерева файловой системы — иерархии файлов и каталогов. Любое количество клиентов подключается к репозиторию, а затем читает или записывает в эти файлы. Записывая данные, клиент делает информацию доступной для других; читая данные, клиент получает информацию от других

3

Рабочая копия Ценность системы контроля версий заключается в том, что она отслеживает версии файлов и каталогов, но остальная часть программного обеспечения не работает с «версиями файлов и каталогов».Большинство программ понимают, как работать только с одной версией файла определенного типа. Итак, как пользователь системы управления версиями взаимодействует с абстрактным — а зачастую и удаленным — репозиторием, заполненным несколькими версиями различных файлов, конкретным образом? Каким образом его или ее программное обеспечение для обработки текстов, программное обеспечение для презентаций, редактор исходного кода, программное обеспечение для веб-дизайна или какая-либо другая программа — все они торгуются в валюте простых файлов данных — получают доступ к таким файлам? Ответ находится в конструкции управления версиями, известной как рабочая копия.Рабочая копия — это буквально локальная копия определенной версии данных пользователя, управляемых VCS, с которой этот пользователь может работать. Рабочие копии выглядят для другого программного обеспечения так же, как и любой другой локальный каталог, заполненный файлами, поэтому эти программы не должны «поддерживать контроль версий» для чтения и записи в эти данные. Задача управления рабочей копией и передачи изменений, внесенных в ее содержимое, в репозиторий и из него полностью ложится на клиентское программное обеспечение системы контроля версий.

4

GIT — ОСНОВЫ ПОНИМАНИЯ GIT (СИСТЕМА УПРАВЛЕНИЯ ВЕРСИЯМИ)

5

Вкратце о GIT Вся идея GIT состоит в том, чтобы сделать снимок вашего проекта через разные промежутки времени, чтобы в случае чего-то не так можно было восстановить состояние проекта в определенное время в прошлом. Git также полезен в ситуациях, когда два человека редактируют один и тот же файл.Они могут извлечь один и тот же файл, отредактировать его, зафиксировать изменения и затем отправить его на удаленный сервер. Теперь, если они используют FTP, они могут перезаписать изменения друг друга. Но если они используют Git, он попытается объединить эти изменения.

6

GIT делает снимки. Основное различие между Git и любой другой VCS (включая Subversion и друзей) — это то, как Git думает о своих данных. По идее, большинство других систем хранят информацию в виде списка файловых изменений.Эти системы (CVS, Subversion, Perforce, Bazaar и т. Д.) Рассматривают информацию, которую они хранят, как набор файлов и изменения, вносимые в каждый файл с течением времени, как показано на рисунке.

7

Каждый раз, когда вы фиксируете или сохраняете состояние вашего проекта в Git, он в основном делает снимок того, как все ваши файлы выглядят в данный момент, и сохраняет ссылку на этот снимок. Для большей эффективности, если файлы не изменились, Git не сохраняет файл снова — просто ссылка на предыдущий идентичный файл, который он уже сохранил.

8

Некоторые основные моменты о GIT  Почти каждая операция является локальной: для большинства операций в Git для работы требуются только локальные файлы и ресурсы — как правило, информация с другого компьютера в вашей сети не требуется. Этот аспект делает GIT очень быстрым. Поскольку у вас есть вся история проекта прямо на вашем локальном диске, большинство операций кажутся почти мгновенными  Git имеет целостность: все в Git проверяется перед сохранением, а затем на него ссылается эта контрольная сумма.Это означает, что невозможно изменить содержимое любого файла или каталога без ведома Git. Эта функциональность встроена в Git на самых низких уровнях и является неотъемлемой частью его философии. Вы не можете потерять информацию при передаче или получить повреждение файла, если Git не сможет это обнаружить.  Git обычно добавляет только данные: когда вы выполняете действия в Git, почти все они только добавляют данные в базу данных Git. Очень сложно заставить систему делать что-либо, что нельзя отменить, или каким-либо образом стереть данные.

9

Три состояния Git имеет три основных состояния, в которых могут находиться ваши файлы: зафиксировано, изменено и размещено.  Принято означает, что данные безопасно хранятся в вашей локальной базе данных.  Измененный означает, что вы изменили файл, но еще не зафиксировали его в своей базе данных.  Поэтапный означает, что вы пометили измененный файл в его текущей версии для использования в следующем снимке фиксации. Это приводит нас к трем основным разделам проекта Git: Каталог Git Рабочий каталог Промежуточная область.

Понимание Git (часть 1) — объясни, как будто я пятерка

Запутанный беспорядок веток. Фото Брэндона Грина.

→ Понимание Git (часть 1) — Объясни, как будто я пять
Понимание Git (часть 2) — Участие в команде
Понимание Git (часть 3) — Разрешение конфликтов (следите за обновлениями!)

Git — мощный инструмент , но он имеет репутацию непонятных новичков. Не помогает то, что большинство людей просто бросают на дно и ждут, что они будут плавать.

Обладая соответствующими знаниями, каждый может освоить git.Как только вы начнете понимать это, терминология станет более понятной, и вы (со временем) научитесь любить ее. Оставайся сильным 🙏

Зачем нужен еще один гид?

Уже существует множество «руководств по git», но большинство из них просто говорят вам копировать / вставлять определенные вещи для выполнения разовых задач. Любой, у кого есть клавиатура, может копировать / вставлять; Чтобы действительно понять, как работает git и что он может для вас сделать, вам нужно немного более глубокое понимание.

Они также склонны кидать в вас словарный запас, не объясняя, что эти слова на самом деле означают.

Это руководство призвано дать вам практическое понимание основных фраз и команд, которые вы будете часто использовать. Невозможно изучить такой мощный и сложный инструмент за один присест, поэтому я призываю вас не торопиться и наслаждаться путешествием.

Что такое git?

Прежде всего, GitHub — это , а не git. Многие люди по понятным причинам путают их. GitHub — это веб-сайт для размещения проектов, которые используют git.

Git — это тип системы управления версиями (VCS), которая упрощает отслеживание изменений в файлах.Например, когда вы редактируете файл, git может помочь вам точно определить , что изменило , , кто, , изменил его, и , почему .

Это полезно для координации работы нескольких людей над проектом, а также для отслеживания прогресса с течением времени путем сохранения «контрольных точек». Вы можете использовать его при написании эссе или для отслеживания изменений в графических изображениях и файлах дизайна.

Git — не единственная существующая система контроля версий, но она, безусловно, самая популярная. Многие разработчики программного обеспечения используют git ежедневно, и понимание того, как им пользоваться, может существенно улучшить ваше резюме.

В сложных проектах, где несколько человек могут одновременно вносить изменения в одни и те же файлы, легко попасть в странное состояние. Это может подтвердить любой, кто имел дело с «конфликтами слияния» и сбивающими с толку >>>>>>> ======= <<<<<<< символов.

Если вы начнете понимать, как работает git, вы поймете, почему возникают конфликты и как легко выходить из этих ситуаций.

Как получить git

Git устанавливается по умолчанию во многих системах.Если у вас его еще нет:

• Вы можете загрузить интерфейс командной строки (CLI) git здесь. Я рекомендовал это как новичкам, так и опытным пользователям.
• Если вы предпочитаете вместо этого использовать модный графический интерфейс пользователя (GUI), попробуйте GitHub Desktop (для Windows и Mac). Так будет проще использовать, но будет сложнее увидеть, что происходит.

Во всех примерах ниже предполагается, что вы используете интерфейс командной строки.

ℹ️ Для использования интерфейса командной строки введите терминал .Если вы не знакомы с терминалами, ничего страшного - сначала попробуйте это (или поищите помощь в Google).

Общие команды

Ниже приводится серия основных команд с описанием того, что каждая из них делает. Этот раздел предназначен для интерактивного использования. Пока вы читаете, не стесняйтесь попробовать сами команды, прежде чем двигаться дальше. В конце также будет «реальный» пример со списком команд, который вы можете попробовать все сразу.

Примечания:

• Любой жаргон будет выделен жирным шрифтом при первом описании.Не стесняйтесь искать эти термины в официальном глоссарии git или справочном руководстве для получения более подробной информации.
• Это упрощенное руководство. Он пытается быть максимально точным, избегая при этом некоторых беспорядочных деталей. В конце есть ссылки для более подробной информации.
• ✨ В описаниях будут новые идеи, поэтому обязательно продолжайте читать.

Вот некоторые из наиболее распространенных команд, примерно в том порядке, в котором вы их будете встречать:

Запустить собственное хранилище с нуля (в любой существующей папке на вашем компьютере):

Это создаст скрытый .Папка git внутри вашей текущей папки - это «репозиторий» (или репо ), где git хранит все свои внутренние данные отслеживания. Любые изменения, внесенные вами в любые файлы в исходной папке, теперь можно будет отслеживать.

✨ Исходная папка теперь называется вашим рабочим каталогом , в отличие от репозитория (папка .git ), который отслеживает ваши изменения. У вас работает в рабочем каталоге. Просто!

Клонировать существующее репо:

Будет загружен файл .git из Интернета (GitHub) на ваш компьютер и извлеките последний снимок репозитория (все файлы) в свой рабочий каталог. По умолчанию все это будет сохранено в папке с тем же именем, что и репо (в данном случае emoji-commit-messages ).

✨ Указанный здесь URL-адрес называется удаленным источником (место, откуда были загружены файлы происхождения ). Этот термин будет использоваться позже.

Просмотр текущего статуса вашего проекта:

Будет напечатана некоторая основная информация, например, какие файлы были недавно изменены.

Вы должны проверять свой статус каждый раз, когда что-то не понимаете. Git напечатает дополнительную информацию в зависимости от того, что происходит в данный момент, чтобы помочь вам.

Создайте новую ветку имя:

 git branch  

Вы можете думать об этом как о создании локальной «контрольной точки» (технически называемой ссылкой ) и присвоении ей имени. Это похоже на выполнение команды File> Save as… в текстовом редакторе; новая создаваемая ветка является ссылкой на текущее состояние вашего репо.Как вы скоро увидите, имя ветки можно будет использовать в других командах.

Подобно ветвлению, чаще вы сохраняете каждую контрольную точку по мере продвижения в виде коммитов (см. git commit в ближайшее время).

Коммиты - это особый тип контрольной точки, называемый ревизией . Имя будет представлять собой случайный хэш цифр и букв, например e093542 . Затем этот хеш можно использовать в различных других командах, например в именах веток.

✨ Это действительно основная функция git: сохранять контрольные точки (версии) и делиться ими с другими людьми. Все вращается вокруг этой концепции.

Если вы когда-либо создавали контрольную точку для чего-либо, вы сможете вернуться к ней позже, если ваша папка .git не повреждена. Это волшебно. См. git reflog , если вы хотите узнать больше.

Ветвление - огромная и сложная тема. Я скоро напишу об этом подробнее; а пока вы можете прочитать здесь больше, если хотите.

Извлечь из конкретной ветки:

 git checkout  

Вы можете думать об этом как о «возобновлении» с существующей контрольной точки. Все ваши файлы будут сброшены в то состояние, в котором они находились в этой конкретной ветке.

⚠️ Имейте в виду, что любые изменения в вашем рабочем каталоге будут сохраняться. См. git stash , если вас интересует простой способ избежать головной боли.

😎 Вы можете использовать флаг -b как ярлык для создать новую ветку, а затем проверить ее за один шаг.Это довольно часто:

 git checkout -b  

Просмотр различий между контрольными точками:

 git diff   

После редактирования некоторых файлов , вы можете просто ввести git diff , чтобы просмотреть список внесенных вами изменений. Это хороший способ перепроверить свою работу перед ее фиксацией.

Для каждой группы изменений вы увидите, как файл , использовавшийся до , выглядел (с префиксом – и окрашен в красный цвет), а затем то, как он выглядит сейчас (с префиксом + и окрашен в зеленый цвет).

Более сложные примеры этой команды см. Ниже.

Этап ваши изменения для подготовки к их фиксации:

После редактирования некоторых файлов эта команда пометит все внесенные вами изменения как «подготовленные» (или «готовые к фиксации»).

⚠️ Если вы затем пойдете и внесете больше изменений, эти новые изменения будут автоматически размещены , а не , даже если вы изменили те же файлы, что и раньше. Это полезно для точного контроля того, что вы делаете, но также является серьезным источником путаницы для новичков.

Если вы не уверены, просто введите git status еще раз, чтобы узнать, что происходит. Вы увидите сообщение «Изменения, которые необходимо зафиксировать:», а затем имена файлов, отмеченные зеленым цветом. Ниже вы увидите сообщение «Изменения, не предназначенные для фиксации:», а затем имена файлов, выделенные красным. Они еще не поставлены.

😎 В качестве ярлыка можно использовать подстановочные знаки , как и любую другую команду терминала. Например:

 git add README.md app / *. Txt 

Это добавит файл README.md , а также все файлы в папке app , которые заканчиваются на .txt . Обычно вы можете просто ввести git add --all , чтобы добавить все, что изменилось.

Зафиксируйте ваши поэтапные изменения:

Это откроет текстовый редактор командной строки по умолчанию и попросит вас ввести сообщение фиксации . Как только вы сохраните и выйдете, ваша фиксация будет сохранена локально.

Сообщение о фиксации важно, чтобы помочь другим людям понять, что было изменено и почему вы это изменили. Здесь есть краткое руководство, объясняющее, как писать полезные сообщения о фиксации.

😎 Вы можете использовать флаг -m как ярлык для написания сообщения. Например:

 git commit -m «Добавить новую функцию» 

Нажмите на свою ветку, чтобы загрузить ее в другое место:

 git push origin <имя-ветки> 

Это загрузит вашу ветку на удаленный с именем origin (помните, что это URL-адрес, изначально определенный во время клона ).

После успешного push ваши товарищи по команде смогут потянуть вашу ветку для просмотра ваших коммитов (см. git pull ниже).

😎 В качестве ярлыка вы можете ввести слово HEAD вместо имя-ветки , чтобы автоматически использовать ветку, в которой вы находитесь. HEAD всегда относится к вашей последней контрольной точке, то есть последней фиксации в вашей текущей ветке.

✨ Как упоминалось ранее, все в git можно рассматривать как контрольную точку. Вот список типов контрольных точек, о которых вы знаете сейчас (опять же, они технически называются «ссылками» и «исправлениями»):

• HEAD
• , e., ~ и @ {} можно использовать для изменения ссылок. Они весьма полезны; узнать больше здесь.

  Получить последнюю информацию о репо:

  Это загрузит последнюю информацию о репо из origin (например, все различные ветки, хранящиеся на GitHub).

  Он не изменяет ни один из ваших локальных файлов — просто обновляет данные отслеживания, хранящиеся в папке .git .

  Объединить с изменениями от кого-то еще:

   git merge  

  Это примет все коммиты, существующие в ветке other-branch-name , и интегрирует их в вашу текущую ветку.

  ⚠️ При этом используются все данные ветки, хранящиеся локально, поэтому убедитесь, что вы сначала запустили git fetch , чтобы загрузить самую свежую информацию.

  Например, если кто-то еще добавляет несколько коммитов в ветку master из origin , вы можете сделать следующее, чтобы загрузить их изменения и обновить свою локальную ветку master :

   git checkout master # Убедитесь, что ты на правильной ветке. 
   git fetch # Загрузить любую новую информацию из origin.
   git merge origin / master # Слить ветку origin / master 
   с вашей текущей веткой. 

  ✨ Имя origin / master здесь буквально означает контрольную точку origin / master на вашем компьютере. Git использует эту нотацию для различения ветвей с одним и тем же именем (например, master ), расположенных в разных местах (например, ваши собственные ветки и origin ).

  😎 В качестве ярлыка вы можете использовать команду pull для fetch и merge все за один шаг.Это чаще, чем слияние вручную, как указано выше:

  Здесь мы разделяем слова origin и master (без косой черты, как указано выше). Мы не хотим использовать контрольную точку origin / master на нашем собственном компьютере, потому что она хранится в автономном режиме и, вероятно, устарела. Вместо этого мы хотим получить данные напрямую из ветки master удаленной конечной точки с именем origin . Не спускайте глаз; разница важна!

  Для более глубокого понимания того, как работает слияние и как разрешаются конфликты (с забавными изображениями и графиками), см. Официальную документацию по слиянию.Это также будет подробно рассмотрено в части 3 этой серии.

  Пример из реальной жизни

  Вот серия команд, которые гипотетически могут быть выполнены при разработке реальной функции. Посмотрите, сможете ли вы выяснить, что они будут делать каждый, а затем попробуйте сами и проверьте.

   git clone https://github.com/cooperka/emoji-commit-messages.git 
   cd emoji-commit-messages 
   git status 
   git checkout -b my-new-feature 
   echo «Это классный новый файл »> Мой файл.txt 
   git status 
   git add --all 
   git status 
   git diff HEAD 
   git commit -m «Добавить my-file.txt» 
   git status 
   git log 
   git push origin HEAD 
   git checkout master 
   git pull 

  У большинства этих команд есть дополнительные параметры, которые вы можете передать для их настройки, и сокращенные версии для краткости, которые делают все более интересным (читай: сбивает с толку). Обычно есть несколько способов выполнить данную задачу.

  No related posts.