Последние сообщения

Еще пояснение: сперва надо добавить вот это выше, перезайти по ssh и создать tmux сессию. Вот после проделанного будет все.

Удаленные репозитории именуются remotes. Их может быть сколько угодно и у каждого может быть свой протокол связи, а, соотв., и авторизации. Дефолтный зовется origin.

git remote --help — чтобы понять, как создать и удалить.
git push <remote_name> <local_branch_name>:<remote_branch_name> — чтоб отослать свою local_branch_name на удаленную remote_branch_name.
git push <remote_name> <branch_name> — это если имена веток совпадают

Напрямую, из консоли, намного все проще и понятнее, конечно, если знаешь команды. Там встроенный help: git <command> --help — читай на здоровье!
Черепашка разрабатывалась под SVN и потому она такая странная с GIT. Мы на работе отдельную доку писали для ее пользователей, чтобы ни шагу в сторону от инструкции.
И вот от всего этого пользователи говорят, что GIT — это сложно. На самом деле, GIT — это очень просто, если с точки зрения архитектуры. Пользовательский интерфейс, да, не очень, даже в командной строке.

Насчет простоты архитектуры. Загляните в .git/config — там много интересного. Тот же ini, только чуть-чуть расширен в именах секций.

[Джон]

Джон, RXL, а я вот пользуюсь гитом только локально, логин - почта. И однажды мне было нужно пушить копию фрилансерскому работодателю. Столкнулся с проблемой - там логин свой. Помнится, не разобрался, как при пуше на два репозитория одновременно использовать разные логины. Это возможно?

Тогда в виде костыля свой логин сделал таким же, а после окончания сотрудничества вернул свой. Локально мне, по большом счёту, пофиг, но вот сейчас вспомнил этот осадочек
Использую оболочку TortoiseGit , вручную не консолюсь

Бывает, что такое надо сделать программно. Мне нужно было для модификации .gitmodules.
И так, на входе у нас:

• remote — сервер, куда мы хотим запушить результат.
• branch — некая ветка, причем мы на ней не стоим!
• filename_src — имя физического файла, источника данных.
• filename — имя файла, как его будет знать GIT.
• commit_message — текст сообщения для коммита.
• author — автор в формате "name <email>.

Последовательность действий:

# получаем текущий хеш ветки (далее $commit_hash)
$git show-ref --hash refs/heads/$branch

# — получаем хеш дерева
$ git cat-file -p $commit_hash | grep '^tree '

# очищаем индекс
$ git reset

# читаем дерево в индекс
$ git read-tree $tree_hash

# создаем объект на основе содержимого файла в локальном кеше GIT, выводит его хеш (далее $file_hash)
$ git hash-object -w $filename_src

# обновляем дерево в индексе
$ git update-index --add --cacheinfo "100644,$file_hash,$filename"

# создаем объект в локальном кеше GIT — новое дерево из индекса, выводит его хеш (далее $new_tree_hash)
$ git write-tree

# коммитер всегда из берется из конфига "~/.gitconfig", если не установить GIT_AUTHOR_NAME, то и автор будет из конфига
$ GIT_AUTHOR_NAME=$author git commit-tree -p $commit_hash -m "$commit_message" $new_tree_hash

# чистим за собой индекс
$ git reset

# обновляем ветку
$ git branch --no-track -f $branch $new_commit_hash

# пушим ветку
$ git push $remote $branch

Если на любом этапе, от read-tree до commit-tree включительно, произошла ошибка, надо почистить индекс.

Если использовать постоянные сессии tmux, то есть проблема с пониманием GIT (да и не только), где же у нас ssh-агент, чтобы авторизоваться на сервере GitLab, GitHub или еще каком.

Добавить куда-нибудь в домашнюю директорию: .profile, .bash_profile, .bashrc или еще какое место, чтобы при запуске сессии отработало:

Код: (Bash)

if [ ! -z "$SSH_AUTH_SOCK" ]; then
    if [ ! \( -L ~/.ssh/auth_sock -a -S ~/.ssh/auth_sock \) ]; then
        echo -e "SSH Agent: \e[32mused my socket\e[0m"
        ln -sf "$SSH_AUTH_SOCK" ~/.ssh/auth_sock
    else
        echo -e "SSH Agent: \e[33mused other session\e[0m"
    fi

    export SSH_AUTH_SOCK=~/.ssh/auth_sock
fi

При подключении по ssh, после авторизации, пишет, чья сессия владеет unix-сокетом агента. Ну и настраивает так, чтобы было хорошо.
Далее tmux attach -t <session> и можно работать.

Да, вместо tmux можно использовать screen. Кому что нравится.

Понятно. Значит будем писать заметки про гит )

Кстати, Жень, а у вас main, master, develop или trunk? 

master

Дело в том, что я локально git ваще не юзаю. В основном он (мне) служит для передачи данных (commit -> push) на сервер для хранения и компиляции, изредка для merge, когда коллега в проекте участвует.
Опять же, в этом случае я просто делаю pull и всё.

Короче, примерно как Ворд в качестве редактора тхт файлов.

Раньше у нас был локальный серевер компиляции и SVN, лет несколько назад перешли на Azure, которая больше git "любит", ну и вот...

Ром, всё понял. Спасибо. Оставлю так.

Люсь, персонально спасибо.

персональное на здоровье ))))

Достоинства git в том, что каждый клон может выступать как основная копия. Если, конечно, он склонировал все, что нужно для автономности. А еще можно в одной и той же репе сделать больше одного дерева, но надо только чтобы они по именам веток не пересекались. Хотя, какое оно к черту дерево. Это граф полноценный, хоть и с корнем.

Кстати, Жень, а у вас main, master, develop или trunk?  

Ром, всё понял. Спасибо. Оставлю так.

Люсь, персонально спасибо.