Examples of git init
vs
Starting a new project can be confusing. Sometimes, it’s unclear if you should use , , or both.
: One Person Starting a New Repository Locally
Your project may already exist locally, but it doesn’t have Git yet. is probably the right choice for you. This is only run once, even if other collaborators share the project.
- First, initialize the repository and make at least one commit.
- Once you have initialized the repository, create a remote repository somewhere like GitHub.com.
- Then, add the remote URL to your local git repository with . This stores the remote URL under a more human-friendly name, .
- Shape your history into at least one commit by using to stage the existing files, and to make the snapshot.
- Once you have at least one commit, you can push to the remote and set up the tracking relationship for good with .
: The Remote Already Exists
If the repository already exists on a remote, you would choose to and not .
If you create a remote repository first with the intent of moving your project to it later, you may have a few other steps to follow. If there are no commits in the remote repository, you can follow the steps above for . If there are commits and files in the remote repository but you would still like it to contain your project files, that repository. Then, move the project’s files into that cloned repository. , , and to create a history that makes sense for the beginning of your project. Then, your team can interact with the repository without again.
Existing Folder
The default behavior of is to transform the current directory into a Git repository. For an existing project to become a Git repository, navigate into the targeted root directory. Then, run .
Or, you can create a new repository in a directory in your current path. Use and specify which directory to turn into a Git repository.
Клонирование всех GitHub-репозиториев
Пояснение: вам нужен список GitHub-репозиториев для клонирования. Самое классное здесь то, что вы можете выделять только нужные вам репозитории, а не копировать все без разбора.
Чтобы клонировать GitHub-репозитории и не вводить каждый раз пароли, вам пригодится HTTPS с 15-минутным кэшированием учетных данных или мой любимый метод — подключение к GitHub через SSH. Для краткости мы воспользуемся вторым способом с уже настроенными SSH-ключами.
Например, вот в файле у нас есть такой список GitHub-адресов:
git@github.com:username/first-repository.gitgit@github.com:username/second-repository.gitgit@github.com:username/third-repository.git
Выполняем следующую команду:
xargs -n1 git clone < gh-repos.txt
Она клонирует все репозитории из списка в текущую папку. Если правильно указать URL, то этот же одностраничник будет работать и для GitLab.
docs book git push push your new branches and data to a remote repository
To share the cool commits you’ve done with others, you need to push your
changes to the remote repository. To do this, you run
which will attempt to make your
the new on the remote. Let’s try it by initially pushing
our ‘master’ branch to the new ‘github’ remote we created earlier.
$ git push github master Counting objects: 25, done. Delta compression using up to 2 threads. Compressing objects: 100% (25/25), done. Writing objects: 100% (25/25), 2.43 KiB, done. Total 25 (delta 4), reused 0 (delta 0) To git@github.com:schacon/hw.git * master -> master
Pretty easy. Now if someone clones that repository they will get exactly
what we have committed and all of its history.
What if you have a topic branch like the ‘erlang’ branch created earlier
and want to share just that? You can just push that branch instead.
$ git push github erlang Counting objects: 7, done. Delta compression using up to 2 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 652 bytes, done. Total 6 (delta 1), reused 0 (delta 0) To git@github.com:schacon/hw.git * erlang -> erlang
Now when people clone or fetch from that repository, they’ll get an ‘erlang’
branch they can look at and merge from. You can push any branch to any
remote repository that you have write access to in this way. If your branch
is already on the server, it will try to update it, if it is not, Git will
add it.
The last major issue you run into with pushing to remote branches is the
case of someone pushing in the meantime. If you and another developer clone
at the same time, you both do commits, then she pushes and then you try to
push, Git will by default not allow you to overwrite her changes. Instead,
it basically runs on the branch you’re trying to push and
makes sure it can see the current tip of the server’s branch in your push’s
history. If it can’t see what is on the server in your history, it concludes
that you are out of date and will reject your push. You will rightly have to
fetch, merge then push again — which makes sure you take her changes into
account.
This is what happens when you try to push a branch to a remote branch
that has been updated in the meantime:
$ git push github master To git@github.com:schacon/hw.git ! master -> master (non-fast-forward) error: failed to push some refs to 'git@github.com:schacon/hw.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details.
You can fix this by running
and then pushing again.
In a nutshell you run to update a
remote repository with the changes you’ve made locally. It will take what your
looks like and push it to be on the remote, if possible. If
someone else has pushed since you last fetched and merged, the Git server will
deny your push until you are up to date.
Общие сведения
Для участия в разработке документации на сайте Майкрософт вы можете локально создавать и редактировать файлы Markdown, клонировав соответствующий репозиторий документации. Чтобы получить разрешения Майкрософт на чтение и запись для соответствующего репозитория, нужно создать его вилку в учетной записи GitHub. Это позволит сохранять предлагаемые изменения. Затем изменения объединяются в центральном общем репозитории, доступном только для чтения, с помощью запросов на вытягивание.
Если вы раньше не работали с GitHub, посмотрите следующее видео, где представлен концептуальный обзор процесса создания вилок и клонирования репозиториев:
Создание локального клона
С помощью Git Bash подготовьтесь выполнить команду клонирования для вытягивания копии репозитории (вашей вилки) в текущий каталог на устройстве.
Проверка подлинности с использованием Git Credential Manager
Если вы установили последнюю версию Git для Windows и согласились на установку по умолчанию, будет по умолчанию активирован диспетчер учетных данных Git Credential Manager. Git Credential Manager упрощает проверку подлинности, избавляя от необходимости отзывать личный маркер доступа при повторной установке подключений с проверкой подлинности и удаленных подключений с GitHub.
-
Выполните команду клонирования, указав имя репозитория. Во время клонирования разветвленный репозиторий скачивается (клонируется) на локальный компьютер.
Совет
Чтобы получить URL-адрес своей вилки GitHub для команды клонирования, нажмите кнопку Clone or download (Клонировать или скачать) в пользовательском интерфейсе GitHub:
В процессе клонирования обязательно укажите путь к своей вилке, а не к главному репозиторию, из которого вы ее создали. В противном случае вы не сможете вносить изменения. Ссылки на вашу вилку осуществляются по имени вашей личной учетной записи GitHub, например .
Команда клонирования должна выглядеть приблизительно следующим образом.
-
При появлении запроса введите учетные данные GitHub.
-
При появлении запроса введите код двухфакторной проверки подлинности.
Примечание
Ваши учетные данные будут сохранены для проверки подлинности последующих запросов GitHub. Проверка подлинности выполняется на каждом компьютере один раз.
-
-
Запущенная команда клонирования скачивает копию файлов репозитория из вашей вилки в новую папку на локальном диске. Новая папка создается в текущей папке. В зависимости от размера репозитория этот процесс может занять несколько минут. По его окончании вы можете открыть папку, чтобы просмотреть ее структуру.
Examples of git clone
The most common usage of cloning is to simply clone a repository. This is only done once, when you begin working on a project, and would follow the syntax of .
A Branch
: By default, will create remote tracking branches for all of the branches currently present in the remote which is being cloned. The only local branch that is created is the default branch.
But, maybe for some reason you would like to only get a remote tracking branch for one specific branch, or clone one branch which isn’t the default branch. Both of these things happen when you use with .
This will create a clone that only has commits included in the current line of history. This means no other branches will be cloned. You can specify a certain branch to clone, but the default branch, usually , will be selected by default.
To clone one specific branch, use:
Cloning only one branch does not add any benefits unless the repository is very large and contains binary files that slow down the performance of the repository. The recommended solution is to optimize the performance of the repository before relying on single branch cloning strategies.
With SSH
Depending on how you authenticate with the remote server, you may choose to clone using SSH.
If you choose to clone with SSH, you would use a specific SSH path for the repository instead of a URL. Typically, developers are authenticated with SSH from the machine level. This means that you would probably clone with HTTPS or with SSH — not a mix of both for your repositories.
Настройка удаленного вышестоящего подключения
После клонирования репозитория следует установить удаленное подключение только для чтения, называемое вышестоящим, к основному репозиторию. С помощью URL-адреса вышестоящего подключения вы сможете обеспечить синхронизацию вашего локального репозитория с последними правками, внесенными другими участниками. Команда git remote служит для задания значения конфигурации. С помощью команды принесения можно обновить сведения о ветви из вышестоящего репозитория.
-
Если вы используете Git Credential Manager, выполните следующие команды. Замените заполнители <repo> и <organization> .
-
Просмотрите настроенные значения и проверьте правильность URL-адресов. Убедитесь, что URL-адреса исходного подключения ведут к вашей персональной вилке. Убедитесь, что URL-адреса вышестоящего подключения ведут к основному репозиторию, например MicrosoftDocs или Azure.
Далее приводится пример выходных данных для подключения к удаленному репозиторию. Здесь вымышленная учетная запись Git с именем MyGitAccount настраивается с личным маркером доступа для обращения к репозиторию azure-docs.
-
Если вы допустили ошибку, значение удаленного подключения можно очистить. Чтобы удалить значение вышестоящего подключения, выполните команду .
Установка Git
Прежде чем использовать Git, вы должны установить его на своём компьютере.
Даже если он уже установлен, наверное, это хороший повод, чтобы обновиться до последней версии.
Вы можете установить Git из собранного пакета или другого установщика, либо скачать исходный код и скомпилировать его самостоятельно.
| Примечание |
В этой книге используется Git версии 2.8.0. |
Установка в Linux
Если вы хотите установить Git под Linux как бинарный пакет, это можно сделать, используя обычный менеджер пакетов вашего дистрибутива.
Если у вас Fedora (или другой похожий дистрибутив, такой как RHEL или CentOS), можно воспользоваться :
Если же у вас дистрибутив, основанный на Debian, например, Ubuntu, попробуйте :
Чтобы воспользоваться дополнительными возможностями, посмотрите инструкцию по установке для нескольких различных разновидностей Unix на сайте Git https://git-scm.com/download/linux.
Установка на Mac
Существует несколько способов установки Git на Mac.
Самый простой — установить Xcode Command Line Tools.
В версии Mavericks (10.9) и выше вы можете добиться этого просто первый раз выполнив ‘git’ в терминале.
Если Git не установлен, вам будет предложено его установить.
Если Вы хотите получить более актуальную версию, то можете воспользоваться бинарным установщиком.
Установщик Git для OS X доступен для скачивания с сайта Git https://git-scm.com/download/mac.
Рисунок 7. OS X инсталлятор Git
Установка в Windows
Для установки Git в Windows также имеется несколько способов.
Официальная сборка доступна для скачивания на официальном сайте Git.
Просто перейдите на страницу https://git-scm.com/download/win, и загрузка запустится автоматически.
Обратите внимание, что это отдельный проект, называемый Git для Windows; для получения дополнительной информации о нём перейдите на https://gitforwindows.org. Для автоматической установки вы можете использовать пакет Git Chocolatey.
Обратите внимание, что пакет Chocolatey поддерживается сообществом
Для автоматической установки вы можете использовать пакет Git Chocolatey.
Обратите внимание, что пакет Chocolatey поддерживается сообществом
Установка из исходников
Многие предпочитают устанавливать Git из исходников, поскольку такой способ позволяет получить самую свежую версию.
Обновление бинарных инсталляторов, как правило, немного отстаёт, хотя в последнее время разница не столь существенна.
Если вы действительно хотите установить Git из исходников, у вас должны быть установлены следующие библиотеки, от которых он зависит: autotools, curl, zlib, openssl, expat, and libiconv.
Например, если в вашей системе используется (Fedora) или (системы на базе Debian), вы можете использовать одну из следующих команд для установки всех зависимостей, используемых для сборки и установки бинарных файлов Git:
Для того, чтобы собрать документацию в различных форматах (doc, html, info), понадобится установить дополнительные зависимости:
| Примечание |
Пользователи RHEL и производных от неё (таких как CentOS или Scientific Linux) должны для корректной установки пакета |
Если вы используете систему на базе Debian (Debian/Ubuntu/Ubuntu-производные), вам так же понадобится установить пакет :
Если вы используете систему на базе RPM (Fedora/RHEL/RHEL-производные), вам так же понадобится установить пакет , который уже установлен в системах на базе Debian:
К тому же из-за различий имён бинарных файлов вам понадобится сделать следующее:
Когда все необходимые зависимости установлены, вы можете пойти дальше и скачать самый свежий архив с исходниками из следующих мест:
с сайта Kernel.org https://www.kernel.org/pub/software/scm/git, или зеркала на сайте GitHub https://github.com/git/git/releases.
Конечно, немного проще скачать последнюю версию с сайта GitHub, но на странице kernel.org релизы имеют подписи, если вы хотите проверить, что скачиваете.
Затем скомпилируйте и установите:
После этого вы можете получать обновления Git посредством самого Git:
prev | next
Непустой проект
Допустим, у нас на локальной машине уже есть проект second-site. Создаем в github репозиторий second-site. Заходим в папку проекта и выполняем команды
Все, можно приступать к работе над проектом. Команды add, commit и push мы разберем в следующих уроках.
Это единственный урок, в котором мы разбирались с тонкостями репозиториев. В дальнейшем будем считать, что репозиторий = проект.
Что могу посоветовать
github или bitbucket? Для личных проектов неважно, оба сервиса разрешают бесплатно создавать приватные репозитории. Для open source или резюме — github
не увлекайтесь клонированием в папку со своим названием
Есть шанс запутаться, самому или коллегам
не путайте публичный и приватный ключи. Отдаем вовне только публичный ключ id_rsa.pub
при смене рабочей машины можно не генерировать ssh-ключи заново, а скопировать их со старой машины. Тогда не придется заново прописывать новые ключи на серверах
Немного подробнее о копировании ssh-ключей
Как скопировать ssh-ключи с одной машины на другую
Хочу немного затронуть эту тему отдельно. Генерировать ключ на новой машине не обязательно. Но нужно выполнить такие действия
- Скопировать id_rsa и id_rsa.pub со старой машины на новую
- Посмотреть права на файлы, возможно, ключи окажутся слишком «открытыми» для записи и потребуется сменить им права доступа — sudo chmod 700 ~/.ssh/*
- Выполнить команду ssh-add
Ссылки, которые могут пригодиться
- github — https://github.com/
- bitbucket — https://bitbucket.org/
- подробнее об ssh-ключах (en) — connecting-to-github-with-ssh
На этом все. В следующем уроке мы сделаем первые изменения в проекте и начнем понимать, в чем заключается прелесть git.
Спасибо за внимание и до встречи!
Следующий урок ⇨
Урок 3. Делаем первые изменения — git diff и git status
⇦ Предыдущий урок
Урок 1. Установка и базовая настройка git
git push (запушить)
Чтобы запушить локальные изменения на удалённый репозиторий, используется команда . Или её расширенный вариант, с указанием ветки, куда пушатся изменения:
git push origin master
Ввод логина и пароля от GitHub при первом пуше
В , теперь будет информация, что никаких новых изменений нет (nothing to commit), и коммитить нечего.
Your branch is up to date. nothing to commit, working tree clean
Теперь проект на Гитхабе актуальный — тут отобразились все изменения, которые были сделаны локально: добавился один commit, добавился файл, изменился README.
Обновилась информация на странице проекта на github
TLDR
Чтобы после изменения проекта, отправить локальные правки на удалённый репозиторий, надо:
- перейти в Терминале в папку самого проекта
- зарегистрировать изменения —
- создать коммит —
- запушить коммит на GitHub —
Обновление локального репозитория, после изменений проекта на GitHub
Бывает так, что файлы проекта правятся прямо на сайте GitHub. Или кто-то из участников проекта запушил новые изменения. В обоих случаях, необходимо получить эти изменения и обновить локальный репозиторий.
Команды git add и git commit
В Терминале перейдём в папку проекта (все изменения с проектом делаются в папке проекта). Для отслеживания изменений используется команда:
git status
Для отслеживания изменений в проекте используется команда:
git status
Просмотр информации об изменениях в проекте с помощью команды git status
Результат работы команды — вывод информации о проекте. Незарегистрированные изменения выделены красным. Структура информации следующая:
On branch master — указана текущая ветка
- Changes not staged for commit — есть незарегистрированные изменения (modified: README.md)
- Untracked files — есть новые файлы (project-page.png)
- no changes added to commit — в данный момент нечего коммитить
Тут же, в круглых скобках git сам даёт подсказки, что можно делать дальше: use git add <file>…
Выбор локальной папки
Создайте локальную папку для локального хранения копии репозитория. Размер некоторых репозиториев может быть значительным, например до 5 ГБ для azure-docs. Выберите расположение с доступным местом на диске.
Выберите имя папки — оно должно быть простым для запоминания и ввода
Например, можно использовать корневую папку или создать папку в каталоге профиля пользователя
Важно!
Не следует выбирать путь к локальной папке, вложенной в другую папку репозитория Git. Несмотря на то что, что клонированные папки Git можно хранить рядом друг с другом, вложение папок Git приводит к ошибкам отслеживания файлов.
Запустите Git Bash
Расположением по умолчанию, в котором обычно запускается Git Bash, является домашний каталог (~) или в ОС Windows.
Чтобы определить текущий каталог, ведите в запросе $.
Преобразуйте каталог (cd) в папку, созданную для локального размещения репозитория
Обратите внимание, что Git Bash поддерживает соглашение Linux по использованию в путях к папкам прямых, а не обратных косых черт.
Например, или .
How to Use Git Commit
Common usages and options for Git Commit
- : This starts the commit process, but since it doesn’t include a flag for the message, your default text editor will be opened for you to create the commit message. If you haven’t configured anything, there’s a good chance this will be VI or Vim. (To get out, press esc, then , and then Enter. :wink:)
- : This starts the commit process, and allows you to include the commit message at the same time.
- : In addition to including the commit message, this option allows you to skip the staging phase. The addition of will automatically stage any files that are already being tracked by Git (changes to files that you’ve committed before).
- : Replaces the most recent commit with a new commit. (More on this later!)
To see all of the possible options you have with , check out Git’s documentation.
How to Undo Commits in Git
Sometimes, you may need to change history. You may need to undo a commit. If you find yourself in this situation, there are a few very important things to remember:
- If you are «undoing» a commit that exists on the remote, you could create big problems for your collaborators
- Undoing a commit on work that you only have locally is much safer
What can go wrong while changing history?
Changing history for collaborators can be problematic in a few ways. Imagine — You and another collaborator have the same repository, with the same history. But, they make a change that deletes the most recent commit. They continue new commits from the commit directly before that. Meanwhile, you keep working with the commit that the collaborator tried to delete. When they push, they’ll have to ‘force push’, which should show to them that they’re changing history. What do you think will happen when you try to push?
In dramatic cases, Git may decide that the histories are too different and the projects are no longer related. This is uncommon, but a big problem.
The most common result is that your would return the «deleted» commit to shared history. (First, you would if you were working on the same branch, and then merge, but the results would be the same.) This means that whatever was so important to delete is now back in the repository. A password, token, or large binary file may return without ever alerting you.
is the safest way to change history with Git. Instead of deleting existing commits, looks at the changes introduced in a specific commit, then applies the inverse of those changes in a new commit. It functions as an «undo commit» command, without sacrificing the integrity of your repository’s history. is always the recommended way to change history when it’s possible.
Sometimes, a commit includes sensitive information and needs to actually be deleted. is a very powerful command that may cause you to lose work. By resetting, you move the pointer and the branch pointer to another point in time — maybe making it seem like the commits in between never happened! Before using :
- Make sure to talk with your team about any shared commits
- Research the three types of reset to see which is right for you (—soft, —mixed, —hard)
- Commit any work that you don’t want to be lost intentionally — work that is committed can be gotten back, but uncommitted work cannot
If you’re changing history and undoing commits, you should know about . If you get into trouble, the reflog could get you out of trouble. The reflog is a log of every commit that has pointed to. So, for example, if you use and unintentionally lose commits, you can find and access them with .
Updating Commits With Git Commit Amend
While does change history, it only changes the most recent commit on your current branch. This can be an extremely useful command for commits that:
- Haven’t been pushed to the remote yet
- Have a spelling error in the commit message
- Don’t contain the changes that you’d like to contain
Создать репозиторий
Зайдите на GitHub.com и войдите под своим именем пользователя и паролем.
Давайте создадим новый репозиторий с домашнего экрана. В левом верхнем углу экрана вы увидите вариант создания нового хранилища. Нажмите New, чтобы начать процесс.
Выберите имя хранилища; любое имя подойдет, если вы помните его для клонирования. Для этого упражнения давайте назовем хранилище «Рабочий стол», чтобы мы запомнили имя.
Давайте установим этот репозиторий в Public и добавим описание. Установите флажок, чтобы инициализировать репозиторий файлом «README», это сделает его доступным для клонирования, как только вы закончите.
Нажмите Создать репозиторий для завершения.
Теперь, когда у нас есть репозиторий, созданный в GitHub, а также наш профиль GitHub, вошедший в GitHub Desktop, мы готовы использовать программу!
