Статьи

Git-оценка: как использовать ветки

Октябрь 26, 2017

Я видел гит-оценку Google на Proggit на днях . У Hacker News было больше комментариев на то же самое.

Супер-круто — совместный обзор кода хранится в системе контроля версий. Я давно этого хотел. Вот как это работает:

$ git clone [email protected]:google/git-appraise.git
Cloning into 'git-appraise'...
remote: Counting objects: 543, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 543 (delta 0), reused 0 (delta 0), pack-reused 539
Receiving objects: 100% (543/543), 169.78 KiB | 0 bytes/s, done.
Resolving deltas: 100% (265/265), done.
Checking connectivity... done.

$ cd git-appraise/

$ git appraise list
Loaded 0 open reviews:

$ git fetch origin refs/notes/*:refs/notes/*
remote: Counting objects: 833, done.
remote: Compressing objects: 100% (42/42), done.
remote: Total 833 (delta 21), reused 0 (delta 0), pack-reused 791
Receiving objects: 100% (833/833), 117.92 KiB | 0 bytes/s, done.
Resolving deltas: 100% (398/398), done.
From github.com:google/git-appraise
 * [new ref]         refs/notes/devtools/analyses -> refs/notes/devtools/analyses
 * [new ref]         refs/notes/devtools/ci -> refs/notes/devtools/ci
 * [new ref]         refs/notes/devtools/discuss -> refs/notes/devtools/discuss
 * [new ref]         refs/notes/devtools/reviews -> refs/notes/devtools/reviews

$ git appraise list
Loaded 1 open reviews:
[pending] 2c9bff89f0f8
  Improve the error messages returned when a git command fails.

  Previously, we were simply cascading the error returned by the instance
  of exec.Command. However, that winds up just being something of the form
  "exit status 128", with all of the real error message going to the
  Stderr field.

  As such, this commit changes the behavior to save the data written to
  stderr, and use it to construct a new error to return.

Реализация Git-appraise не использует обычную ветку с текстовыми ресурсами для обзора, что было бы моим предпочтением. Он использует refs / notes / devtools / reviews в качестве магазина. В списке ветвей отображаются только основная ветвь и ветвь функций:

Действительно, интерфейс GitHub должен позволять вам перемещаться по этим текстовым ресурсам в ветке. Я писал об этом раньше . В идеале я также мог бы подключить сторонний плагин к веб-интерфейсу GitHub и иметь полезную навигацию по обзорам.

Филиалы или Репо?

Классическая лучшая практика заключается в том, что ветки должны быть для изменения политики в одном источнике. Политика может быть любой / все из:

  • группы могут / не могут видеть ветку против другой ветки
  • группы могут / не могут зарегистрироваться в ветви против другой ветви
  • Ветка содержит материал для конкретной версии (и не далее)
  • ветвь содержит незавершенную работу по некоторым функциональным или нефункциональным изменениям, с переменным уровнем детализации

Вообще говоря, ветви всегда должны быть объединяемыми друг с другом, с политикой, определяющей, следует ли вам / не следует (можете / не можете, если у вашего СКМ есть разрешения в некоторой степени).

Github Страницы (Филиалы)

Предложение для GitHub страницы используется, чтобы иметь его на ветви GH-страницы, рядом с вашей основной ветви (который содержит код). Конечно, для чистого блога или сайта у вас может быть только контент Github Pages и вообще нет программного источника. Действительно, в этой конфигурации вам вообще не нужна ветка gh-pages. Я нахожу ветку gh-pages немного странной, как бы ни были замечательны технологии. Слияние между gh-paged ветвью и нелогичным мастером — моя настойчивая мысль.

Как видно из названия, ветки должны быть для смены политики на одном источнике.

Реализация GitHub в вики (Repos)

Github implemented Wiki differently: as a first class repo, that follows a naming convention association with the repo it is associated with. D3’s repo can be cloned from [email protected]:mbostock/d3.git and its wiki from https://github.com/mbostock/d3.wiki.git. This is great. Less than great is the the fact that the Github web interface doesn’t allow you to navigate the revisions of pages, or see diffs etc. That would be so easy for them to implement. This is how Github Pages should have been implemented, in my opinion.

In summary, the wiki implementation is done right, given it is not a branch.

Git Appraise (Neither)

It’s being stored in refs/notes/devtools/reviews as mentioned. My thoughts:

  • Should be a first class SCMed set of text files, in my opinion, allowing merge amongst other things
  • Would be best not represented as a branch with a different policy to the thing it is reviewing
  • Should have be navigable in the same web-UI as the regular code

39
Share: