github-flow.txt

workflow:
Workflow is the way people get work done, and can be illustrated as series of steps that need to be completed sequentially in a diagram or checklist.

for our RAX project:
we track our bugs/features in QTS, code repository is the IBM clear case. review codes in CCRC, after review, we check in codes into clear case manually. NO automation test?

for our DPAgent project:
we trace bugs/features in bugzilla, we use our company github as the code repository. we use gerrit for code review when we push codes into remote branches like refs/for/master, and each time we pushed codes, automation test runs.

for datahub-flowagent project:
basically we are following the github flow. but now we also need bugzilla to track the issues. previoulys, all things in github only. that is the workflow many open source projects follow.

by the way, besides github flow, there are git flow and gitlab flow, they are other types of workflow, different process, addtional tools, might be more complicated.

github/codes is code repository.
github/issues to track issues, communication.
git/pulls for code review in pull reqeust.
for our flowagent project, automation infrabox test run when: 
1, pushed to your branch if you configured your project in infrabox dashboard.
2, created a PR.
3, pushed your new commits into your branch in PR.

firstly, fork your project. why? 
because not anyone is allowed to push commits into the branches in origin project.
only those people who have the write permision could push commits directly into origin proejct. they are project owner, project archetect. say KB.
you should fork your own project and push to your own branch in your fork project. and create a PR(Pull Request) to request to merge your commits into origin branches.

actually, there are two kinds of develop model, fork-pull model and shared model. for shared model, everyone could create branch and commit changes. obviously, it is not a proper model for a project that involves many people and even people from outside the group.

git clone your fork project or add remote for your fork project.

and i suggest your don't push codes to your master branch, instead, you create another branch with a descriptive/meaningfull name,say, "odata-sql-consumer".

1, git add <files>, git commit -m "commmit message".
2, git push your-remote your-branch:remote-branch.
3, create a pull request, base is origin/master, compare is your-fork-project/your-branch
4, add reviewer, normally KB should be a must.
5, if requrie change, git add, git commit -m "commite message2", git push your-remote your-branch:remote-branch
6, sync your branch:
sometimes origin master have new commits while you are waiting for review pass. you need to:
git fetch origin
git merge origin/master
git push your-remote your-branch:remote-branch.
7, after review passed, project owner or the collaborator who has the write permission would do the merge.
8, you could git branch -D your-branch-name and delete the branch in remote repo.

close issue.