Differences between revisions 2 and 3
Revision 2 as of 2020-02-25 14:31:09
Size: 1643
Editor: JendrikSeipp
Comment:
Revision 3 as of 2020-02-27 10:09:14
Size: 1965
Comment: more on git workflow
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
 * 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?)  * we want to use branches for issues and basically follow our previous Mercurial workflow, i.e., have one feature branch for each issue
Line 14: Line 14:
 * TODO: what did we decide w.r.t. to having "cross references"/links to issues etc. in commit messages?
Line 15: Line 16:
TODO: add infos on how to do something like git bisect with --first-parent etc. (Malte sent a few links) Best practices:
 * TODO: git bisect with --first-parent etc. (Malte sent a few links)
 * TODO: how to configure git + meld
 * TODO: can we use github's facilities on the webpage for, e.g., merging pull requests or does this do "wrong" things?
Line 17: Line 21:
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
Suggested workflow:
 * git checkout -b issue999
Line 29: Line 30:
 * ...
 * git commit --allow-empty -m "close branch issue999"
 * git checkout master
 * git merge --no-ff issue999
 * git branch -d issue999
 * git push

Discussion on workflow:
 * do we want "opening" and "closing" commits for branches?
   * [Silvan] I don't think we necessarily do, but it wouldn't hurt to have them.

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 and basically follow our previous Mercurial workflow, i.e., have one feature branch for each issue
  • 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: what did we decide w.r.t. to having "cross references"/links to issues etc. in commit messages?

Best practices:

  • TODO: git bisect with --first-parent etc. (Malte sent a few links)
  • TODO: how to configure git + meld
  • TODO: can we use github's facilities on the webpage for, e.g., merging pull requests or does this do "wrong" things?

Suggested workflow:

  • git checkout -b 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
  • ...
  • git commit --allow-empty -m "close branch issue999"
  • git checkout master
  • git merge --no-ff issue999
  • git branch -d issue999
  • git push

Discussion on workflow:

  • do we want "opening" and "closing" commits for branches?
    • [Silvan] I don't think we necessarily do, but it wouldn't hurt to have them.

FastDownward: ForDevelopers/Git (last edited 2023-02-14 15:29:06 by SilvanSievers)