Changes between Version 8 and Version 9 of ru/WorkingGuideLines


Ignore:
Timestamp:
06/16/09 21:17:05 (15 years ago)
Author:
angel_il
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • ru/WorkingGuideLines

    v8 v9  
    2727 $ # Упрощенный вариант тестирования: 
    2828 $ git checkout origin/123_branch_name 
    29  $ <собираем/тестируем> 
     29 $ <сборка/тестирование> 
    3030}}} 
    3131{{{ 
    … …  
    3535 $ git pull 
    3636 $ git merge --log --no-ff origin/123_branch_name 
    37  $ <собираем/тестируем> 
     37 $ <сборка/тестирование> 
    3838}}} 
    3939   * Если посмотреть на патч, то необходимо проверить: 
    … …  
    6969  $ git checkout master              // переключение на ветвь "master" 
    7070  $ git pull                         // обновление текущей ветви 
     71}}} 
     72 
     73  далее если ветвь состоит из единственного патча, а комментарий к нему содержит ссылку на тикет как было показано выше. 
     74{{{ 
     75  $ git merge --log 123_branch_name  // слияние с "master" той ветви которую необходимо слить 
     76}}} 
     77   
     78  либо если было несколько коммитов в ветви решающей проблему обозначенную в тикете. 
     79{{{ 
    7180  $ git merge --log --no-ff 123_branch_name  // слияние с "master" той ветви которую необходимо слить 
    72         // --log показывает в merge коммите список патчей, которые вводятся этим мержем 
    73         // --no-ff в этом случае генерируется merge коммит даже, если ветка является дочерней 
    74         //              от вершины родителя (по нем проще отслеживать какие патчи входили в решение данного тикета) 
    75         //              Это немного увеличит историю, но упростит дальнейшее ковыряние в ней. 
    76         // 
    77         //              Параметр можно опускать, если ветка состоит из единственного патча и комментарий к коммиту 
    78         //              содержит ссылку на баг на траке. В тривиальном случае перед вливанием в master можно произвести rebase. 
     81}}} 
     82   
     83  * опция --log показывает в merge коммите список патчей, которые вводятся этим мержем 
     84  * опция --no-ff позволяет сгенерировать merge коммит даже, если ветвь является дочерней от вершины родителя (по нему проще отследить какие патчи были сделаны в рамках данного тикета). Данная опция значительно упрощает понимание взаимосвязей коммитов. 
     85   
     86  далее: 
     87{{{ 
    7988  $ git push origin master           // обновление данных в удаленном репозитарии 
    8089  $ git push origin :123_branch_name // удаление ветви 123_branch_name на сервере  
    8190  $ git branch -d 123_branch_name    // локальное удаление ветви 123_branch_name на клиентском хосте    
    8291}}} 
     92 
     93  В тривиальном случае перед вливанием в master можно произвести rebase. 
     94примерно так 
     95{{{ 
     96  $ git rebase -i HEAD~4  //если коммитов было 4 
     97}}} 
     98  Узнать количество коммитов можно командой  
     99{{{ 
     100  $ git log 
     101}}} 
     102 
    83103   * Если слияние "merge" произошло с ошибкой (из-за конфликтов), то необходимо вручную исправить конфликты и продолжить слияние (merge). В идеале такого было не должно. Все тикеты _крайне_ желательно проверять предварительно смержив тестируемую ветку с той, в которую планируется ее добавить; иначе в ветку попадает другой код (который в некоторых случаях не только не работает, но даже и не собирается). 
    84104   * Теперь вы можете просто закрыть тикет с причиной закрытия "Fixed" (исправлено), необходимо также добавить ключевое слово '''commited-master''', если слияние происходило с ветвью "master". Состояние тикета поменяется на "testing".