mkone112, С какого перепуга мастер поменяется? Я никуда не перемещаюсь из тематической ветки. Последний параметр в команде означает переключиться в эту ветку, если вдруг мы находимся не на ней. Если мы уже в своей ветке, то последний параметр можно опустить. Изменяем только свою ветку, мастер не трогаем.
Saboteur а зачем весь репозиторий то удалять? Если мы перепишем историю только одной ветки, то только её и удаляем и загружаем заново. А ещё лучше если коллеги просто перезагрузят её через git pull --rebase, чтобы не терять свою работу, если успели добавить что-то локально.
Pragma Games, вообще-то да, минус перед другими параметрами похож на ошибку, но строки text и -text валидные. Это указывает на то, как diff будет воспринимать эти файлы. Как текстовые или как двоичные. И как будут учитываться символы новой строки EOL.
Мы наверное не должны редактировать файл .gitattributes вручную, а добавлять туда значения через команду git lfs track, чтобы не накосячить в синтаксисе.
Оба варианта неправильные. Если я правильно понял, у тебя уже есть проект на компьютере, который ты хочешь начать отслеживать через Git. Вот и сделай это, а отправка его на BitBucket это уже второстепенная задача.
Первым делом ты должен инициализировать локальный репозиторий в папке твоего проекта. git init
Создать правильный .gitignore, чтобы впомогательные файлы и npm-модули не мозолили глаза. Их не надо отслеживать. Потом файлы с кодом проиндексировать. git add файлы
Создать начальный коммит с текущим состоянием проекта. git commit
Это стандартный рабочий процесс.
Если нужно отправить код в BitBucket или любой другой хостинг, то ты должен сначала создать там пустой репозиторий, а затем следовать инструкциям, которые там же обычно сразу показываются.
Обычно достаточно двух шагов, чтобы связать локальный и внешний репозиторий. git remote add origin https://адрес_репозитория.git
git push -u origin master
Первая команда запоминает адрес внешнего репо в переменной origin.
Вторая заливает проект и создает связь локальной ветки с внешней веткой master.
После merge ветки featA в master лучше пересадить ветку featB на актуальный master. git rebase master featB
Либо влить актуальный мастер в ветку featB git merge master featB
Так мы сможем видеть различия featB по сравнению с актуальным кодом, а не со старой версией master.
Иначе запутаетесь потом во время вливания featB в master. Надеюсь вы не мёржите в master в слепую, а предварительно рецензируете сделанные изменения. Будет непонятно, что именно сделано в featB, так как там вылезут и коммиты из featA тоже. А актуальный мастер может успеть убежать вперёд. Зачем вам создавать эти проблемы на пустом месте?
Евгений Береговой,
Под клиентскими пакетами подразумеваете клиентские лицензии? Но если вы используете левые патчи для снятия зашитых лицензионных ограничений, значит вам наверное не важна лицензионная чистота?
Тогда серверной винды точно достаточно. Даже активировать или взламывать не обязательно.
ettaluni, а как ты тестируешь? Обычно тесты автоматизируют и они запускаются автоматически прямо на GitLab (или GitHub или другом хостинге). Если ты проверяешь вручную, то тебе достаточно только возможностей чистого Git. Разрабатываешь на своём компе, потом идёшь на тестовую машину и там забираешь обновления средствами Git. Что именно тебе не понятно в команде git pull? Это и есть достОвка ))
Зачем rsync, если Git уже является раcпределённой системой и синхронизируется через push/fetch?
Формат команды отправки git push <адрес репозитория> <в какую ветку>
Чтобы не писать каждый раз полный адрес, добавь его в переменную remote и назови например как test: git remote add test https://10.0.0.1
потом можно будет отправлять короткой командой git push test
Но ветка feature_branch в этот момент не должна быть активной на тестовом сервере, иначе получишь ошибку.
Поэтому проще не проталкивать обновления на стенд, а забирать их с твоего компа находясь на стенде.
Если под словом «сжать» имеется в виду «уменьшить размер раздела», то тут поможет бесплатная утилита. Она умеет перемещать файлы в начало раздела, чтобы освободилось место для такого сжатия.
Если же хотелось увеличить свободное место на диске путём сжатия файлов на нём, то это делается в другом месте. Просто проставьте атрибут «сжатый» в свойствах диска.
На скрине не твой личный аккаунт, а главная страница GitHub. Это видишь только ты.
На странице твоего профиля видны только твои публичные репозитории.
Немного смущает фраза «клон репозитория из аккаунта разработчиков». Если ты сделал форк репозитория разработчиков к себе в личный аккаунт? Если да, то зачем? Когда у тебя есть доступ к оригинальному репозиторию, то форк не нужен.
