How to use git on windows

How to install and use Git on Windows

By default, Git is installed on Linux and macOS computers as a command line option. However, Microsoft Windows does not include a Git command. Below are the steps on how to install and use Git and GitHub on Microsoft Windows.

Installing Git on Windows

Open the Git website.
Click the Download link to download Git. The download should automatically start.
Once downloaded, start the installation from the browser or the download folder.
In the Select Components window, leave all default options checked and check any other additional components you want installed.
Next, in the Choosing the default editor, used by Git unless you’re familiar with Vim we highly recommend using a text editor you’re comfortable using. If Notepad++ is installed, we suggest using it as your editor. If Notepad++ is not installed, you can cancel the install and install Notepad++ and then restart the GitHub install.
Next, in the Adjusting your PATH environment, we recommend keeping the default Use Git from the command line and also from 3rd-party software as shown below. This option allows you to use Git from either Git Bash or the Windows Command Prompt.

Next in the, we recommend leaving the default selected as Use OpenSSH.
Next, in Choosing HTTPS transport backend, leave the default Use the OpenSSL library selected.
In the Configuring the line ending conversions, select Checkout Windows-style, commit Unix-style line endings unless you need other line endings for your work.
In the Configuring the terminal emulator to use with Git Bash window, select Use MinTTY (the default terminal of MSYS2).
On the Configuring extra options window, leave the default options checked unless you need symbolic links.
Click the Install button
Once completed, you can check the option to Launch Git Bash if you want to open a Bash command line or, if you selected the Windows command line, run Git from the Windows command line.

We highly recommend you use Git from the command line and not use a GUI interface. You’ll only be using the command line to interface with Git to manage the files. Editing can still be done through a text editor or IDE of your choice. If you’re new to the command line, you can find help with navigating the Windows command line and Linux (Bash) through the links below.

Configuring and connecting to a remote repository

In our example, we’re using GitHub as a storage for our remote repository. Below are the steps on how you can connect to a GitHub repository. If you are new to GitHub, see: How to create a GitHub repository.

From the command line, move to the directory you want to contain your Git repository.

How to change a directory or open a folder.

Type the following command to configure your Git username, where will be your GitHub username.

After entering the above command, you’ll be returned to the command prompt. Next, enter your e-mail address by typing the following command, where is your e-mail address.

Once the above steps are completed, you’ll be ready to connect to a remote repository. To find the repository address, go to a repository on GitHub and click the Clone or download repository link to get the address. For example, we’ve created a repository called «example» at https://github.com/Computerhope/example.git address. Copy the address to your clipboard.
Once copied go back to the command line and type the following command, where is the address you copied. To paste that address into the command line right-click in the command line window and click paste.

Once the Git repository is created, you’ll have a new directory in your current directory with the name of the Git repository.
Once the Git remote repository is cloned to your local repository, a new folder in the current directory should appear with the name of the Git repository. For example, in our «example» Git we would have a new directory called «example». Use the cd command to change into the new directory.
Once in the new directory, type the following command to list the remote repositories.

If successful, the output is «origin,» which is a special name that refers to the remote repository.
To see the aliases (URL or path), type the following command.

Running each of the above commands give you an output similar to what is shown in our example below.

Now that you’ve connected to a remote repository on GitHub you’re ready to start working on the files and pushing and pulling files as you update the files.

Working in your local repository and pushing files

After following the above steps and cloning a remote repository, you can work on the files as you normally would. You can create new files or edit existing files from the command line or your favorite text editor. Below, are the steps of creating a new file, pushing that file, editing an existing file, and pushing the update.

Creating a new file and pushing to remote repository

Create a new file in the Git directory by typing the following command from either the Bash or Windows command line. The following command opens and creates a file called example.txt in Notepad. In Git Bash, you could also use the touch command to create a blank new file and then type «start » to open the file in your favorite text editor.

In the text editor, enter some text into the file and save and exit the file.
Back at the command line type the following command to get the current status of your branch and untracked files.

Git displays a window similar to the example shown below, showing that the file we created is new and untracked by Git.

We’ll now want to add this file to Git to be tracked by typing the following command. If your file is not named «example.txt,» you’d want to change the text to the name of your file.

After entering the above command, the file is added as a new file also known as staging. Typing git status again shows you in green that the file is a new file that is ready to be committed.
Next, type the following command to commit the changes made in the local workspace to the local repository. In the example below, our notes «First example» should be notes that would make sense everyone working on your project.

You can also type git commit with no additional tags or options. However, when doing this it opens a vim like editor that can be difficult for those not familiar with the vim to use. If you type this command press «i» to enter insert mode and type the notes for the commit on the first line, press Esc, and then type «:wq» to save, exit, and commit. We suggest using the above command because it’s easier for more people to use.

Finally, now that changes are moved from your workspace into your local repository it’s ready to be pushed to the remote repository. Type the following command to push all changes to the remote repository.

If you want to follow the progress, you can type git status again to see the current status. You can also type git log to see a log of changes.

You’ll be asked for your GitHub username and password if your computer has not logged in to Git from the command line.

Once the file is pushed, it appears in your GitHub remote repository and is available to everyone else who’re working with the same repository.

Modifying a file and pushing to remote repository

Edit and modify one or more files in your Git.
Type git status to see the status of all the files not yet committed from the workspace to the local repository.
Type the following command to add all files. The single period indicates that you want all files to be added to the local repository. Some people may also use git add -A to add all.

You can also use wildcards instead of a period. For example, if you wanted to add all text files you could type *.txt instead of a single period to only add text files.

Once the files are added, type the following command to commit. Change the notes to apply to your commit.

Finally, type git push to push the commit to the remote repository.

If you’re working with a lot of other people, we’d recommend you pull (explained below) before committing. If your local repository is not the same as the remote repository (excluding your new changes), the commit fails. For example, if someone has added new files to the remote repository while you’ve been working and you try commit, it fails until you pull.

Pulling or fetching updates from the remote repository

If it’s been awhile since you’ve committed any work, perform the git pull command to get the latest updates from the remote repository and merge them into your local repository. By pulling updates from a repository before committing, it verifies your local repository and the remote repository are the same and prevents merge conflicts.

To get all changes without merging, run the git fetch command to grab all of the latest updates from the remote repository without merging changes.

How to deal with a Git merge conflict

When multiple people are working with the same files, you’re going to encounter merge conflicts. When a conflict occurs, Git modifies your local files and it is up to you to manually fix the files with the conflicts.

Use the git status command to see the status and merge conflict information.

Open the file with the conflict to start correcting the errors. In the example file below, we had a text file with one line of text and in the local repository we added the text «update1» to the file. However, during the same time, the remote repository file was modified and added «update2″ to the file on the same line. Git marks conflicts with » >>>>>> » to mark the end.

To resolve this merge conflict, we would need to decide what text we wanted to keep, update, or remove. In this example, we want to keep «update1» and «update2» in the order they’re listed so we would only need to remove the Git markings to make the file resemble the following example.

If you’re working with a big file, it’s a good idea to search the file for «HEAD» because there may be more than one conflict.

Once the changes are made in the file, we could save the file and then perform the following git commands to update the fixes.

The example given in this merge conflict is a very basic example. When dealing with a file with more than a few lines of text or big sections of code, merge conflict can get a lot more confusing. To make it easier to deal with merge conflicts, you can use the command git mergetool to use a merge tool, such as WinMerge or another popular merge tool.

Creating a Git branch

Creating a branch allows you to create a duplicate of the master (trunk) and make several updates without affecting the master. For example, when developing a program if a big fix was need that could take weeks or months, a branch could be created for that fix. Once you’ve fixed the bug, you could merge your branch back into the master.

To create a branch in your local repository, follow the steps below.

In the Git master directory, type the following command, where » » is the name of the new branch name. For example, we could call the branch «examplebranch».

Next, type the following command to switch to the branch.

After entering the above command, the prompt (in Git Bash) changes from «master» to the branch name to indicate you’re working in a branch.
From this point, you can continue to use Git and modify the files how you have in the past.
To see all available branches, you can use the git branch command. For example, typing git branch displays your local repository branches. Typing git branch -a displays all local and remote repositories.
If you need to push the branch to the remote repository, you can run the following command.

Finally, if you need to switch back to the master branch, you can type the following command.

How to merge a branch back into the master

After completing your work, you’ll want to merge it back into the master or another branch by following the steps below.

Move into the branch you want to merge into. For example, if you wanted to merge back into the master, type the following command.

Once in the master, type the following command to merge the branch.

Once the merge is performed, add the files.
Next, commit the changes.
Once merged and committed, push the merge by typing the following command. If you get conflicts during the merge, see our how to deal with merge conflicts section.

How to delete a local and remote branch

If, after merging a branch you no longer want to keep the local or remote branch, you can perform the following commands.

To delete the local branch, type the following command.

To delete the remote branch, type the following command.

Источник

Git за полчаса: руководство для начинающих

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

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

Основы

Git — это набор консольных утилит, которые отслеживают и фиксируют изменения в файлах (чаще всего речь идет об исходном коде программ, но вы можете использовать его для любых файлов на ваш вкус). С его помощью вы можете откатиться на более старую версию вашего проекта, сравнивать, анализировать, сливать изменения и многое другое. Этот процесс называется контролем версий. Существуют различные системы для контроля версий. Вы, возможно, о них слышали: SVN, Mercurial, Perforce, CVS, Bitkeeper и другие.

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

Установка

Установить git на свою машину очень просто:

Linux — нужно просто открыть терминал и установить приложение при помощи пакетного менеджера вашего дистрибутива. Для Ubuntu команда будет выглядеть следующим образом:

sudo apt-get install git

Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.
OS X — проще всего воспользоваться homebrew. После его установки запустите в терминале:

Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.

Настройка

Итак, мы установили git, теперь нужно добавить немного настроек. Есть довольно много опций, с которыми можно играть, но мы настроим самые важные: наше имя пользователя и адрес электронной почты. Откройте терминал и запустите команды:

git config —global user.name «My Name»

git config —global user.email myEmail@example.com

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

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

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

Создайте на рабочем столе папку под названием git_exercise. Для этого в окне терминала введите:

$ mkdir Desktop/git_exercise/
$ cd Desktop/git_exercise/
$ git init

Командная строка должна вернуть что-то вроде:

Initialized empty Git repository in /home/user/Desktop/git_exercise/.git/

Это значит, что наш репозиторий был успешно создан, но пока что пуст. Теперь создайте текстовый файл под названием hello.txt и сохраните его в директории git_exercise.

Определение состояния

status — это еще одна важнейшая команда, которая показывает информацию о текущем состоянии репозитория: актуальна ли информация на нём, нет ли чего-то нового, что поменялось, и так далее. Запуск git status на нашем свежесозданном репозитории должен выдать:

$ git status
On branch master
Initial commit
Untracked files:
(use «git add . » to include in what will be committed)
hello.txt

Сообщение говорит о том, что файл hello.txt неотслеживаемый. Это значит, что файл новый и система еще не знает, нужно ли следить за изменениями в файле или его можно просто игнорировать. Для того, чтобы начать отслеживать новый файл, нужно его специальным образом объявить.

Подготовка файлов

В git есть концепция области подготовленных файлов. Можно представить ее как холст, на который наносят изменения, которые нужны в коммите. Сперва он пустой, но затем мы добавляем на него файлы (или части файлов, или даже одиночные строчки) командой add и, наконец, коммитим все нужное в репозиторий (создаем слепок нужного нам состояния) командой commit.
В нашем случае у нас только один файл, так что добавим его:

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

Проверим статус снова, на этот раз мы должны получить другой ответ:

$ git status
On branch master
Initial commit
Changes to be committed:
(use «git rm —cached . » to unstage)
new file: hello.txt

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

Коммит(фиксация изменений)

Коммит представляет собой состояние репозитория в определенный момент времени. Это похоже на снапшот, к которому мы можем вернуться и увидеть состояние объектов на определенный момент времени.
Чтобы зафиксировать изменения, нам нужно хотя бы одно изменение в области подготовки (мы только что создали его при помощи git add), после которого мы может коммитить:

$ git commit -m «Initial commit.»

Эта команда создаст новый коммит со всеми изменениями из области подготовки (добавление файла hello.txt). Ключ -m и сообщение «Initial commit.» — это созданное пользователем описание всех изменений, включенных в коммит. Считается хорошей практикой делать коммиты часто и всегда писать содержательные комментарии.

Удаленные репозитории

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

1. Подключение к удаленному репозиторию

Чтобы загрузить что-нибудь в удаленный репозиторий, сначала нужно к нему подключиться. В нашем руководстве мы будем использовать адрес https://github.com/tutorialzine/awesome-project, но вам посоветуем попробовать создать свой репозиторий в GitHub, BitBucket или любом другом сервисе. Регистрация и установка может занять время, но все подобные сервисы предоставляют хорошую документацию.

Чтобы связать наш локальный репозиторий с репозиторием на GitHub, выполним следующую команду в терминале. Обратите внимание, что нужно обязательно изменить URI репозитория на свой.

# This is only an example. Replace the URI with your own repository address.
$ git remote add origin https://github.com/tutorialzine/awesome-project.git

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

2. Отправка изменений на сервер

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

Команда, предназначенная для этого — push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).

$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 212 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/tutorialzine/awesome-project.git
* [new branch] master -> master

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

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

Сейчас другие пользователи GitHub могут просматривать ваш репозиторий. Они могут скачать из него данные и получить полностью работоспособную копию вашего проекта при помощи команды clone.

$ git clone https://github.com/tutorialzine/awesome-project.git

Новый локальный репозиторий создается автоматически с GitHub в качестве удаленного репозитория.

4. Запрос изменений с сервера

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

$ git pull origin master
From https://github.com/tutorialzine/awesome-project
* branch master -> FETCH_HEAD
Already up-to-date.

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

Ветвление

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

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

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

1. Создание новой ветки

Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch

$ git branch amazing_new_feature

Это создаст новую ветку, пока что точную копию ветки master.

2. Переключение между ветками

Сейчас, если мы запустим branch, мы увидим две доступные опции:

$ git branch
amazing_new_feature
* master

master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.

$ git checkout amazing_new_feature

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

Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:

$ git add feature.txt
$ git commit -m «New feature complete.”

Изменения завершены, теперь мы можем переключиться обратно на ветку master.

$ git checkout master

Теперь, если мы откроем наш проект в файловом менеджере, мы не увидим файла feature.txt, потому что мы переключились обратно на ветку master, в которой такого файла не существует. Чтобы он появился, нужно воспользоваться merge для объединения веток (применения изменений из ветки amazing_new_feature к основной версии проекта).

$ git merge amazing_new_feature

Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.

$ git branch -d awesome_new_feature

Дополнительно

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

1. Отслеживание изменений, сделанных в коммитах

У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:

$ git log
commit ba25c0ff30e1b2f0259157b42b9f8f5d174d80d7
Author: Tutorialzine
Date: Mon May 30 17:15:28 2016 +0300
New feature complete
commit b10cc1238e355c02a044ef9f9860811ff605c9b4
Author: Tutorialzine
Date: Mon May 30 16:30:04 2016 +0300
Added content to hello.txt
commit 09bd8cc171d7084e78e4d118a2346b7487dca059
Author: Tutorialzine
Date: Sat May 28 17:52:14 2016 +0300
Initial commit

Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]

$ git show b10cc123
commit b10cc1238e355c02a044ef9f9860811ff605c9b4
Author: Tutorialzine
Date: Mon May 30 16:30:04 2016 +0300
Added content to hello.txt
diff —git a/hello.txt b/hello.txt
index e69de29..b546a21 100644
— a/hello.txt
+++ b/hello.txt
@@ -0,0 +1 @@
+Nice weather today, isn’t it?

$ git diff 09bd8cc..ba25c0ff
diff —git a/feature.txt b/feature.txt
new file mode 100644
index 0000000..e69de29
diff —git a/hello.txt b/hello.txt
index e69de29..b546a21 100644
— a/hello.txt
+++ b/hello.txt
@@ -0,0 +1 @@
+Nice weather today, isn’t it?

2. Возвращение файла к предыдущему состоянию

Гит позволяет вернуть выбранный файл к состоянию на момент определенного коммита. Это делается уже знакомой нам командой checkout, которую мы ранее использовали для переключения между ветками. Но она также может быть использована для переключения между коммитами (это довольно распространенная ситуация для Гита — использование одной команды для различных, на первый взгляд, слабо связанных задач).
В следующем примере мы возьмем файл hello.txt и откатим все изменения, совершенные над ним к первому коммиту. Чтобы сделать это, мы подставим в команду идентификатор нужного коммита, а также путь до файла:

$ git checkout 09bd8cc1 hello.txt

3. Исправление коммита

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

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

Самый последний коммит может быть доступен по алиасу HEAD:

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

$ git revert b10cc123

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

4. Разрешение конфликтов при слиянии

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

Джон использует цикл:

// Use a for loop to console.log contents.
for(var i=0; iconsole.log(arr[i]);
>

Тим предпочитает forEach:

// Use forEach to console.log contents.
arr.forEach(function(item) <
console.log(item);
>);

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

$ git merge tim_branch
Auto-merging print_array.js
CONFLICT (content): Merge conflict in print_array.js
Automatic merge failed; fix conflicts and then commit the result.

Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:

Над разделителем ======= мы видим последний (HEAD) коммит, а под ним — конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.

// Not using for loop or forEach.
// Use Array.toString() to console.log contents.
console.log(arr.toString());

Когда все готово, нужно закоммитить изменения, чтобы закончить процесс:

$ git add -A
$ git commit -m «Array printing conflict resolved.»

Как вы можете заметить, процесс довольно утомительный и может быть очень сложным в больших проектах. Многие разработчики предпочитают использовать для разрешения конфликтов клиенты с графическим интерфейсом. (Для запуска нужно набрать git mergetool).

5. Настройка .gitignore

В большинстве проектов есть файлы или целые директории, в которые мы не хотим (и, скорее всего, не захотим) коммитить. Мы можем удостовериться, что они случайно не попадут в git add -A при помощи файла .gitignore

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

Вот хорошие примеры файлов, которые нужно игнорировать:

Логи
Артефакты систем сборки
Папки node_modules в проектах node.js
Папки, созданные IDE, например, Netbeans или IntelliJ
Разнообразные заметки разработчика.

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

Символ слэша в конце некоторых линий означает директорию (и тот факт, что мы рекурсивно игнорируем все ее содержимое). Звездочка, как обычно, означает шаблон.

Заключение

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

Официальная документация, включающая книгу и видеоуроки – тут .
“Getting git right” – Коллекция руководств и статей от Atlassian – тут .
Список клиентов с графическим интерфейсом – тут .
Онлайн утилита для генерации .gitignore файлов – тут .