|
Size: 1376
Comment: add page Git: collection of discussion and TODO items for git workflow
|
Size: 2194
Comment:
|
| 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 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". * TODO: what did we decide w.r.t. to having "cross references"/links to issues etc. in commit messages? |
|
| Line 13: | 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 15: | 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 27: | 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. * [Jendrik] I don't think they make sense for Git and only complicate the workflow. * [Malte] I agree with Jendrik. In Mercurial they do something important to the metadata, in git they don't, and they are not idiomatic. |
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
[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".
- 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.
- [Jendrik] I don't think they make sense for Git and only complicate the workflow.
- [Malte] I agree with Jendrik. In Mercurial they do something important to the metadata, in git they don't, and they are not idiomatic.