LINUX.ORG.RU

Не пушатся ветки, если их делать локально на склонированном репе.

 ,


0

1

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

Собственно по порядку

git clone git@github.com:project/rep .

Затем

git checkout develop

Делаем веточку от develop и работаем в ней

git branch feature1
git checkout feature1

А вот при попытке запушить начинается веселье

$ git add filename.txt
$ git status
On branch feature1
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   filename.txt

$ git commit -m 'fix'
[feature1 388e691] fix
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 filename.txt

$ git push
Everything up-to-date

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

Что я упускаю?

★☆☆

Последнее исправление: r_asian (всего исправлений: 1)

git push origin feature1 решит твою проблему.

также рекомендуется изучить следующую директиву конфигурации git.

push.default Defines the action git push should take if no refspec is explicitly given. Different values are well-suited for specific workflows; for instance, in a purely central workflow (i.e. the fetch source is equal to the push destination), upstream is probably what you want. Possible values are:

nothing - do not push anything (error out) unless a refspec is explicitly given. This is primarily meant for people who want to avoid mistakes by always being explicit.

current - push the current branch to update a branch with the same name on the receiving end. Works in both central and non-central workflows.

upstream - push the current branch back to the branch whose changes are usually integrated into the current branch (which is called @{upstream}). This mode only makes sense if you are pushing to the same repository you would normally pull from (i.e. central workflow).

simple - in centralized workflow, work like upstream with an added safety to refuse to push if the upstream branch’s name is different from the local one.

When pushing to a remote that is different from the remote you normally pull from, work as current. This is the safest option and is suited for beginners.

This mode has become the default in Git 2.0.

matching - push all branches having the same name on both ends. This makes the repository you are pushing to remember the set of branches that will be pushed out (e.g. if you always push maint and master there and no other branches, the repository you push to will have these two branches, and your local maint and master will be pushed there).

To use this mode effectively, you have to make sure all the branches you would push out are ready to be pushed out before running git push, as the whole point of this mode is to allow you to push all of the branches in one go. If you usually finish work on only one branch and push out the result, while other branches are unfinished, this mode is not for you. Also this mode is not suitable for pushing into a shared central repository, as other people may add new branches there, or update the tip of existing branches outside your control.

This used to be the default, but not since Git 2.0 (simple is the new default).

git config --global --get push.default узнать текущее значение переменной в глобальном конфиге.

dhampire ★★★
()
Ответ на: комментарий от pi11

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

anonymous
()
Ответ на: комментарий от anonymous

Какая у тебя эмоциональная реакция на очевидную шутку.

pi11 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.