• Как скрыть Pull Request от других пользователей?

    sergey-kuznetsov
    @sergey-kuznetsov Куратор тега Git
    Автоматизатор
    Вы наверное хотите скрыть не сам Pull Request, а код, который виден там.
    Но ведь этот код студенты отправляют из своих открытых проектов в ваш открытый проект. Значит код в любом случае виден всем в интернете, причем даже без создания PR.
    Единственный способ скрыть код — публиковать его в закрытые проекты.
    Пусть студенты создают приватные репозитории и дают вам доступ туда.
    Ответ написан
    Комментировать
  • Как в Git переименовать ветку?

    sergey-kuznetsov
    @sergey-kuznetsov Куратор тега Git
    Автоматизатор
    старый мастер назвать old-master и текущую ветку, переименовать в master

    git branch -M master old-master # переимоновать старый мастер
    git branch -M master # переименовать текущую ветку в master

    Но зачем всё это? old-master будет по-прежнему связан с origin\master.
    Если хочется обновить и эти связи, то используется push
    git push --set-upstream origin old-master # перенаправить на новую ветку
    git push -u --force origin master # пересоздать внешний master

    Если origin и VPS это разные места, то VPS не увидит этих ваших переименований.
    Там тоже придётся связи перенастраивать.
    Например через git pull --rebase на VPS и на компьютерах всех коллег, если вы работаете в команде.

    Снова повторю вопрос: зачем вам эти сложности?

    git remote rename - но это для переименования удаленных веток (как я понял)

    Нет, это для переименования remotes — ссылок на внешние репо.
    Ответ написан
    1 комментарий
  • Как называется этот эффект в поле ввода?

    hahenty
    @hahenty
    ('•')
    Ответ написан
    Комментировать
  • Как обновить локальную ветку задачи если develop ветка обновилась?

    sergey-kuznetsov
    @sergey-kuznetsov Куратор тега Git
    Автоматизатор
    Вы наверное не совсем понимаете логику работы гита, раз такой вопрос возник.
    Репозиторий надо рассматривать как дерево состояний проекта. Каждый коммит это определённое состояние. Название ветки это лишь указатель на некоторое состояние.

    создал локальную ветку задачи branchTaskName от локальной develop-ветки (предварительно ее обновив)

    Точнее вы создали тематическую ветку не от другой ветки, а от конкретного состояния, на которое указывал в тот момент указатель develop в распакованной (checkout) в рабочий каталог ветке.

    Нужно ли мне обновлять свою ветку задачи branchTaskName свежими изменениями?

    Моё мнение — нужно. Ведь ваша задача состоит не в создании сферических файлов в вакууме, а в изменении файлов проекта. Причём изменений относительно уже устаревшего состояния. Желательно чтобы ваша работа опиралась на актуальный проект, а не на старую версию.

    Как правильно обновить ветку задачи branchTaskName чтобы не было проблем при отправке своей ветки в удаленный репозиторий?

    Тут тоже странное утверждение. У вас неоткуда взяться проблемам при отправке (push) изменений во внешний репозиторий. Проблемы могут возникнуть уже после, когда вашу ветку будут интегрировать (merge) с основной веткой (develop). Чтобы избежать этих проблем мы заранее предпринимаем определённые действия.

    Способов собственно два:

    1) Мы забираем новое состояние develop в свою тематическую ветку через коммит слияния. И для этого вовсе не обязательно переключаться в локальную develop, обновлять её (pull) а затем возвращаться к себе чтобы сделать git merge develop. Это бессмысленные манипуляции. Достаточно просто скачать к себе в локальный репозиторий обновления внешнего репозитория git fetch (Лайвхак: эту операцию можно автоматизировать. Настройте автоматическое выполнение fetch по расписанию, и у вас всегда будет под рукой доступ к актуальному проекту). Затем сделайте git merge origin/develop. Указатель origin/develop это и есть ссылка на состояние проекта на момент последнего скачивания (fetch). В принципе эти два шага эквивалентны одной команде git pull origin develop — внутри делается всё то же самое.

    2) Второй способ — пересадить вашу ветку на новое актуальное состояние проекта (rebase). Выглядеть будет так, если бы вы начали работать над фичей вот только что, и тут точно не возникнет конфликтов, так как база ветки актуальная. Это делается тоже в два шага. Сначала убедимся что у нас всё актуально git fetch, затем собственно пересадим ветку на актуальное состояние git rebase develop. Последний вариант мне нравится тем, что история не засоряется коммитами слияния. Но тут предполагается, что тематическая ветка принадлежит только вам и никто больше в ней не работает. Так как после пересадки её придётся удалять из внешнего репозитория и создавать там заново через git push --force. Если работа над фичей ведётся совместно с коллегами, то такой рабочий процесс не очень подойдёт.

    Если вы не коммитите напрямую в master и в develop, то держать их у себя локально (делать checkout в рабочий каталог) тоже нет смысла. Вы всегда можете начать новую тематическую ветку от актуального состояния, на которое ссылаются origin/master или origin/develop. Так вы не наступите на грабли, когда люди забывают переключиться из мастера и начинают коммитить туда. Нет мастера — нет проблем.
    Ответ написан
    Комментировать
  • Как организовать изолированную среду выполнения собранного dotnet приложения?

    vabka
    @vabka Куратор тега .NET
    Токсичный шарпист
    Кажется, что прощё сделать софт как SaaS, а хостинг на серверах заказчика сделать только для тех ситуаций, когда это заказчику действительно необходимо и за индивидуальный прайс.
    Даже в случае утечки будет сразу ясно, кто это сделал и набутылить.

    А полностью защищённый контейнер - это физический сервер, к содержимому файловой системы которого человек со стороны не будет иметь доступ совсем.

    Никакие софтовые решения (обфускация, контейнеры, шифрованные виртуалки, передача критичного исполняемого кода по сети) не спасут от тех людей, которые хотят с вами конкурировать или осознанно хотят нарушить соглашения.
    Ответ написан
    4 комментария
  • Как организовать изолированную среду выполнения собранного dotnet приложения?

    @Voland69
    ИМХО вариант только хостить у себя.
    Всякая виртуалка в шифрованном томе не выход, т.к. чтобы оно запустилось, у клиента так или иначе должен быть ключ.
    Ответ написан
    1 комментарий
  • Пишут ли в компаниях коммиты в git на русском?

    Aetae
    @Aetae
    Тлен
    Ну, юзается логика. Если проект будет работать только в рамках России без вариантов - и комменты и коммиты - на русском. Иначе - на английском.
    Ответ написан
    Комментировать
  • А можно ли как-то иметь файл в локальном репозитории, но при этом чтобы он не пушился в удаленный?

    sergey-kuznetsov
    @sergey-kuznetsov Куратор тега Git
    Автоматизатор
    Гит пушит не файлы, а ветки с коммитами, поэтому внешний репозиторий будет содержать точную копию локальных данных. Репозиторий по сути один, и он распределённый. Так устроен Гит. Нет разницы локальный или внешний.
    Не храни вообще конфиги в репозитории, если он уйдёт в паблик!
    Поэтому правильный ответ на поставленный вопрос — нет.

    Но ты можешь распаковать (checkout) разные ветки в разные каталоги (worktree). И уже для каждого сможешь сделать нужные настройки. Так ты получишь желаемое и пароли не придётся светить в публичном внешнем репозитории.
    Ответ написан
    1 комментарий
  • Почему на только что скачанном репозитории Git выдает список измененных файлов?

    sergey-kuznetsov
    @sergey-kuznetsov Куратор тега Git
    Автоматизатор
    Такое может произойти из-за неправильной настройки символа переноса строки.
    Читай тут как исправить.
    Ответ написан
    Комментировать
  • Как откатиться назад на стабильный commit и при этом сохранить полезный код, который ты сделал после допущенной ошибки?

    На практике редко ошибки правятся "выдиранием" одного коммита из истории, но такая операция вполне себе возможна.
    Вариант номер один - интерактивный ребейз, и в нем указываешь какие коммиты дропнуть. Если коммитов много, то можно задолбаться решать конфликты
    Вариант номер два - просто делаешь новый коммит с реверсом изменений из коммита, который привел к проблемам
    Вариант третий - делаешь новый бранч, откатываешся до проблемного коммита, потом из полного бранча накатываешь остальные изменения.

    Все сценарии приблизительные, потому что каждая проблема требует комплексоного подхода и знания возможностей инструмента, поэтому не поленись, а почитай вот это внимательно и полностью
    https://git-scm.com/book/en/v2
    Ответ написан
    Комментировать
  • Как переключить удаленный репозиторий на более ранний коммит?

    sergey-kuznetsov
    @sergey-kuznetsov Куратор тега Git
    Автоматизатор
    git reset --hard 0821842 # откатить локально 
    git push --force # откатить на внешнем, это удалит и создаст заново ветку

    Master обычно имеет защиту от удаления, тогда можно поступить более правильно:
    # создать синтетический коммит, отменяющий последние коммиты
    git merge --ff $(git commit-tree -p master -m "Rollback to commit 0821842" 0821842^{tree})
    git push
    # можно ещё для надёжности проверить, что новое состояние действительно совпадает с желаемым
    git diff master 0821842
    Ответ написан
    8 комментариев
  • Как вернуть проект в состояние, в котором он был до того как изменились файлы (к последнему комиту)?

    Real_Fermer
    @Real_Fermer
    Программист PHP
    git reset --hard HEAD
    Ответ написан
    Комментировать
  • Как склонировать ветку на свой домашний компьютер через ssh если локальная разработка проводилась на другом компьютере?

    karabanov
    @karabanov
    Системный администратор
    Сгенерируй SSH ключ на домашнем компьютере ssh -t ed25519
    Добавь публичную часть ключа в свой аккаунт на GitHub
    После этого сможешь клонировать.

    К каждого устройства должен быть свой ключ. Приватный ключ не должен покидать устройство на котором он был сгенерирован.
    Ответ написан
    1 комментарий
  • Могут ли p2p сети работать, если все пользователи имеют серые IP?

    @rPman
    Вообще без каких либо опор с белыми ip.
    тогда не смогут
    tcpip требует чтобы кто то к кому то по ip адресу подключился

    но возможна ситуация когда с однократно с помощью белого ip клиент подключился к другому клиенту, который открыл порты на роутере с помощью upnp, запомнил всех таких клиентов и передал весь их список (id_client:ip:port) всем клиентам.

    Если оперативно передавать информацию об изменениях ip адресов клиентов (такие клиенты все еще помнят адреса других и при смене своего адреса тут же сообщают об этом другим) то это облако клиентов сможет существовать в принципе без сигнального сервера (точнее сигнальными серверами могут являться другие клиенты)

    Если клиент на долго отключится от этой сети, может получиться что все другие клиенты сменят ip адрес и ему некуда будет подключаться, но чем больше клиентов в сети тем больше шансов что появится клиент с постоянным ip адресом.

    p.s. udp подключение позволяет подключиться к чужому подключению без наличия на роутере поддержки upnp
    Ответ написан
    Комментировать
  • Клиент присылает 100500 правок, при этом проект завершен на 99%. Как быть?

    DevMan
    @DevMan
    правки бывают двух типов:
    1. исправление косяков.
    2. дополнительные фичи/изменение уже реализованных.

    1 делается бесплатно и как можно быстрее.
    2 делается за отдельные деньги. или не делается вообще и работа с клиентом прекращается.

    есть ещё 3: дать клиенту скидобан на конкретно оговоренный объем дополнительных работ.

    это из основного. есть ещё методы, но они уже для постоянных клиентов.
    Ответ написан
    1 комментарий
  • Как создать ветку -@#%=]! в git?

    Lynn
    @Lynn
    nginx, js, css
    Ну развлекайтесь

    $ git update-ref 'refs/heads/-@have-fun!' @^{commit}
    $ git switch -- '-@have-fun!'
    Switched to branch '-@have-fun!'
    $ git branch -v
    * -@have-fun! 734a4af Docker
      master      734a4af Docker
    Ответ написан
    Комментировать
  • Как добавить чужую ветку в проекте?

    @schepetkov
    remotes/origin/develop означает, что ветка есть в удалённом репозитории.
    Достаточно просто переключиться на ветку:
    git checkout develop
    Если ветка есть локально - гит переключится на неё, если её нет локально, но она есть в удалённом репозитории - гит её скачает и переключится на неё (и ветка появится локально). Если ветки нет ни локально, ни удалённо - будет ошибка.
    Ответ написан
    Комментировать
  • Алгоритм эффективного размещения?

    wataru
    @wataru Куратор тега Алгоритмы
    Разработчик на С++, экс-олимпиадник.
    *offtopic* Лет 15 назад делал такое для записывания анимешных сериалов на CD-диски, только там было сложнее, потому что сериалы можно разбивать по нескольким дискам и записывать можно толко сериалы целиком. Эх... было время. Сейчас эти 300 дисков даже и прочитать-то нечем. И исходники пропали лет 10 назад =(.

    Как вам уже написали - эта задача о мульти-рюкзаке. Простого и эффективного решения у нее нет.

    Однако, на практике, скорее всего, вам не нужно оптимальное решение - нужна лишь его некоторая аппроксимация. Посмотрите задачу о рюкзаке. Там есть очень простое динамическое программирование с параметрами вида "можно ли используя файлы с 1 по i-ый заполнить ровно k (мега|кило)байт"

    Потом сморите в конце массива для всех файлов - это оптимальные заполнения одной флешки.

    Удалите файлы определенные на эту флешку из рассмотрения и повторяйте процесс.

    Можно навесить сверху полный перебор с отсечениями. Из массива ДП идля задачи о рюкзаке можно случайным образом получить несколько хороших заполнений.

    Потом в переборе пробуйте разные варианты, запускайтесь рекурсивно. Какой-то ответ будет найден моментально. Выходите из перебора, если текущее количество флешек/общее свободное место/сумма квадратов свободных мест превысило оптимальное найденное пока что.

    Для ускорения можно округлить размеры файлов до мегабайта. Чем меньше разрешение - тем быстрее будет работать ДП. Еще можно отдавать предпочтение большим файлам в начале.

    Альтернативно - составьте задачу целочисленного линейного программирование (integer linear programming) и натравите на нее какой-то из солверов. Они сейчас очень продвинутые. Правда тут уж как повезет. Может на вашей задаче вы ответа так и не дождетесь. В качестве переменных берите, что такой-то файл относится к такой-то флешке. Сумма по каждому файлу - ровно один. По каждой флешке сумма размеров файлов * на переменные <= размер флешки. Сумма свободных мест - минимизируется.

    Возможно, можно составить квадратичную целевую функцию, я не знаю, что сейчас солверы умеют. Гуглите quadratic integer programming solver.

    Если хотите минимизировать количество флешек, то можно завести еще переменные - занята ли флешка. Уравнения тут - эта переменная >= всех индикаторынх переменных для всех файлов для этой флешки. Целевая функция - сумма всех переменных занятости флешек.
    Ответ написан
    Комментировать
  • Безопасный обмен данными между моб приложением и бэкендом?

    pro100chel
    @pro100chel
    Python && PHP Developer
    НИКАК. Все что лежит на клиенте может быть сломано. Протоколы взаимодействия клиента и сервера будут вскрыты и все равно будет лететь калл на сервер, тут ничего не поделаешь.

    1)От школьников и хацкеров можно защититься при помощи SSL/TLS. Если у тебя REST API то просто ставишь сертификат на сервер при помощи Lets Encrypt или же стороннего провайдера по типу CloudFlare.

    2) В REST данные передаются по URL. Первое, что будет делать человек, который декомпильнул твой апликатион он будет искать URL в коде. Шифруй URL в каких-нибудь base64 или как-нить по-другому. Сам код нужно будет обфусцировать, запутать.

    3) Максимально усложнить хацкерам жизнь. Например, ограничить кол-во запросов в минуту или в час. Выдавать иногда капчу, усложнить протокол аутентификации (например, часто менять ключ и разными способами, делить ключи на части и получать их разными методами). При обфусцированном коде это будет довольно сложно отследить.

    Это все можно будет обойти опытному человеку минут за 5-10. Просто поднимается посредник между клиентом и сервером и тупо ставится поддельный сертификат или же подменяются ключи. Таким образом злоумышленник может "отлаживать" твой протокол взаимодействия.

    Все меры защиты нацелены на усложнение взлома, а не на его невозможность.
    Ответ написан
    Комментировать