Every open source project lives from the generous help by contributors that sacrifice their time and Robottelo is no different.

To make participation as pleasant as possible, this project adheres to the Code of Conduct by the Python Software Foundation.

Here are a few hints and rules to get you started:

• No contribution is too small; please submit as many fixes for typos and grammar bloopers as you can!
• Don’t ever break backward compatibility. If it ever has to happen for higher reasons, Robottelo will follow the proven procedures of the Twisted project.
• Always add tests and docs for your code. This is a hard rule; patches with missing tests or documentation won’t be merged. If a feature is not tested or documented, it doesn’t exist.
• Obey PEP 8 and PEP 257.
• Write good commit messages.
• Ideally, squash your commits, i.e. make your pull requests just one commit.

Thank you for considering to contribute to Robottelo! If you have any question or concerns, feel free to reach out to me. I can usually be found on the #robottelo channel on freenode.

• Add Robottelo as a remote repository to your fork

(master) $ git remote add upstream [email protected]:SatelliteQE/robottelo.git

• Fetch latest upstream code

(master) $ git fetch upstream

• Rebase your fork's master repo to match upstream's

(master) $ git rebase upstream/master

• Create new local repo to work on issue or feature

(master) $ git checkout -b branch_name

• Make all your changes in the local branch_name repo and commit with a nice, short subject and a detailed message

(branch_name) $ git add <all modified or new files>
(branch_name) $ git commit

Adding feature so and so to module blah.

Here I will add more information about what the entire commit is about.

• PEP8 and PyLint

Before you commit your changes and prepare a Pull Request (PR), please make sure to check your code using pep8 and pylint to make sure your code follows our standards as well as catch issues early:

(branch_name) $ pylint --rcfile=pylint.cfg -rn -f colorized tests/ui/test_domain.py
************* Module tests.ui.test_domain
C: 13, 0: Invalid constant name "domain" (invalid-name)
C: 16, 0: Missing class docstring (missing-docstring)
C: 18, 4: Missing method docstring (missing-docstring)
R: 16, 0: Too many public methods (52/20) (too-many-public-methods)

(branch_name) $ pep8 --first --show-source  tests/ui/test_operatingSys.py -v
user configuration: /Users/omaciel/.config/pep8
checking tests/ui/test_operatingSys.py
tests/ui/test_operatingSys.py:39:80: E501 line too long (82 > 79 characters)
      # self.assertTrue(self.user.wait_until_element(locators["notif.success"]))
                                                                             ^

As you can see, this will allow you to improve your code by providing docstrings and/or tweaking your methods/functions/classes to conform with well known standards for python coding

• Ready to push your changes for a PR?

(branch_name) $ git push origin branch_name

• Now use Github's web UI to create your PR.

• Need to make more changes either because you received feedback for your PR or because you're not done yet?

(branch_name) $ git add <all modified or new files>
(branch_name) $ git commit --amend
(branch_name) $ git push

* By using --amend you get to keep all your changes as one single commit, which is much cleaner imho :)

• First, let's rebase your master to reflect upstream's master

(branch_name) $ git checkout master
(master) $ git fetch upstream
(master) $ git rebase upstream/master
(master) $ git push

• Now, let's rebase our working directory against your master

(master) $ git checkout branch_name
(branch_name) $ git rebase master

• Push your rebased branch_name back to Github

(branch_name) $ git push origin branch_name

• Git complaining about rebase because commit history is being changed? Use the --force Luke

(branch_name) $ git push origin branch_name --force

• Got to handle some issues with rebase? First, edit the offending file to resolve the conflict. Next, add it and commit it with --amend

(branch_name) $ git add <offending files>
(branch_name) $ git commit --amend

• Push it back to Github as explained before

So you made changes to FILE but you changed your mind and want to revert your changes? Don't want to preserve your changes either?

(branch_name) $ git checkout -- FILE

So you made changes to FILE, ran git add FILE but you changed your mind and want to revert your changes? Want to preserve your changes?

(branch_name) $ git reset HEAD FILE

So you went ahead and committed your changes and everything is 'staged', but you changed your mind and want to 'unstage' it?

• If you want to preserve your changes so that you can continue working on them:

(branch_name) $ git reset --soft HEAD~

• If you don't want to preserve your changes:

(branch_name) $ git reset --hard HEAD~

NOTE: Please note that HEAD~ represents 'the last commit'. If you want to undo the last 3 commits, then change HEAD~ to HEAD~3.