Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Git Workflow #3

Closed
PRemmen opened this issue Jan 12, 2015 · 6 comments
Closed

Git Workflow #3

PRemmen opened this issue Jan 12, 2015 · 6 comments

Comments

@PRemmen
Copy link
Contributor

PRemmen commented Jan 12, 2015

I think we should add a Git workflow to our wiki, so we maintain a overview what is changed etc.

We could adapt the workflow from the annex repository:
https://github.com/iea-annex60/modelica-annex60/wiki/Workflow-for-code-changes

Are there any objections using this workflow and adjust it for our purposes?

@thorade
Copy link
Contributor

thorade commented Jan 12, 2015

The workflow as described sounds good to me.

There is one point to discuss though:
IIRC, in annex60, people work on their own fork, where they have all rights, and make a pull request afterwards.
In EnEff-BIM, we want a private repository and no public forks, so we are probably going to work in the main repository (but in a separate branch).

(Also discussed here: RWTH-EBC/AixLib#1 )

@PRemmen
Copy link
Contributor Author

PRemmen commented Jan 12, 2015

Adapted Worflow proposal:

This page describes the workflow for changing source code and documentation. Eventually, as the design becomes more stable, we will define a stricter process. At this stage of the development, code changes should be done as follows:

  1. Open a new issue, and assign it to the one who can address it (which may be you).
  2. Make a new branch starting from the master branch. Call this branch something like issue17_templateBoiler, use the issue number and a brief description of the revised feature.
  3. Document your changes on the issue tracker and implement them on the branch. You may want to include in the commit message a string such as change python dependency from 3.4 to 3.3 #17. This will automatically add a link to the commit from the issue.
  4. When done with the implementation:
    • merge the latest version from the master to your branch
    • make a pull request from your branch to the master
    • assign the issue to someone for review and for merging it into the master branch
  5. When reviewing other's code, add your comments on the issue tracker
  6. If the revisions are reviewed and correct, merge the pull requests to the master, delete the branch and close the ticket. If the revisions need further work, assign the issue to the original author.

Note that only the person who reviewed the code will merge it to the master. Don't merge your own revisions without having them reviewed.

@math-boy
Copy link
Contributor

Thanks for the workflow. That's fine for me!

@thorade
Copy link
Contributor

thorade commented Jan 12, 2015

And thanks for adding the issue labels

@PRemmen
Copy link
Contributor Author

PRemmen commented Jan 12, 2015

I added the workflow to the wiki, but I will leave this issue open for some time, to be reviewed if wanted

https://github.com/EnEff-BIM/EnEffBIM-Framework/wiki/Git-Workflow

@PRemmen
Copy link
Contributor Author

PRemmen commented Feb 26, 2015

Workflow has been discussed at Berlin workshop and can be closed

@PRemmen PRemmen closed this as completed Feb 26, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants