devel:git-commit-guidelines
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| devel:git-commit-guidelines [2014/12/15 12:56] – [Cloning GIT Repository] miconda | devel:git-commit-guidelines [2018/10/24 20:33] (current) – [Read-Only Cloning of GIT Repository] henningw | ||
|---|---|---|---|
| Line 3: | Line 3: | ||
| ===== GIT Repository Location ===== | ===== GIT Repository Location ===== | ||
| - | Starting with December 15, 2014, the main GITH repository of Kamailio project is hosted on Github at: | + | Starting with December 15, 2014, the main GIT repository of Kamailio project is hosted on Github at: |
| * https:// | * https:// | ||
| Line 9: | Line 9: | ||
| A read-only mirror is maintained at: | A read-only mirror is maintained at: | ||
| - | * git.kamailio.org (still accessible via git.sip-router.org) | + | * git.kamailio.org (still accessible via git.sip-router.org) |
| + | * http:// | ||
| ===== Cloning GIT Repository ===== | ===== Cloning GIT Repository ===== | ||
| Line 41: | Line 42: | ||
| The clone is tracking automatically the remote **master** branch (the development version). | The clone is tracking automatically the remote **master** branch (the development version). | ||
| + | |||
| + | ===== Working with Github forks of a GIT Repository ===== | ||
| + | |||
| + | If you don't have developer write access, you can fork the Kamailio repository. Then you checkout the forked repository to your local disk and do the changes. Commit the changes to your repository and create a pull request to integrate your changes into the Kamailio repository back. Have a look e.g. to this documentation: | ||
| + | |||
| + | [[https:// | ||
| + | |||
| + | [[https:// | ||
| ===== Read-Only Cloning of GIT Repository ===== | ===== Read-Only Cloning of GIT Repository ===== | ||
| + | |||
| + | **Working with a fork of the Kamailio repository and then submitting a pull request is nowadays the preferred way to integrate your contributions, | ||
| If you don't have developer write access, you can clone read-only the repository with: | If you don't have developer write access, you can clone read-only the repository with: | ||
| Line 123: | Line 134: | ||
| * module_name: | * module_name: | ||
| * lib_name: critical bug fix | * lib_name: critical bug fix | ||
| - | |||
| - | If the module_name is duplicated, one in modules_k and one in modules_s, add (k) or (s), depending where the changes was done, for example: | ||
| - | * auth_db(k): fixed typo in comment | ||
| - | * auth_db(s): fixed typo in comment | ||
| Examples of commit messages: | Examples of commit messages: | ||
| - | * change to usrloc module from modules_k | + | * change to usrloc module from modules |
| < | < | ||
| - | usrloc(s): fixed name conflict | + | usrloc: fixed name conflict |
| - destroy_avps() renamed to reg_destroy_avps() to avoid conflicts | - destroy_avps() renamed to reg_destroy_avps() to avoid conflicts | ||
| Line 155: | Line 162: | ||
| * http:// | * http:// | ||
| + | ==== Content of the Commit Message ==== | ||
| + | |||
| + | * the message must be addressed for humans, using common sense language. All commit messages are part of the ChangeLog file for each release and that file is read by sysadmins and other non-developer people | ||
| + | * the message must be strictly related to the changes in the C code (e.g., don't give instructions what another developer must do with your patch) | ||
| + | * credits to persons or companies that helped in the context of the commit are allowed and it is fair to be added whenever is the case. The place is at the end of the commit message (or end of the part describing the related change) | ||
| + | * don't use slang and don't abuse using abbreviations, | ||
| + | * don't use system or tools commands to express the changes of the commit. They can be given as an example in the detailed message to show how the changes were done, but text explanation must be first. E.g., if you renamed a function, don't use as commit message ' | ||
| ===== Generic Guidelines ===== | ===== Generic Guidelines ===== | ||
| Line 162: | Line 176: | ||
| * do the commits per one module when changing in a module and other modules are affected and were updates as well | * do the commits per one module when changing in a module and other modules are affected and were updates as well | ||
| * when updating the documentation and it is intended to do a backport, split the commit in one for xml files and one for the README file. Usually the commit to xml files can be backported without conflict (with git cherry-pick ...). README files are many times generated with different character sets, a matter of the system where they are generated, resulting in backporting conflicts. Thus is better to backport only the commit for xml files and generate the README for that branch, then push it to remote GIT repository | * when updating the documentation and it is intended to do a backport, split the commit in one for xml files and one for the README file. Usually the commit to xml files can be backported without conflict (with git cherry-pick ...). README files are many times generated with different character sets, a matter of the system where they are generated, resulting in backporting conflicts. Thus is better to backport only the commit for xml files and generate the README for that branch, then push it to remote GIT repository | ||
| + | * **IMPORTANT**: | ||
| * if it is a change that has to be repeated in many places, then the commit can be done at once to all changes. For example, renaming a token that is present in all docbook files, removing or adding a new field in a structure such as module exports. | * if it is a change that has to be repeated in many places, then the commit can be done at once to all changes. For example, renaming a token that is present in all docbook files, removing or adding a new field in a structure such as module exports. | ||
| Line 305: | Line 320: | ||
| < | < | ||
| git push origin :< | git push origin :< | ||
| + | </ | ||
| + | |||
| + | As of Git v1.7.0, a remote branch can be deleted using: | ||
| + | |||
| + | < | ||
| + | git push origin --delete < | ||
| + | </ | ||
| + | |||
| + | ==== Revert already pushed commit ==== | ||
| + | |||
| + | This will produce a commit reverting the previous commit < | ||
| + | |||
| + | < | ||
| + | git revert < | ||
| + | git push origin | ||
| + | </ | ||
| + | |||
| + | ==== Rename and commit file ==== | ||
| + | |||
| + | Create minimal commit when renaming file | ||
| + | |||
| + | < | ||
| + | git mv module.c module_mod.c | ||
| + | git commit -m '...: renamed module file to match recommended pattern' | ||
| </ | </ | ||
devel/git-commit-guidelines.1418648163.txt.gz · Last modified: 2014/12/15 12:56 by miconda