webdonsk.ruКак сделать релиз в github
Добавил пользователь Дмитрий К. Обновлено: 10.09.2024
Этот документ объясняет механизм ветвления и то, каким образом публиковать свои изменения в GitLab.
Терминология
master: главная ветвь проекта. Обычно ветки создаются от master. Вы не должны делать свою работу напрямую в master и должны создавать новые ветки для каждой задачи над которой вы работаете самостоятельно или сообща. Когда работа закончена выполняется слияние вашей ветки обратно в master. Ветвление и слияние в Git должно стать частью вашего ежедневного рабочего процесса.
origin: основной удалённый репозиторий в котором вы публикуете свои изменения и из которого получаете изменения других разработчиков.
Ветки
Две основные долгоживущие ветки:
- master основной ствол проекта. Ветки для доработок и багфиксов начинаются здесь.
- stable ветка для текущего релиза на сопровождении. Сюда вносим только исправления ошибок, портированные с master.
Настройка GitLab аккаунта
GitLab должен знать что вам разрешено делать, а что нет. Для этого вам нужно настроить доступ по SSH-ключам. Это описано здесь
Цикл разработки
Мы используем подход, основанный на мерж-реквестах. Багфиксы и доработки должны быть опубликованы в собственной ветке разработчика, которая создаётся специально под задачу.
Затем создаётся запрос на слияние новой ветки с веткой master в основном репозитории. Следует избегать публикации непосредственно в ветку master.
Правила именования коммитов
Комментарии к правкам следует писать по-русски в кодировке UTF-8.
Многострочный комментарий состоит из однострочного заголовка отделённого от тела пустой строкой.
Длина строки заголовка и тела не должна превышать 80 символов.
Тело комментария должно содержать информацию о том что сделано и зачем это было сделано.
Многострочный комментарий используется при необходимости детализировать назначение набора изменений.
Если правка относится к задаче в трекере, в заголовке указывается номер задачи Jira.
IS-1276. Экспорт РПП в формат CSV. Выгрузка НДС в назначении платежа.
Правила именования веток
Имена функциональных веток должны кратко, в 1-2-3-4 слова (слова разделяются дефисом), характеризовать назначение ветки.
Нет необходимости включать в наименование ничего не значащие или понятные только вам аббревиатуры, постфиксы, указания на нежелаемое поведение.
Хороший пример: fix-service-control
Плохой пример: ab1000610777_notStmt-branch - WTF?!
Создание merge request
Идём на GitLab, находим модуль, в котором мы опубликовали свою ветку, далее на закладке Merge requests и нажимаем кнопку Create merge request.
Вводим Title. Заголовок обязательно должен включать номер задачи в Jira и тему, характеризующую изменения.
В Description можем указывать какие именно изменения были сделаны, почему предпочтение отдано именно такому подходу.
Дополнительно здесь можно указать информацию, которая может быть полезна ревьюверу чтобы сориенироваться в предлагаемых правках.
А также упомянуть тех, кому эти изменения могут быть интересны (чьё мнение вам важно). Для этого введите /cc @
Здесь работает markdown-синтаксис.
Проверяем что в список Changes попали только коммиты с вашей ветки.
Выбираем того, кому предстоит принимать ваш запрос из выпадающего списка Assignee.
Ставим галку Remove source branch when merge request is accepted.
Жмём Submit merge request. Мерж-реквест создан. О дальнейшей его судьбе вы будете узнавать из уведомлений, которые начнут приходить на электронную почту.
Больше мерж-реквестов
Для набора изменений, затронувшего несколько модулей, если изменения в этом модуле не совсем тривиальны и нуждаются в ревью (см. ниже раздел "Когда направлять мерж-реквест, а когда нет"), создаётся по одному мерж-реквесту на каждый модуль.
Имена веток во всех модулях должны совпадать. Для навигации между ними в описании добавляются перекрёстные ссылки.
Кто принимает мерж-реквест
Мерж-реквест должен быть одобрен хотя бы одним разработчиком, который не принимал непосредственного участия в написании кода этого изменения
Ревьюверу следует обращать внимание на:
- Соответствие предложенного решения поставленной задаче.
- Соответствие стилю кодирования.
- Наличие тестов и документации.
Комментарии и замечания должны находиться непосредственно в данном мерж-реквесте.
Одна из самых распространенных систем управления версиями – Git. Ее ядро добавляет в систему ряд консольных команд, предназначенных для управления репозиториями. В самих же репозиториях хранятся важные каталоги, конфигурационные файлы, журналы и прочие связанные элементы.
Далее я расскажу, как создать, клонировать и удалить эти репозитории.
Следующие инструкции предназначены для тех, кто уже установил Git на свой сервер. Если вы еще не сделали этого, используйте руководство с GitHub, которое поможет разобраться с выполнением поставленной задачи.
Создание Git-репозитория
Сначала рассмотрим создание репозитория. Представим, что у вас уже есть папка для хранения файлов, но она еще не находится под контролем Git.
В Linux выполните команду: ?
В macOS :
В Windows:
Остается только ввести нижеуказанную команду, чтобы завершить первый этап.
Благодаря этой команде создается структура подкаталога со всеми необходимыми файлами. Кстати, все они расположены в подпапке с названием .git . Пока что проект не находится под контролем учета версий, поскольку в него добавлены только нужные элементы для работы Git. Для добавления файлов в репозиторий будем использовать git add. Команда git commit является заключительной:
Теперь у вас есть Git-репозиторий со всеми необходимыми составляющими и отслеживаемыми файлами.
Клонирование существующего репозитория
Второй вариант создания директории для контроля версий – копирование существующего проекта с другого сервера. Это актуально, когда осуществляется доработка готового проекта или вы желаете внедрить его компоненты в свой. В этом поможет команда git clone , о которой и пойдет речь далее.
При использовании упомянутой команды вы получаете клоны всех версий файлов, а значит, можете использовать любые из них, если что-то пойдет не так. Это же пригождается, когда требуется вернуть предыдущую версию проекта, что осуществимо благодаря файлам, помещенным под версионный контроль.
Для клонирования существующего репозитория понадобится ввести git clone . Пример такой команды вы видите ниже:
Данная команда позволила вам получить клон всех версий указанного репозитория (в качестве примера было взято название rep ). Теперь на вашем сервере создана директория с указанным названием. К ней подключена поддержка контроля версий, то есть появилась папка .git .
При использовании вышеуказанной команды репозиторий клонируется с текущим названием. Если же оно должно отличаться, используйте следующую вариацию команды:
Завершим этот раздел статьи описанием содержимого, которое появляется в консоли при выполнении команды. Данный вывод соответствует успешному клонированию:
Удаление локального Git-репозитория
Если с созданием и клонированием репозиториев все понятно, то как быть, когда папка с проектом уже существует, но в нее нужно поместить новые данные, удалив предыдущие, или когда Git-репозиторий на сервере больше не нужен. В таком случае осуществляется стандартное удаление.
В корне каталога с проектом необходимо избавиться от папки .git, о которой уже шла речь выше. Так вы удаляете только ту информацию, которая связана с Git, но сам проект остается. В Linux через Терминал вы должны перейти к каталогу с проектом и ввести следующую команду:
Еще один вариант – удаление .gitignore и .gitmodules в случае их наличия. Тогда команда меняет свой вид на:
Остается только убедиться в отсутствии скрытой папки, которая может помешать инсталляции новой. Для этого существует простая команда ls -lah , выполнить которую необходимо с указанием того же каталога.
Только что мы разобрались с основами создания, клонирования и удаления Git-репозитория. Удачи!
Это запись о том как быстро начать работу с Git’ом. Не какой воды.
Установка Git
Первоначальная настройка git
Настройка SSH-авторизации
Далее копируем открытый ssh-ключ в буфер обмена. Команда для копирования вводится в зависимости от Вашей OS.
Для Mac
Для Linux (Ubuntu)
Для Windows (Git Bash)
Как ввести SSH ключ на стороне Git’a
Теперь жмем на вкладку “SSH and GPG keys”:
Далее нажимаем кнопку “New SSH Key”. Указываем имя и вставляем ключ в поле Key. Нажимаем Add Key.
Работа с репозиторием
Клонирование репозитория
Покажу на примере Windows.
Когда вы создаете репозиторий на GitHub, он существует как удаленный репозиторий. Вы можете клонировать свой репозиторий, чтобы создать локальную копию на вашем компьютере и синхронизировать между этими двумя местоположениями.
В этой процедуре предполагается, что вы уже создали хранилище на GitHub или имеете существующее хранилище, принадлежащее кому-то, кому вы хотели бы внести свой вклад.
Клонирование репозитория с помощью командной строки
На GitHub перейдите на главную страницу репозитория.
Примечание. Если хранилище пустое, вы можете вручную скопировать URL-адрес страницы хранилища из браузера и перейти к шагу 4.
Под именем хранилища нажмите Клонировать или загрузить .
Откройте Git Bash. TerminalTerminal
Измените текущий рабочий каталог на место, где вы хотите сделать клонированный каталог.
Результат: каталог с выписанной веткой master . Теперь можно создавать новые ветки, или выписывать с github существующие.
Как выписать ветку с github
Или так, что намного надежнее:
Если команда не сработала, нужно попробовать выполнить обновление:
Если вышеприведенные команды не сработали, выдали ошибку, и времени разбираться с ней нет, можно попробовать получить нужную ветку следующим способом:
Т.е. сначала мы создаем новую ветку, а затем вливаем в нее изменения из ветки на github.
Как создать новую ветку в локальном репозитории
2. Публикуем ее на github:
Как переключиться на другую ветку в git
Если вы случайно удалили какой-то файл, можно извлечь его из хранилища:
Как посмотреть список веток
Как сделать commit
Создаем новую ветку, выполняем в ней нужные изменения.
- Список всех измененных и добавленных файлов можно просмотреть командой:
2. Подготавливаем коммит, добавляя в него файлы командой:
Или удаляем устаревшие файлы:
3. Выполняем коммит:
4. Как правило, в репозитории существует две основные ветки — dev и master. Dev — общая ветка разработчиков и тестировщиков. Именно в нее добавляются все новые разработки перед очередным релизом. Master — ветка для выкладки продукта на боевые сервера.
После коммита надо влить в нашу ветку изменения из ветки dev и master:
Теперь наша ветка содержит изменения для проекта, и все последние изменения по другим задачам, которые успела внести команда.
5. Переключаемся на ветку dev:
6. Вливаем в dev изменения из ветки проекта:
7. Заливаем последнюю версию ветки dev на удаленный сервер:
push может не пройти, потому что удалённый origin/dev обогнал локальную его копию.
Как решить конфликт бинарных файлов
Допустим, при слиянии с другой веткой git выдал ошибку. Команда git status возвращает информацию о конфликте:
Конфликтный файл является бинарным (это могут быть архивные файлы, изображения и т.п.), и решение конфликта стандартным способом, с помощью редактирования — не возможно.
Чтобы решить такой конфликт, надо просто выбрать — какая версия файла будет использоваться: ваша или из вливаемой ветки. Чтобы использовать свой вариант файла, вводим команду:
Если мы выбираем версию из вливаемой ветки:
Как посмотреть историю изменений
git log — просмотр логов.
Вывод данных о каждом коммите в одну строку:
Для вывода информации git log использует просмотрщик, указанный в конфиге репозитория.
Поиск по ключевому слову в комментариях к коммиту:
Можно посмотреть построчную информацию о последнем коммите, имя автора и хэш коммита:
git annotate, выводит измененные строки и информацию о коммитах, где это произошло:
Как сделать откат
- git log — просмотр логов, показывает дельту (разницу/diff), привнесенную каждым коммитом.
- Копируем идентификатор коммита, до которого происходит откат.
- Откатываемся до последнего успешного коммита (указываем последний коммит):
Можно откатить до последней версии ветки:
После того, как откат сделан, и выполнен очередной локальный коммит, при попытке сделать push в удаленный репозиторий, git может начать ругаться, что версия вашей ветки младше чем на github и вам надо сделать pull. Это лечится принудительным коммитом:
Как выполнить слияние с другой веткой
git merge выполняет слияние текущей и указанной ветки. Изменения добавляются в текущую ветку.
git pull забирает изменения из ветки на удаленном сервере и проводит слияние с активной веткой.
git pull отличается от git merge тем, что merge только выполняет слияние веток, а pull прежде чем выполнить слияние — закачивает изменения с удаленного сервера. merge удобно использовать для слияния веток в локальном репозитории, pull — слияния веток, когда одна из них лежит на github.
Создание нового локального репозитория
git cherry-pick
git cherry-pick помогает применить один-единственный коммит из одной ветки к дереву другой.
- Для этого нужно выписать ветку, в которую будем вливать коммит:
3. Выполнить команду, указать код коммита:
4. После этого обновить ветку на сервере:
Как раскрасить команды git
После создания репозитория в текущей директории появится субдиректория .git . Она содержит файл config .
Чтобы раскрасить вывод git, можно добавить в файл блок [color] :
Add colors to your ~/.gitconfig file:
Highlight whitespace in diffs
Add aliases to your ~/.gitconfig file:
[alias] st = status
ci = commit
br = branch
co = checkout
df = diff
dc = diff —cached
lg = log -p
lol = log —graph —decorate —pretty=oneline —abbrev-commit
lola = log —graph —decorate —pretty=oneline —abbrev-commit —all
ls = ls-files
git config -e [—global] edit the .git/config [or ~/.gitconfig] file in your $EDITOR
git config —global user.name ‘John Doe’
git config —global user.email [email protected]
sets your name and email for commit messages
git config core.autocrlf true
This setting tells git to convert the newlines to the system’s standard
when checking out files, and to LF newlines when committing in
git config —list
To view all options
git config apply.whitespace nowarn
To ignore whitespace
Info
—-
git reflog
Use this to recover from *major* mess ups! It’s basically a log of the
last few actions and you might have luck and find old commits that
have been lost by doing a complex merge.
git status
show files added to the staging area, files with changes, and untracked files
git show
show the changeset (diff) of a commit specified by , which can be any
SHA1 commit ID, branch name, or tag (shows the last commit (HEAD) by default)
also to show the contents of a file at a specific revision, use
git show :
this is similar to cat-file but much simpler syntax.
git show —name-only
show only the names of the files that changed, no diff information.
git blame
show who authored each line in
git blame
show who authored each line in as of (allows blame to go back in
time)
git gui blame
really nice GUI interface to git blame
git whatchanged
show only the commits which affected listing the most recent first
E.g. view all changes made to a file on a branch:
git whatchanged
| grep commit | \
colrm 1 7 | xargs -I % git show %
this could be combined with git remote show to find all changes on
all branches to a particular file.
git diff head path/to/fubar
show the diff between a file on the current branch and potentially another branch
git diff —cached [ ] shows diff for staged (git-add’ed) files (which includes uncommitted git cherry-pick’ed files)
git ls-files
list all files in the index and under version control.
git ls-remote [HEAD] show the current version on the remote repo. This can be used to check whether
a local is required by comparing the local head revision.
git add …
add , , etc… to the project
git add
add all files under directory to the project, including subdirectories
git add .
add all files under the current directory to the project
*WARNING*: including untracked files.
git rm …
remove , , etc… from the project
git rm $(git ls-files —deleted)
remove all deleted files from the project
git rm —cached …
commits absence of , , etc… from the project
Edit $GIT_DIR/.git/info/exclude. See Environment Variables below for explanation on $GIT_DIR.
Add a file .gitignore to the root of your project. This file will be checked in.
Either way you need to add patterns to exclude to these files.
git add …
git stage …
add changes in , … to the staging area (to be included in
the next commit
git add -p
git stage —patch
interactively walk through the current changes (hunks) in the working
tree, and decide which changes to add to the staging area.
git add -i
git stage —interactive
interactively add files/changes to the staging area. For a simpler
mode (no menu), try `git add —patch` (above)
git reset HEAD …
remove the specified files from the next commit
git commit … [-m ] commit , , etc…, optionally using commit message ,
otherwise opening your editor to let you type a commit message
git commit -a
commit all files changed since your last commit
(does not include new (untracked) files)
git commit -v
commit verbosely, i.e. includes the diff of the contents being committed in
the commit message screen
git commit —amend
edit the commit message of the most recent commit
git commit —amend …
redo previous commit, including changes made to , , etc…
git branch
list all local branches
git branch -r
list all remote branches
git branch -a
list all local and remote branches
create a new branch named
, referencing the same point in history as
the current branch
git branch
create a new branch named
, referencing , which may be
specified any way you like, including using a branch name or a tag name
git push :refs/heads/
git branch —track
create a tracking branch. Will push/pull changes to/from another repository.
Example: git branch —track experimental origin/experimental
git branch —set-upstream
(As of Git 1.7.0)
Make an existing branch track a remote branch
Example: git branch —set-upstream foo origin/foo
delete the branch
; if the branch you are deleting points to a
commit which is not reachable from the current branch, this command
will fail with a warning.
git branch -r -d
delete a remote-tracking branch.
Example: git branch -r -d wycats/master
even if the branch points to a commit not reachable from the current branch,
you may know that that commit is still reachable from some other branch or
tag. In that case it is safe to use this command to force git to delete the
branch.
make the current branch
, updating the working directory to reflect
the version referenced by
git checkout -b
create a new branch referencing , and check it out.
removes a branch from a remote repository.
Example: git push origin :old_branch_to_be_deleted
Checkout a file from another branch and add it to this branch. File
will still need to be added to the git branch, but it’s present.
Eg. git co remote_at_origin__tick702_antifraud_blocking …./…nt_elements_for_iframe_blocked_page.rb
Eg. git show remote_tick702 — path/to/fubar.txt
show the contents of a file that was created on another branch and that
does not exist on the current branch.
git show :
Show the contents of a file at the specific revision. Note: path has to be
absolute within the repo.
merge branch
into the current branch; this command is idempotent
and can be run as many times as needed to keep the current branch
up-to-date with changes in
git merge
—no-commit
merge branch
into the current branch, but do not autocommit the
result; allows you to make further tweaks
git merge
-s ours
merge branch
into the current branch, but drops any changes in
, using the current tree as the new tree
git cherry-pick [—edit] [-n] [-m parent-number] [-s] [-x]
selectively merge a single commit from another local branch
Example: git cherry-pick 7300a6130d9447e18a931e898b64eefedea19544
git hash-object
get the blob of some file whether it is in a repository or not
Find the commit in the repository that contains the file blob:
git mergetool
work through conflicted files by opening them in your mergetool (opendiff,
kdiff3, etc.) and choosing left/right chunks. The merged result is staged for
commit.
For binary files or if mergetool won’t do, resolve the conflict(s) manually
and then do:
Once all conflicts are resolved and staged, commit the pending merge with:
git push
update the server with your commits across all branches that are *COMMON*
between your local copy and the server. Local branches that were never
pushed to the server in the first place are not shared.
git push origin
git push origin
:refs/heads/
E.g. git push origin twitter-experiment:refs/heads/twitter-experiment
Which, in fact, is the same as git push origin
but a little
more obvious what is happening.
git checkout
re-checkout , overwriting any local changes
Fix mistakes / Undo
——————-
git reset —hard
abandon everything since your last commit; this command can be DANGEROUS.
If merging has resulted in conflicts and you’d like to just forget about
the merge, this command will do that.
git reset —soft HEAD^
forgot something in your last commit? That’s easy to fix. Undo your last
commit, but keep the changes in the staging area for editing.
git commit —amend
redo previous commit, including changes you’ve staged in the meantime.
Also used to edit commit message of previous commit.
test = $(git merge-base )
determine if merging sha1-B into sha1-A is achievable as a fast forward;
non-zero exit status is false.
git stash apply
restore the changes recorded in the stash on top of the current working tree
state
git stash pop
restore the changes from the most recent stash, and remove it from the stack
of stashed changes
git stash list
list all current stashes
git stash show -p
show the contents of a stash — accepts all diff args
git stash drop [ ] delete the stash
git stash clear
delete all current stashes
git push :refs/heads/
delete a branch in a remote repository
git push :refs/heads/
create a branch on a remote repository
Example: git push origin origin:refs/heads/new_feature_name
git push + :
replace a branch with
think twice before do this
Example: git push origin +master:my_branch
git remote show
show information about the remote server.
git checkout -b /
Eg.:
git checkout -b myfeature origin/myfeature
git checkout -b myfeature remotes/ /
Track a remote branch as a local branch. It seems that
somtimes an extra ‘remotes/’ is required, to see the exact
branch name, ‘git branch -a’.
git push
For branches that are remotely tracked (via git push) but
that complain about non-fast forward commits when doing a
git push. The pull synchronizes local and remote, and if
all goes well, the result is pushable.
git fetch
Retrieves all branches from the remote repository. After
this ‘git branch —track …’ can be used to track a branch
from the new remote.
git submodule add
add the given repository at the given path. The addition will be part of the
next commit.
git submodule update [—init] Update the registered submodules (clone missing submodules, and checkout
the commit specified by the super-repo). —init is needed the first time.
git submodule foreach
Executes the given command within each checked out submodule.
1. Delete the relevant line from the .gitmodules file.
2. Delete the relevant section from .git/config.
3. Run git rm —cached path_to_submodule (no trailing slash).
4. Commit and delete the now untracked submodule files.
Updating submodules
To update a submodule to a new commit:
1. update submodule:
cd
git pull
2. commit the new version of submodule:
cd
git format-patch HEAD^
Generate the last commit as a patch that can be applied on another
clone (or branch) using ‘git am’. Format patch can also generate a
patch for all commits using ‘git format-patch HEAD^ HEAD’
All page files will be enumerated with a prefix, e.g. 0001 is the
first patch.
git format-patch ^..
Generate a patch for a single commit. E.g.
git format-patch d8efce43099^..d8efce43099
Revision does not need to be fully specified.
Applies the patch file generated by format-patch.
git diff —no-prefix > patchfile
Generates a patch file that can be applied using patch:
patch -p0
Will checkout the code for a particular tag. After this you’ll
probably want to do: ‘git co -b ’ to define
a branch. Any changes you now make can be committed to that
branch and later merged.
git archive master | tar -x -C /somewhere/else
Will export expanded tree as tar archive at given path
git archive master | bzip2 > source-tree.tar.bz2
Will export archive as bz2
git archive —format zip —output /full/path master
Will export as zip
GIT_AUTHOR_NAME, GIT_COMMITTER_NAME
Your full name to be recorded in any newly created commits. Overrides
user.name in .git/config
GIT_AUTHOR_EMAIL, GIT_COMMITTER_EMAIL
Your email address to be recorded in any newly created commits. Overrides
user.email in .git/config
GIT_DIR
Location of the repository to use (for out of working directory repositories)
GIT_WORKING_TREE
Location of the Working Directory — use with GIT_DIR to specifiy the working directory root
or to work without being in the working directory at all.
Change author for all commits with given name
Читайте также: