🌍
English
Differences
This shows you the differences between two versions of the page.
|
dev:core:git [2014/11/07 10:44] mistic100 |
— (current) | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | <WRAP round tip> | ||
| - | This is a work in progress, all concepts exposed here are susceptible to change. | ||
| - | </WRAP> | ||
| - | |||
| - | ====== Git workflow and best pratices ====== | ||
| - | |||
| - | ===== Reminder ===== | ||
| - | |||
| - | On Piwigo we typically have two active branches: | ||
| - | * ''trunk'' holds the main source code with features for the next major version | ||
| - | * ''2.7'' (in instance) holds the source code of the current major version, only bug fixes and minor features are pushed to this branch | ||
| - | |||
| - | As the SVN concept of branches is very loose we used to develop either on ''master'' or ''2.7'' and then merge specific commits to the other branch if needed. This concept is totally applicable in Git, it's called **cherry pick**. | ||
| - | |||
| - | **But this is not how Git is supposed to work.** Git tends to track every changes, and links them to others, and because **cherry pick** basically forge a new commit from another one, a part of the history is lost. | ||
| - | |||
| - | ===== Workflow ===== | ||
| - | |||
| - | The workflow we follow is the one described by Vincent Driessen in his excellent article [[http://nvie.com/posts/a-successful-git-branching-model|A successful Git branching model]]. | ||
| - | |||
| - | {{http://nvie.com/img/git-model@2x.png?575}} | ||
| - | |||
| - | **Don't worry** it's actually very simple. There are five types of branches. | ||
| - | ===''master''== | ||
| - | Contains the latest **stable** version of the source code. Production tags are created on this branch. **Never commit on this branch.** | ||
| - | |||
| - | ===''develop''== | ||
| - | Contains the latest **development** code. It's like the ''trunk'' on Subversion. **It is advised to only make small commits on this branch**, prefer using a ''bug-'' or ''feature-'' branch. | ||
| - | |||
| - | === Release branches (''2.7'' for instance) === | ||
| - | Contain the code of a specific major version and all its minor versions. It is initiated by a single commit making necessary changes (version change, production config, etc.). Like ''develop'' **it's advised to only make small commits on this branch**. | ||
| - | |||
| - | Remember that we NEVER make database changes in minor releases, neither we add translatable strings. | ||
| - | |||
| - | When a new version is released, the branch **must** be merged in ''master'' and a tag created (on master). | ||
| - | |||
| - | ===''bug-''=== | ||
| - | Are used to... fix bugs. Create one bug branch by bug. It should be named after a specific issue number (eg: ''bug-1324''). | ||
| - | |||
| - | Once the fix is ready it **must** be merged in ''develop'' and generally the current release branch.\\ | ||
| - | You notice that, unlike Vincent Dressen, we don't merge bug fixes in ''master'' but in the current branch, which is then merged back into ''master'' when ready. | ||
| - | |||
| - | Don't forget to delete the branch locally and remotely when finished. | ||
| - | |||
| - | ===''feature-''=== | ||
| - | Almost the same as ''bug-'' but for new features. It can be named after a specific issue number, or an arbitrary name for unlisted features. | ||
| - | |||
| - | Once the feature is ready it **must** be merge in ''develop'' and in the current release branch **only** if it's a minor feature. | ||
| - | |||
| - | |||
| - | ===== Best pratices ===== | ||
| - | |||
| - | These are some random advices you **should** really apply in order to have a clean Git history. | ||
| - | |||
| - | ==== No fast-forward ==== | ||
| - | When merging a branch into another, the default behavior of Git is to fast-forward it, that means if no changes has been made on the target branch, the source branch will simply disappear from the tree, making it difficult to localize merging point. | ||
| - | |||
| - | By adding the ''--no-ff'' option to ''git merge'' you will force Git to create an empty technical commit when merging. | ||
| - | |||
| - | {{http://nvie.com/img/merge-without-ff@2x.png?478}} | ||
| - | |||
| - | ==== Rebase when pulling ==== | ||