You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@streampipes.apache.org by Florian Micklich <fl...@disy.net.INVALID> on 2020/03/05 20:33:52 UTC

git workflow to contribute code

Hi everyone,

I just want to write a quick mail to mention the git workflow for contributing code and also start a discussion for best practice way.


So first of all I created a fork of the apache/incubator-streampipes-extensions (https://github.com/apache/incubator-streampipes-extensions)

After this, the branch is my GitHub  account as a repository, which I can clone as usually to my hard drive.

        git clone  git@github.com<ma...@github.com>:<GITHUBUSER>/incubator-streampipes-extensions.git

The current work takes place in the dev branch so to get the latest code I checkout the dev branch

        git checkout dev


But I learned that this is still not a good place to start writing code. To do later on a clean push request it is better to create a new branch, so called feature branch. It can be either created via git (creating a myNewFeature-Branch depending on the dev branch)

        git checkout -b myNewFeature dev


or, because I personally like and use gitflow, which automatically uses the prefix feature for naming the branch, I do:

        git flow feature start myNewFeature

The name of the branch will be feature/myNewFeature

In this branch, I do all my code work and commit and push it to github (still in the feature branch)

If I work on two features at ones I simply created two feature branches to work separately on it, so both features will not be mixed up during pull request and the discussion and code is clear to all members.


If I think I have finished my work and everything is ready to to start a pull request,  I simple go to Github and do following steps,

1. Switch to the finished feature branch and click merge request. Here I can choose

    a)  the base repository address  --> apache/incubator-streampipes-extensions and the base branch --> here I choose dev

    b) the head repository address (my fork) <GITHUBUSER>/incubator-streampipes-extensions and the branch I want to use as pull request --> feature/myNewFeature

2. If I see "Able to merge" I can simple click on View pull request, where I can add some comments and introductions to start the discussion


and then ready to pull and waiting.

While waiting and discussion time, I finished my other feature and start another pull request clean and tidy.


In my eyes  the important step is that the feature branch is never be merged  into my local dev branch or in gitflow terms finish my feature branch.

This is because I want to synchronize the dev branch with the main channel of the apache/incubator-streampipes-extensions without merge conflicts. So after the pull request is accepted (with maybe some changes from the community) I get my own code anyway in the dev channel.


So the main step is to synchronize my fork with the main streampipes channel to get the latest updates and my accepted branch.

To get this I only have to add another remote channel:

        git remote add upstream git://github.com/apache/incubator-streampipes-extensions.git

So with

    git remote -v


I see the origin and the upstream channel.


To be sure to get the latest changes  I use

        git fetch upstream


The dev channel is still the place to be so I checkout the origin dev channel

        git checkout origin dev



and merge the latest changes from upstream dev into my local branch

        git merge upstream/dev



And here my only and properly also a philosophical question: would be a rebase better in this case?


After the pull request is accepted and found its way into the upstream dev branch, I can easily delete my feature branch.

If I want to improve my feature again, I start to create a fresh new feature branch from the updated local dev :)

I think this can be illustrated  with some screenshots as well  and added next to the "how to import the project into intellij"  post ;-)


During the pull request, what general information would be helpful to add as comment? I think a short description what the code is for is one major bullet point. Or is this information already in the resource file?

A short template list  with the necessary information would be good.


Kind regards

Florian


Disy Informationssysteme GmbH
Florian Micklich
Lösungsentwickler
+49 721 16006 477,  florian.micklich@disy.net

Firmensitz: Ludwig-Erhard-Allee 6, 76131 Karlsruhe
Registergericht: Amtsgericht Mannheim, HRB 107964
Geschäftsführer: Claus Hofmann

Bitte beachten Sie folgende Informationen für Kunden, Lieferanten und Bewerber
- Datenschutz: www.disy.net/datenschutz
- Informationspflichten:  www.disy.net/informationspflichten