User Tools
devel:git-commit-guidelines
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
devel:git-commit-guidelines [2015/02/02 17:27] miconda [Commit message] |
devel:git-commit-guidelines [2018/03/12 13:03] miconda [Generic Guidelines] |
||
|---|---|---|---|
| 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 166: | Line 166: | ||
| * 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 315: | Line 316: | ||
| < | < | ||
| git push origin --delete < | 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.txt ยท Last modified: 2018/10/24 22:33 by henningw
Page Tools
