Git - artemovsergey/ASP GitHub Wiki

Основные команды Git по работе с ветками


git config --global user.name "YOUR NAME"
git config --global user.email "[email protected]"

git log — история коммитов.
git status — измененные файлы (показывает добавлены в коммит или нет).
git add file — добавить файл в коммит.
git add . — добавить все изменённые файлы в коммит.
git commit — m ‘text’ - добавить подпись коммитов.
git commit --amend — изменения сообщение последнего коммита.
git branch — посмотреть ветки.
git branch -v — просмотре веток с последним в ней коммитом.
git branch –a - просмотре всех веток: удаленных и локальных
git branch -m my-bug-fix изменение имени ветки
git branch -m my-new-feature my-new-feature (из-под другой ветки) - изменение имени ветки

git branch -d название ветки — удалить ветку. 
git checkout название ветки — переключиться в ветку.
git checkout -b название ветки — создать новую ветку и сразу в неё переключиться.
git push сервер ветка – залить изменения на сервер в указанную ветку.
git push -f  — залить изменения на сервер в режиме force, то есть с возможностью переписать уже имеющиеся коммиты на сервере. Будьте очень аккуратны с этой командой, а лучше минимизируйте её использование, ведь вы будете переписывать серверные файлы.

git fetch получаем актуальную информацию о репозитории на сервере. Извлечём все последние изменения удалённого репозитория. Извлекаются последние актуальные метаданные.

git pull origin dev (ключевое слово origin указывает на удаленный репозиторий). Извлечь и скопировать все изменения из удалённого репозитория

git merge name_new_brahch
git rebase name_new_branch - перенос с историями изменений

git config --global init.defaultBranch main

git config --global alias.co checkout


git cherry-pick abc - перенос одного коммита

git revert abc - отмена коммита с помощью сосздания нового коммита
git --soft reset abc  - раскоммичивает изменения, изменения остаются в индексе
git --hard reset abc

Порядок работы c Git

git checkout master - переключаемся на мастер

git pull -p - обновляем ветку мастер с сервера. В общих чертах pull состоит из двух компонентов: команды fetch, которая подтягивает изменения с удаленного репозитория, и команды merge, которая совмещает эти изменения с вашей локальной веткой.

git checkout -b [название-ветки]

Принципы работы c Git

ваш комментарий к коммиту должен полностью описывать (в настоящем времени) его содержимое, например "add About section to navbar on static pages". Комментарий должен быть на английском языке, вне зависимости от того, какой язык используете вы или ваша команда разработчиков. Если вы хотите использовать точку или "и", то, возможно, вы включили в коммит слишком много, и его следовало бы делать более модульным и независимым.
У нас есть две основные ветки -- master и dev. master используется для готового к работе в production кода. Любой код, попадающий сюда, будет протестирован и перейдет в production. Вы же будете работать с отдельной веткой и создавать пулл реквесты в ветку dev. Представьте, что ветки master вообще не существует.

1 Создайте ветку для любого функционала, используя $ git checkout -b your_feature_name.

2 Напишите код, закоммитьте его, напишите еще, повторите коммит (видите шаблон?).

3 Когда вы сделали работу, есть шанс, что кто-то уже внес изменения в "upstream". Это значит, что ветки master и dev уже устарели. Выполните $ git fetch upstream для получения свежих данных.

4 Используйте $ git branch --all, чтобы получить список всех веток, в том числе тех, которые обычно скрыты (например удаленных веток, которые вы только что получили). Среди них вы должны увидеть upstream/master и upstream/dev.

5 Теперь слейте изменения из upstream в локальную версию dev, используя $ git merge. В данном случае, будет необходимо выполнить $ git checkout dev, чтобы попасть на ветку dev, и затем выполнить $ git merge upstream/dev. На этом перенос изменений в dev будет закончен.

6 Замечу, что команды $ git fetch upstream и $ git merge upstream/some_branch - это то же самое, что и одна команда $ git pull upstream/some_branch, просто я предпочитаю разделять ее на два шага.

7 Теперь, когда ветка dev содержит актуальные данные, необходимо слить ее с вашей веткой нового функционала. Хотя это звучит странно, тем не менее это так и есть. Хотите вместо этого слить ветку нового функционала с dev? Да хотите, но не сейчас. Ваша ветка с новым функционалом "грязная". Вы не знаете, содержит ли она потенциальные конфликты. Каждый раз, когда вы сливаетесь со "старшими" ветками (например ветку с вашим функционалом в dev, или же dev в master), вам необходимо, чтобы слияние было неконфликтным. Поэтому, сначала необходимо слить "старшую" ветку с "младшей" для разрешения конфликтов. Так что, мы выполняем $ git checkout your_feature_name, чтобы перейти на вашу ветку с новым функционалом, а затем $ git merge dev, чтобы слить в нее dev.

8 Возможно вы получите конфликт слияния... разрешите его с помощью $ git mergetool, или просто откройте вручную конфликтующие файлы. В основном, в таких случаях, в файлы вносятся маркеры, обозначающие, какие строки относятся к новому коду, а какие - к существующему. Необходимо один за одним отредактировать эти файлы (включая удаление маркированного текста), а затем пересохранить их. После этого, необходимо провести коммит, чтобы закончить слияние.

Создание Pull Request (ПР)

1 После того, как ветка с вашим функционалом проверена, и вы знаете, что она сольется с dev без ошибок, осталось пройти пару шагов. Выполните слияние с dev командами $ git checkout dev и $ git merge your_feature_name.

2 Теперь необходимо отослать локальную ветку dev в origin (напомним, это ваш форк на Github). Вы не можете отослать изменения сразу на upstream, так как у вас нет туда доступа, поэтому вам необходимо выполнить Pull Request (ПР). Команда $ git push origin dev отправит ветку dev в origin.

3 И, наконец, создайте ПР, чтобы отправить свою версию dev в ветку dev репозитория upstream. Это может быть сделано с использованием пользовательского интерфейса Github. Здесь вы должны быть уверены в том, что отправляете ПР в ветку dev, а не в master.