Difference between revisions of "Lazarus Team - Git Workflows"
(→Milestone: Categorise page) |
m (→Milestone) |
||
Line 62: | Line 62: | ||
[[Category:Lazarus]] | [[Category:Lazarus]] | ||
[[Category:Revision control]] | [[Category:Revision control]] | ||
+ | [[Category:Lazarus Developer Guide]] |
Revision as of 16:15, 16 August 2022
This page contains workflows for Lazarus team members, when working with GIT.
git pull --rebase
- Commits made by team members should have a linear history
If you have local commits to push, and the remote branch has new commits too, then use rebase. Do not create any merge commits.
git pull --rebase
or
git rebase
Merge Requests / Pull Requests
Merge requests should be included by creating a merge commit
git merge merge-request/foo
Cherry picking / Merging
Do not "squash" commits when cherry picking.
If commits are squashed, then "git cherry" wont work.
Use
git cherry pick -x
The "-x" adds "cherry picked from commit"
".gitattributes" - Adding new file extensions
If you add files with an new extension (not yet covered by .gitattributes) then it is best to add that extension (or the concrete file)
Files not covered by .gitattributes will be left to git figuring out on its own, if they are text. Since this affects line endings, it is best to tell git, what we want the file to be.
After editing .gitattributes you must run (before committing):
git add --renormalize .
Then check git status which files were affected.
Issue Tracker
Milestone
When closing an issue, ensure to set the correct milestone.
If the issues is (or will be) merged to a fixes branch, set the milestone for the fixes release. (If the merge later fails, the milestone must be amended).
If you do not merge (cherry pick) yourself:
- leave the issue open
- Set the fixes milestone
- add the label
- merge::merge-and-close