Differences between revisions 1 and 2
Revision 1 as of 2020-02-25 13:14:16
Size: 1376
Comment: add page Git: collection of discussion and TODO items for git workflow
Revision 2 as of 2020-02-25 14:31:09
Size: 1643
Editor: JendrikSeipp
Comment:
Deletions are marked like this. Additions are marked like this.
Line 12: Line 12:
   * [Jendrik] Thankfully, this can be automated (https://stackoverflow.com/questions/5894946/how-to-add-gits-branch-name-to-the-commit-message, https://gist.github.com/bartoszmajsak/1396344)
   * [Jendrik] I'd prefer "[issue999] Fix bug" over "issue999: Fix bug".

Back to developer page.

Git

Our Git workflow (work in progress)

Outcome of the discussion in the Fast Downward meeting on 21 February:

  • we want to use branches for issues as with Mercurial (TODO: is there a precise workflow we follow, e.g., from the slides Gabi showed us? Or the git project we looked at?)
  • when integrating branches into master, we do not squash commits and we do not fast forward, i.e., we want to preserve the non-linear history of commits and always have a proper merge commit for the integration
  • we delete branches (the pointer) after integration
  • to identify commits on a branch, we prepend "issue999: " to all commits of the branch issue999

TODO: add infos on how to do something like git bisect with --first-parent etc. (Malte sent a few links)

TODO: github workflow: can we use their features, such as for merging pull request of extern collaborators, if that ever happens?

TODO: old suggestion for workflow, needs to be adapted according to above discussion:

  • git branch issue999
  • git checkout issue999
  • git commit --allow-empty -m "start branch issue999"
  • ...
  • git commit -m "some changes"
  • ...
  • git tag -a issue999-base -m "add tag issue999-base" <rev>

  • git tag -a issue999-v1 -m "add tag issue999-v1" <rev>

  • git push --set-upstream origin issue999 --tags

FastDownward: ForDevelopers/Git (last edited 2020-02-27 17:50:43 by SilvanSievers)