Skip to content

Instantly share code, notes, and snippets.

@InsaneLuv

InsaneLuv/gist:69d0c86907edbb11e9317a696c5038bf

Forked from digitaljhelms/gist:4287848
Last active November 28, 2024 08:57
Show Gist options
  • Save InsaneLuv/69d0c86907edbb11e9317a696c5038bf to your computer and use it in GitHub Desktop.
Save InsaneLuv/69d0c86907edbb11e9317a696c5038bf to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. InsaneLuv revised this gist Nov 28, 2024. 1 changed file with 89 additions and 118 deletions.
    207 changes: 89 additions & 118 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -1,182 +1,153 @@
    # Branching

    ## Quick Legend

    <table>
    <thead>
    <tr>
    <th>Instance</th>
    <th>Branch</th>
    <th>Description, Instructions, Notes</th>
    </tr>
    </thead>
    <tbody>
    <tr>
    <td>Stable</td>
    <td>stable</td>
    <td>Accepts merges from Working and Hotfixes</td>
    </tr>
    <tr>
    <td>Working</td>
    <td>master</td>
    <td>Accepts merges from Features/Issues and Hotfixes</td>
    </tr>
    <tr>
    <td>Features/Issues</td>
    <td>topic-*</td>
    <td>Always branch off HEAD of Working</td>
    </tr>
    <tr>
    <td>Hotfix</td>
    <td>hotfix-*</td>
    <td>Always branch off Stable</td>
    </tr>
    </tbody>
    </table>

    ## Main Branches

    The main repository will always hold two evergreen branches:
    # Ветвление (Branching)

    ## Введение

    <table> <thead> <tr> <th>Экземпляр</th> <th>Ветка</th> <th>Описание, Инструкции, Примечания</th> </tr> </thead> <tbody> <tr> <td>Stable (Стабильная)</td> <td>stable</td> <td>Принимает слияния из Working (Рабочей) и Hotfixes (Горячих исправлений)</td> </tr> <tr> <td>Working (Рабочая)</td> <td>master</td> <td>Принимает слияния из Features/Issues (Функций/Задач) и Hotfixes (Горячих исправлений)</td> </tr> <tr> <td>Features/Issues (Функции/Задачи)</td> <td>topic-*</td> <td>Всегда создаются от HEAD ветки Working (Рабочей)</td> </tr> <tr> <td>Hotfix (Горячее исправление)</td> <td>hotfix-*</td> <td>Всегда создаются от Stable (Стабильной)</td> </tr> </tbody> </table>

    ## Основные Ветки

    Основной репозиторий всегда будет содержать две постоянные ветки:

    * `master`
    * `stable`

    The main branch should be considered `origin/master` and will be the main branch where the source code of `HEAD` always reflects a state with the latest delivered development changes for the next release. As a developer, you will be branching and merging from `master`.
    Основной следует считать `origin/master` она будет веткой, где исходный код `HEAD` всегда отражает состояние с последними внесенными изменениями для следующего релиза. Как разработчик, вы будете создавать ветки и сливать(merge) их в ветку `master`.

    Consider `origin/stable` to always represent the latest code deployed to production. During day to day development, the `stable` branch will not be interacted with.
    `origin/stable` - Считается тем кодом, который развернут в продакшене на данный момент. В повседневной разработке с веткой `stable` вы не должны взаимодействовать.

    When the source code in the `master` branch is stable and has been deployed, all of the changes will be merged into `stable` and tagged with a release number. *How this is done in detail will be discussed later.*
    Когда исходный код в ветке `master` стабилен и был развернут, ветка `master` будет слита(merge) в ветку `stable` и помечена номером релиза. *Как это делается подробно будет обсуждено позже.*

    ## Supporting Branches
    ## Ветки-Поддержка

    Supporting branches are used to aid parallel development between team members, ease tracking of features, and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited life time, since they will be removed eventually.
    Поддерживающие ветки используются для параллельной разработки между участниками команды, упрощения отслеживания функций и для быстрого исправления проблем в живом продакшене. В отличие от основных веток, эти ветки всегда имеют ограниченный срок жизни, так как они будут удалены в конечном итоге.

    The different types of branches we may use are:
    Различные типы веток, которые мы можем использовать:

    * Feature branches
    * Bug branches
    * Hotfix branches
    * Feature ветки
    * Bug ветки
    * Hotfix ветки

    Each of these branches have a specific purpose and are bound to strict rules as to which branches may be their originating branch and which branches must be their merge targets. Each branch and its usage is explained below.
    Каждая из этих веток имеет конкретное назначение и подчиняется строгим правилам относительно того, от каких веток они могут исходить и в какие ветки должны сливаться. *Каждая ветка и её использование объяснены ниже.*

    ### Feature Branches
    ### Ветки Feature

    Feature branches are used when developing a new feature or enhancement which has the potential of a development lifespan longer than a single deployment. When starting development, the deployment in which this feature will be released may not be known. No matter when the feature branch will be finished, it will always be merged back into the master branch.
    Ветки Feature используются при разработке новой функции или улучшения, которое может иметь продолжительный жизненный цикл разработки, превышающий один выпуск. При начале разработки деплоймент, в котором эта функция будет выпущена, может быть неизвестен. Независимо от того, когда ветка Feature будет завершена, она всегда будет слита обратно в ветку `master`.

    During the lifespan of the feature development, the lead should watch the `master` branch (network tool or branch tool in GitHub) to see if there have been commits since the feature was branched. Any and all changes to `master` should be merged into the feature before merging back to `master`; this can be done at various times during the project or at the end, but time to handle merge conflicts should be accounted for.
    В течение жизненного цикла разработки функции тимлид должен следить за веткой `master` (с помощью сетевого инструмента или инструмента веток в GitHub), чтобы видеть, были ли коммиты с момента создания ветки Feature. Все изменения в `master` должны быть слиты в ветку Feature перед слиянием обратно в `master`; это можно сделать в разное время во время проекта или в конце, но время на разрешение конфликтов при слиянии должно быть учтено.

    `<tbd number>` represents the project to which Project Management will be tracked.
    `<tbd number>` представляет проект, к которому будет привязываться управление проектом.

    * Must branch from: `master`
    * Must merge back into: `master`
    * Branch naming convention: `feature-<tbd number>`
    * Должна создаваться от: `master`
    * Должна сливаться обратно в: `master`
    * Правила именования веток: `feature-<tbd number>`

    #### Working with a feature branch
    #### Работа с Feature веткой

    If the branch does not exist yet (check with the Lead), create the branch locally and then push to GitHub. A feature branch should always be 'publicly' available. That is, development should never exist in just one developer's local branch.
    Если ветка ещё не существует (узнайте у тимлида), создайте ветку локально, а затем отправьте её в GitHub. Ветка Feature обычно является "публичной" или "публичной" в рамках команды. То есть, разработка никогда не должна существовать только в локальной ветке одного разработчика.

    ```
    $ git checkout -b feature-id master // creates a local branch for the new feature
    $ git push origin feature-id // makes the new feature remotely available
    $ git checkout -b feature-id master // создаёт локальную ветку для новой функции
    $ git push origin feature-id // делает новую функцию доступной удалённо
    ```

    Periodically, changes made to `master` (if any) should be merged back into your feature branch.

    Периодически изменения, внесённые в `master` (если есть), должны быть слиты обратно в вашу ветку Feature.
    ```
    $ git merge master // merges changes from master into feature branch
    $ git merge master // сливает изменения из master в ветку Feature
    ```

    When development on the feature is complete, the lead (or engineer in charge) should merge changes into `master` and then make sure the remote branch is deleted.

    Когда разработка функции завершена, тимлид (или другой ответственный) должен слиять ветку в `master` и затем убедиться, что удалённая ветка удалена.
    ```
    $ git checkout master // change to the master branch
    $ git merge --no-ff feature-id // makes sure to create a commit object during merge
    $ git push origin master // push merge changes
    $ git push origin :feature-id // deletes the remote branch
    $ git checkout master // переключиться на ветку master
    $ git merge --no-ff feature-id // гарантирует создание объекта коммита при слиянии
    $ git push origin master // отправить изменения слияния
    $ git push origin :feature-id // удалить удалённую ветку
    ```

    ### Bug Branches

    Bug branches differ from feature branches only semantically. Bug branches will be created when there is a bug on the live site that should be fixed and merged into the next deployment. For that reason, a bug branch typically will not last longer than one deployment cycle. Additionally, bug branches are used to explicitly track the difference between bug development and feature development. No matter when the bug branch will be finished, it will always be merged back into `master`.
    ### Ветки Bug

    Although likelihood will be less, during the lifespan of the bug development, the lead should watch the `master` branch (network tool or branch tool in GitHub) to see if there have been commits since the bug was branched. Any and all changes to `master` should be merged into the bug before merging back to `master`; this can be done at various times during the project or at the end, but time to handle merge conflicts should be accounted for.
    Ветки Bug отличаются от веток Feature только семантически. Ветки Bug создаются, когда на живом сайте обнаружена ошибка, которую необходимо исправить и слиять в следующий деплоймент. По этой причине ветка Bug обычно не будет существовать дольше одного цикла деплоймента. Кроме того, ветки Bug используются для явного отслеживания различий между разработкой ошибок и разработкой функций. Независимо от того, когда ветка Bug будет завершена, она всегда будет слита обратно в `master`.

    `<tbd number>` represents the Basecamp project to which Project Management will be tracked.
    Хотя вероятность меньше, в течение жизненного цикла разработки ошибки тимлид должен следить за веткой `master` (с помощью сетевого инструмента или инструмента веток в GitHub), чтобы видеть, были ли коммиты с момента создания ветки Bug. Все изменения в `master` должны быть слиты в ветку Bug перед слиянием обратно в `master`; это можно сделать в разное время во время проекта или в конце, но время на разрешение конфликтов при слиянии должно быть учтено.

    * Must branch from: `master`
    * Must merge back into: `master`
    * Branch naming convention: `bug-<tbd number>`
    `<tbd number>` представляет проект Basecamp, к которому будет привязываться управление проектом.

    #### Working with a bug branch
    * Должна создаваться от: `master`
    * Должна сливаться обратно в: `master`
    * Правила именования веток: `bug-<tbd number>`

    #### Работа с веткой Bug

    If the branch does not exist yet (check with the Lead), create the branch locally and then push to GitHub. A bug branch should always be 'publicly' available. That is, development should never exist in just one developer's local branch.
    Если ветка ещё не существует (узнайте у тимлида), создайте ветку локально, а затем отправьте её в GitHub. Ветка Bug всегда должна быть "публичной" или "публичной" в рамках команды. То есть, разработка никогда не должна существовать только в локальной ветке одного разработчика.

    ```
    $ git checkout -b bug-id master // creates a local branch for the new bug
    $ git push origin bug-id // makes the new bug remotely available
    $ git checkout -b bug-id master // создаёт локальную ветку для новой ошибки
    $ git push origin bug-id // делает новую ошибку доступной удалённо
    ```

    Periodically, changes made to `master` (if any) should be merged back into your bug branch.
    Периодически изменения, внесённые в `master` (если есть), должны быть слиты обратно в вашу ветку Bug.

    ```
    $ git merge master // merges changes from master into bug branch
    $ git merge master // сливает изменения из master в ветку Bug
    ```

    When development on the bug is complete, [the Lead] should merge changes into `master` and then make sure the remote branch is deleted.

    Когда разработка ошибки завершена, [Тимлид] должен слиять ветку и изменения в `master` и затем убедиться, что удалённая ветка удалена.
    ```
    $ git checkout master // change to the master branch
    $ git merge --no-ff bug-id // makes sure to create a commit object during merge
    $ git push origin master // push merge changes
    $ git push origin :bug-id // deletes the remote branch
    $ git checkout master // переключиться на ветку master
    $ git merge --no-ff bug-id // гарантирует создание объекта коммита при слиянии
    $ git push origin master // отправить изменения слияния
    $ git push origin :bug-id // удалить удалённую ветку
    ```

    ### Hotfix Branches

    A hotfix branch comes from the need to act immediately upon an undesired state of a live production version. Additionally, because of the urgency, a hotfix is not required to be be pushed during a scheduled deployment. Due to these requirements, a hotfix branch is always branched from a tagged `stable` branch. This is done for two reasons:

    * Development on the `master` branch can continue while the hotfix is being addressed.
    * A tagged `stable` branch still represents what is in production. At the point in time where a hotfix is needed, there could have been multiple commits to `master` which would then no longer represent production.

    `<tbd number>` represents the Basecamp project to which Project Management will be tracked.
    Ветка Hotfix создаётся из необходимости немедленно реагировать на нежелательное состояние живой продакшн-версии. Кроме того, из-за срочности, ветка Hotfix не обязана быть слита во время планового деплоймента. Из-за этих требований ветка Hotfix всегда создаётся от помеченной ветки `stable`. Это делается по двум причинам:

    * Must branch from: tagged `stable`
    * Must merge back into: `master` and `stable`
    * Branch naming convention: `hotfix-<tbd number>`
    * Разработка в ветке `master` может продолжаться, пока решается Hotfix.
    * Помеченная ветка `stable` всё ещё представляет то, что находится в продакшене. В момент, когда Hotfix необходим, могли быть сделаны несколько коммитов в `master`, которые больше не будут представлять продакшн.

    #### Working with a hotfix branch
    <tbd number> представляет проект Basecamp, к которому будет привязываться управление проектом.

    If the branch does not exist yet (check with the Lead), create the branch locally and then push to GitHub. A hotfix branch should always be 'publicly' available. That is, development should never exist in just one developer's local branch.
    * Должна создаваться от: помеченной ветки `stable`
    * Должна сливаться обратно в: `master` и `stable`
    * Правила именования веток: `hotfix-<tbd number>`

    #### Работа с веткой Hotfix
    Если ветка ещё не существует (узнайте у тимлида), создайте ветку локально, а затем отправьте её в GitHub. Ветка Hotfix всегда должна быть "публичной". То есть, разработка никогда не должна существовать только в локальной ветке одного разработчика.

    ```
    $ git checkout -b hotfix-id stable // creates a local branch for the new hotfix
    $ git push origin hotfix-id // makes the new hotfix remotely available
    ```
    $ git checkout -b hotfix-id stable // создаёт локальную ветку для нового горячего исправления
    $ git push origin hotfix-id // делает новое горячее исправление доступным удалённо
    When development on the hotfix is complete, [the Lead] should merge changes into `stable` and then update the tag.
    ```

    Когда разработка Hotfix завершена, [тимлид] должен слиять ветку и изменения в `stable` и затем обновить тег.

    ```
    $ git checkout stable // change to the stable branch
    $ git merge --no-ff hotfix-id // forces creation of commit object during merge
    $ git tag -a <tag> // tags the fix
    $ git push origin stable --tags // push tag changes
    $ git checkout stable // переключиться на ветку stable
    $ git merge --no-ff hotfix-id // гарантирует создание объекта коммита при слиянии
    $ git tag -a <tag> // помечает исправление
    $ git push origin stable --tags // отправляет изменения тегов
    ```

    Merge changes into `master` so not to lose the hotfix and then delete the remote hotfix branch.
    Слияйте ветку с изменениями в `master`, чтобы не потерять Hotfix, а затем удалите удалённую ветку Hotfix.

    ```
    $ git checkout master // change to the master branch
    $ git merge --no-ff hotfix-id // forces creation of commit object during merge
    $ git push origin master // push merge changes
    $ git push origin :hotfix-id // deletes the remote branch
    $ git checkout master // переключиться на ветку master
    $ git merge --no-ff hotfix-id // гарантирует создание объекта коммита при слиянии
    $ git push origin master // отправить изменения слияния
    $ git push origin :hotfix-id // удалить удалённую ветку
    ```

    ## Workflow Diagram
    ## Диаграмма Рабочего Процесса

    ![Git Branching Model](https://raw.githubusercontent.com/digitaljhelms/public/master/gitflow-model.png)
    *[gitflow-model.src.key](https://github.com/digitaljhelms/public/raw/master/gitflow-model.src.key)*

    ## Other Material
    ## Прочие Материалы

    * [Git/GitHub commit standards & conventions](https://gist.github.com/digitaljhelms/3761873)
    * [A successful Git branching model](https://nvie.com/posts/a-successful-git-branching-model/) (the basis for this flow model)
    * [Стандарты и соглашения по коммитам Git/GitHub](https://gist.github.com/digitaljhelms/3761873)
    * [Успешная модель ветвления Git (основа этой модели потока)](https://nvie.com/posts/a-successful-git-branching-model/) (основа)
  2. @digitaljhelms digitaljhelms revised this gist Mar 25, 2021. 1 changed file with 2 additions and 1 deletion.
    3 changes: 2 additions & 1 deletion gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -178,4 +178,5 @@ $ git push origin :hotfix-id // deletes the remote branch

    ## Other Material

    * [Git/GitHub commit standards & conventions](https://gist.github.com/digitaljhelms/3761873)
    * [Git/GitHub commit standards & conventions](https://gist.github.com/digitaljhelms/3761873)
    * [A successful Git branching model](https://nvie.com/posts/a-successful-git-branching-model/) (the basis for this flow model)
  3. @digitaljhelms digitaljhelms revised this gist Mar 24, 2021. 1 changed file with 6 additions and 2 deletions.
    8 changes: 6 additions & 2 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -173,5 +173,9 @@ $ git push origin :hotfix-id // deletes the remote branch

    ## Workflow Diagram

    ![Git Branching Model](http://f.cl.ly/items/3i1Z3n1T1k392r1A3Q0m/gitflow-model.001.png)
    *[gitflow-model.src.key](http://cl.ly/3V1b0c2F1H4024173S1M)*
    ![Git Branching Model](https://raw.githubusercontent.com/digitaljhelms/public/master/gitflow-model.png)
    *[gitflow-model.src.key](https://github.com/digitaljhelms/public/raw/master/gitflow-model.src.key)*

    ## Other Material

    * [Git/GitHub commit standards & conventions](https://gist.github.com/digitaljhelms/3761873)
  4. @digitaljhelms digitaljhelms revised this gist Mar 4, 2019. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -101,7 +101,7 @@ Bug branches differ from feature branches only semantically. Bug branches will b

    Although likelihood will be less, during the lifespan of the bug development, the lead should watch the `master` branch (network tool or branch tool in GitHub) to see if there have been commits since the bug was branched. Any and all changes to `master` should be merged into the bug before merging back to `master`; this can be done at various times during the project or at the end, but time to handle merge conflicts should be accounted for.

    <tbd number> represents the Basecamp project to which Project Management will be tracked.
    `<tbd number>` represents the Basecamp project to which Project Management will be tracked.

    * Must branch from: `master`
    * Must merge back into: `master`
    @@ -138,7 +138,7 @@ A hotfix branch comes from the need to act immediately upon an undesired state o
    * Development on the `master` branch can continue while the hotfix is being addressed.
    * A tagged `stable` branch still represents what is in production. At the point in time where a hotfix is needed, there could have been multiple commits to `master` which would then no longer represent production.

    <tbd number> represents the Basecamp project to which Project Management will be tracked.
    `<tbd number>` represents the Basecamp project to which Project Management will be tracked.

    * Must branch from: tagged `stable`
    * Must merge back into: `master` and `stable`
  5. @digitaljhelms digitaljhelms revised this gist Mar 4, 2019. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -65,7 +65,7 @@ Feature branches are used when developing a new feature or enhancement which has

    During the lifespan of the feature development, the lead should watch the `master` branch (network tool or branch tool in GitHub) to see if there have been commits since the feature was branched. Any and all changes to `master` should be merged into the feature before merging back to `master`; this can be done at various times during the project or at the end, but time to handle merge conflicts should be accounted for.

    <tbd number> represents the Basecamp project to which Project Management will be tracked.
    `<tbd number>` represents the project to which Project Management will be tracked.

    * Must branch from: `master`
    * Must merge back into: `master`
  6. @digitaljhelms digitaljhelms revised this gist Mar 4, 2019. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -41,7 +41,7 @@ The main repository will always hold two evergreen branches:
    * `master`
    * `stable`

    The main branch should be considered `origin/master` and will be the main branch where the source code of `HEAD` always reflects a state with the latest delivered development changes for the next release. As a developer, you will you be branching and merging from `master`.
    The main branch should be considered `origin/master` and will be the main branch where the source code of `HEAD` always reflects a state with the latest delivered development changes for the next release. As a developer, you will be branching and merging from `master`.

    Consider `origin/stable` to always represent the latest code deployed to production. During day to day development, the `stable` branch will not be interacted with.

  7. @digitaljhelms digitaljhelms created this gist Dec 14, 2012.
    177 changes: 177 additions & 0 deletions gistfile1.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,177 @@
    # Branching

    ## Quick Legend

    <table>
    <thead>
    <tr>
    <th>Instance</th>
    <th>Branch</th>
    <th>Description, Instructions, Notes</th>
    </tr>
    </thead>
    <tbody>
    <tr>
    <td>Stable</td>
    <td>stable</td>
    <td>Accepts merges from Working and Hotfixes</td>
    </tr>
    <tr>
    <td>Working</td>
    <td>master</td>
    <td>Accepts merges from Features/Issues and Hotfixes</td>
    </tr>
    <tr>
    <td>Features/Issues</td>
    <td>topic-*</td>
    <td>Always branch off HEAD of Working</td>
    </tr>
    <tr>
    <td>Hotfix</td>
    <td>hotfix-*</td>
    <td>Always branch off Stable</td>
    </tr>
    </tbody>
    </table>

    ## Main Branches

    The main repository will always hold two evergreen branches:

    * `master`
    * `stable`

    The main branch should be considered `origin/master` and will be the main branch where the source code of `HEAD` always reflects a state with the latest delivered development changes for the next release. As a developer, you will you be branching and merging from `master`.

    Consider `origin/stable` to always represent the latest code deployed to production. During day to day development, the `stable` branch will not be interacted with.

    When the source code in the `master` branch is stable and has been deployed, all of the changes will be merged into `stable` and tagged with a release number. *How this is done in detail will be discussed later.*

    ## Supporting Branches

    Supporting branches are used to aid parallel development between team members, ease tracking of features, and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited life time, since they will be removed eventually.

    The different types of branches we may use are:

    * Feature branches
    * Bug branches
    * Hotfix branches

    Each of these branches have a specific purpose and are bound to strict rules as to which branches may be their originating branch and which branches must be their merge targets. Each branch and its usage is explained below.

    ### Feature Branches

    Feature branches are used when developing a new feature or enhancement which has the potential of a development lifespan longer than a single deployment. When starting development, the deployment in which this feature will be released may not be known. No matter when the feature branch will be finished, it will always be merged back into the master branch.

    During the lifespan of the feature development, the lead should watch the `master` branch (network tool or branch tool in GitHub) to see if there have been commits since the feature was branched. Any and all changes to `master` should be merged into the feature before merging back to `master`; this can be done at various times during the project or at the end, but time to handle merge conflicts should be accounted for.

    <tbd number> represents the Basecamp project to which Project Management will be tracked.

    * Must branch from: `master`
    * Must merge back into: `master`
    * Branch naming convention: `feature-<tbd number>`

    #### Working with a feature branch

    If the branch does not exist yet (check with the Lead), create the branch locally and then push to GitHub. A feature branch should always be 'publicly' available. That is, development should never exist in just one developer's local branch.

    ```
    $ git checkout -b feature-id master // creates a local branch for the new feature
    $ git push origin feature-id // makes the new feature remotely available
    ```

    Periodically, changes made to `master` (if any) should be merged back into your feature branch.

    ```
    $ git merge master // merges changes from master into feature branch
    ```

    When development on the feature is complete, the lead (or engineer in charge) should merge changes into `master` and then make sure the remote branch is deleted.

    ```
    $ git checkout master // change to the master branch
    $ git merge --no-ff feature-id // makes sure to create a commit object during merge
    $ git push origin master // push merge changes
    $ git push origin :feature-id // deletes the remote branch
    ```

    ### Bug Branches

    Bug branches differ from feature branches only semantically. Bug branches will be created when there is a bug on the live site that should be fixed and merged into the next deployment. For that reason, a bug branch typically will not last longer than one deployment cycle. Additionally, bug branches are used to explicitly track the difference between bug development and feature development. No matter when the bug branch will be finished, it will always be merged back into `master`.

    Although likelihood will be less, during the lifespan of the bug development, the lead should watch the `master` branch (network tool or branch tool in GitHub) to see if there have been commits since the bug was branched. Any and all changes to `master` should be merged into the bug before merging back to `master`; this can be done at various times during the project or at the end, but time to handle merge conflicts should be accounted for.

    <tbd number> represents the Basecamp project to which Project Management will be tracked.

    * Must branch from: `master`
    * Must merge back into: `master`
    * Branch naming convention: `bug-<tbd number>`

    #### Working with a bug branch

    If the branch does not exist yet (check with the Lead), create the branch locally and then push to GitHub. A bug branch should always be 'publicly' available. That is, development should never exist in just one developer's local branch.

    ```
    $ git checkout -b bug-id master // creates a local branch for the new bug
    $ git push origin bug-id // makes the new bug remotely available
    ```

    Periodically, changes made to `master` (if any) should be merged back into your bug branch.

    ```
    $ git merge master // merges changes from master into bug branch
    ```

    When development on the bug is complete, [the Lead] should merge changes into `master` and then make sure the remote branch is deleted.

    ```
    $ git checkout master // change to the master branch
    $ git merge --no-ff bug-id // makes sure to create a commit object during merge
    $ git push origin master // push merge changes
    $ git push origin :bug-id // deletes the remote branch
    ```

    ### Hotfix Branches

    A hotfix branch comes from the need to act immediately upon an undesired state of a live production version. Additionally, because of the urgency, a hotfix is not required to be be pushed during a scheduled deployment. Due to these requirements, a hotfix branch is always branched from a tagged `stable` branch. This is done for two reasons:

    * Development on the `master` branch can continue while the hotfix is being addressed.
    * A tagged `stable` branch still represents what is in production. At the point in time where a hotfix is needed, there could have been multiple commits to `master` which would then no longer represent production.

    <tbd number> represents the Basecamp project to which Project Management will be tracked.

    * Must branch from: tagged `stable`
    * Must merge back into: `master` and `stable`
    * Branch naming convention: `hotfix-<tbd number>`

    #### Working with a hotfix branch

    If the branch does not exist yet (check with the Lead), create the branch locally and then push to GitHub. A hotfix branch should always be 'publicly' available. That is, development should never exist in just one developer's local branch.

    ```
    $ git checkout -b hotfix-id stable // creates a local branch for the new hotfix
    $ git push origin hotfix-id // makes the new hotfix remotely available
    ```

    When development on the hotfix is complete, [the Lead] should merge changes into `stable` and then update the tag.

    ```
    $ git checkout stable // change to the stable branch
    $ git merge --no-ff hotfix-id // forces creation of commit object during merge
    $ git tag -a <tag> // tags the fix
    $ git push origin stable --tags // push tag changes
    ```

    Merge changes into `master` so not to lose the hotfix and then delete the remote hotfix branch.

    ```
    $ git checkout master // change to the master branch
    $ git merge --no-ff hotfix-id // forces creation of commit object during merge
    $ git push origin master // push merge changes
    $ git push origin :hotfix-id // deletes the remote branch
    ```

    ## Workflow Diagram

    ![Git Branching Model](http://f.cl.ly/items/3i1Z3n1T1k392r1A3Q0m/gitflow-model.001.png)
    *[gitflow-model.src.key](http://cl.ly/3V1b0c2F1H4024173S1M)*