Dev Branch

[willemdh]

@dimon222 @ThomDietrich

So I did some tests with the dev branch and made a pull request. Is it possible to give you push permissions on the dev branch only somehow? Should I make the master branch protected?

[dimon222]

There are few options.

1. Make master protected like you mentioned. All the work is being done based on merges only. Preferably that there's you who can review pull requests, and decide accordingly to merge or to refuse.
2. Transfer project to newly created Organization. Github is claiming that there's more granular control for permissions for organizatons - https://help.github.com/articles/differences-between-user-and-organization-accounts/
3. Move to Gitlab. Sounds like radical option, but it has lot more options for controlling permissions.

[willemdh]

Hmm, I prefer to stay on (non-organization) GitHub for now. A colleague of me is setting up an on-premise GitLab server, so migrating to a public GitLab might be something to consider in the future if the protected branch option is not working for me.

So I sent @dimon222 and @ThomDietrich a collaborator request. Please o please don't abuse your new powers.. So from now on please commit to the dev branch and create a pull request to the master branch if you think your changes are production ready. Could you guys please send me a little email to myself (willem.dhaese@gmail.com) so I can contact you in another way then with GitHub. I reserve myself the rights to change this new way of working if it doesn't work for me.

[ThomDietrich]

Hey, the way you have it right now is okay with me. I'd actually prefer to still have merges to master only done by you! I'll do my development in my own fork on a feature branch and create PRs as soon as they are ready. Moving to an organization is not really needed I think. I love GitLab as a software for in-house development but open source projects like FireMotD should stay on GitHub for easy discovery and collaboration.

Let's see how it goes. Thanks for the trust and Happy Hacking! I'll write you a mail tomorrow.

[willemdh]

Posting my workflow to start 'hacking' on a new idea for future reference, let me know if you have any suggestions.

git branch -f dev-willem master
git checkout dev-willem
git push --set-upstream origin dev-willem

Start playing, when finished commit with:

GitAll "Feature X"

GitAll is an alias which contains

GitAll () {
    git add --all
    if [ "$1" != "" ]
    then
        git commit -m "$1"
    else
        git commit -m update
    fi
    git push
}

I'm creating the pull request in GitHub website atm, is there a way to do this from commandline?

[dimon222]

I'm creating the pull request in GitHub website atm, is there a way to do this from commandline?

Possible via Hub + Github Gem combo

PS: won't work if u don't have Hub installed and configured to work with github

[ThomDietrich]

Honestly I do my git'tery in a graphical UI (SmartGit or GitKraken). I think GitKraken even supports GitHub PRs.

As for the workflow, the first two commands can just as well be replaced by git checkout -b feature123. Descriptive names are normally better for branches. I like to work with names like "exception-bugfix" or "feature/ip-resolution-enhancement".

I personally don't like the GitAll alias. Here's my personal opinion: One should never blindly issue git add --all. Before adding something to the staging area you should check the diff to make sure it contains what you indeed want to commit. The --all option is also dangerous in this matter because you could accidentally commit temporary or unwanted files. Let's say you've done your diff checking before executing GitAll, it might be okay. Still I would not automate the add+commit+push process but go through it myself.

GitHub from the command line, check out: https://github.com/guyzmo/git-repo

[willemdh]

Closing this.