В чем разница между HEAD: master и HEAD?

Question

git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_APP_NAME_PRODUCTION.git HEAD

и

git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_APP_NAME.git HEAD:master

Похоже, что HEAD: мастер может перезаписать файл .gitignore, а HEAD - нет.

Answer 1

Общий синтаксис для git push:

git push <remote> <refspec>

Последний аргумент, который вас интересует, обычно имеет форму <local-branch>:<remote-branch>, что означает «протолкнуть мою ветку, названную удаленно, в ветку с именем». Есть несколько ярлыков:

• git push <remote> <branch> (без :, например git push origin master) является ярлыком для git push <remote> <branch>:<branch>, т. Е. Помещает локальную ветвь в удаленную ветвь с тем же именем.

• git push <remote> HEAD означает передачу текущей ветви к ветви с тем же именем на пульте дистанционного управления. Это первая команда, которую вы пишете в своем вопросе.

Вторая упомянутая вами команда - это общий случай: HEAD:master означает «перенести текущую ветвь в основную ветвь в удаленном репозитории».

Если вы видите разницу, вы находитесь в локальной ветке, отличной от master, скажем my-branch. HEAD в одиночку подталкивает к my-branch на пульте. HEAD:master подталкивает к master независимо от вашей текущей ветви.

Answer 2

Разница в целевой ветви на удаленном сервере.

Предположим, вы сидите на ветке foobar.

git checkout foobar
..workwork..
git push origin HEAD

HEAD новейшая версия вашей текущей локальной ветки . Таким образом, в данном примере это означает foobar. Поэтому эта команда просто отправит foobar на удаленный сервер. На удаленном сервере он обновит / перезапишет ветку, которая «соответствует» *) той, которую вы отправляете. Обычно это означает отправку foobar как foobar. Здесь нет сюрпризов.

С другой стороны

git checkout foobar
..workwork..
git push origin HEAD:master

явно инструктирует git отправить вашу ГОЛОВУ как master . Это означает, что он отправит ваш самый последний foobar на удаленный сервер как master на удаленном сервере. Просто так, именно так. Ваш местный master не изменится и останется нетронутым. Пульт foobar, если он вообще существует, не изменится. Однако удаленный master теперь будет синхронизироваться с вашим локальным foobar

---

*) именно клиент (ваша локальная сторона) решает, какую ветвь выбрать на удаленной стороне. Отображения по умолчанию между локальной веткой и удаленной веткой хранятся в вашем файле .git/config. Абсолютно возможно заставить вашу локальную ветку aaa автоматически отправлять на удаленную aaa или на удаленную bbb, так что на самом деле я не могу сказать вам, куда именно git push origin xxxx подтолкнет ветку xxxx - это зависит от сопоставлений - и вы можете изменить их --set-upstream или просто отредактировав файл конфигурации. С другой стороны, git push origin xxx:yyy всегда означает именно это: отправьте x как y.

---

Что касается .gitignore части - она ​​не имеет ничего общего. Ни тянуть, ни толкать ничего нельзя для .gitignore. Git-ignore не мешает вам что-либо толкать. Это только помогает вам в не фиксировать ненужные файлы . Даже в этом контексте это не мешает вам, так как вы всегда можете добавить любой файл через git add -f, и такие файлы будут отправляться на любые пульты во время push, как обычный файл (которым они на самом деле являются).

Обратите внимание, что эти две команды, которые вы показали, используют разные репозитории:

... git.heroku.com/$HEROKU_APP_NAME_PRODUCTION.git ... git.heroku.com/$HEROKU_APP_NAME.git

может быть, именно это и заставило вас думать, что git-ignore меняет дело?