Difference between revisions of "Lazarus Team - Git Workflows"

From Free Pascal wiki
Jump to navigationJump to search
Line 62: Line 62:
 
[[Category:Lazarus]]
 
[[Category:Lazarus]]
 
[[Category:Revision control]]
 
[[Category:Revision control]]
[[Category:Lazarus Developer Guide]]
+
[[Category:Lazarus Developer Routine]]

Revision as of 16:36, 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

Warning-icon.png

Warning: Adding new extensions can have unwanted side effects on existing file.

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