"Fossies" - the Fresh Open Source Software Archive  

Source code changes of the file "CONTRIBUTING.md" between
angular.js-1.7.9.tar.gz and angular.js-1.8.0.tar.gz

About: AngularJS is a web application framework that assists with creating single-page applications that only require HTML, CSS, and JavaScript on the client side.

CONTRIBUTING.md  (angular.js-1.7.9)	:	CONTRIBUTING.md  (angular.js-1.8.0)
skipping to change at line 128		skipping to change at line 128
* Make your changes in a new git branch:		* Make your changes in a new git branch:
```shell		```shell
git checkout -b my-fix-branch master		git checkout -b my-fix-branch master
```		```
* Create your patch commit, **including appropriate test cases**.		* Create your patch commit, **including appropriate test cases**.
* Follow our [Coding Rules][developers.rules].		* Follow our [Coding Rules][developers.rules].
* If the changes affect public APIs, change or add relevant [documentation][deve lopers.documentation].		* If the changes affect public APIs, change or add relevant [documentation][deve lopers.documentation].
* Run the AngularJS [unit][developers.tests-unit] and [E2E test][developers.test s-e2e] suites, and ensure that all tests		* Run the AngularJS [unit][developers.tests-unit] and [E2E test][developers.test s-e2e] suites, and ensure that all tests
pass. It is generally sufficient to run the tests only on Chrome, as our Travi		pass. It is generally sufficient to run the tests only on Chrome, as our conti
s integration will		nuous integration test will
run the tests on all supported browsers.		run the tests on additional browsers.
* Run `yarn grunt eslint` to check that you have followed the automatically enfo rced coding rules		* Run `yarn grunt eslint` to check that you have followed the automatically enfo rced coding rules
* Commit your changes using a descriptive commit message that follows our		* Commit your changes using a descriptive commit message that follows our
[commit message conventions][developers.commits]. Adherence to the		[commit message conventions][developers.commits]. Adherence to the
[commit message conventions][developers.commits] is required, because release notes are		[commit message conventions][developers.commits] is required, because release notes are
automatically generated from these messages.		automatically generated from these messages.
```shell		```shell
git commit -a		git commit -a
```		```
Note: the optional commit `-a` command line option will automatically "add" an d "rm" edited files.		Note: the optional commit `-a` command line option will automatically "add" an d "rm" edited files.
skipping to change at line 154		skipping to change at line 154
yarn grunt test		yarn grunt test
```		```
* Push your branch to GitHub:		* Push your branch to GitHub:
```shell		```shell
git push origin my-fix-branch		git push origin my-fix-branch
```		```
* In GitHub, send a pull request to `angular.js:master`. This will trigger the c heck of the		* In GitHub, send a pull request to `angular.js:master`. This will trigger the c heck of the
[Contributor License Agreement](#cla) and the Travis integration.		[Contributor License Agreement](#cla) and the continuous integration tests.
* If you find that the Travis integration has failed, look into the logs on Trav is to find out		* If you find that the continuous integration tests have failed, look into the l ogs to find out
if your changes caused test failures, the commit message was malformed etc. If y ou find that the		if your changes caused test failures, the commit message was malformed etc. If y ou find that the
tests failed or times out for unrelated reasons, you can ping a team member so t hat the build can be		tests failed or times out for unrelated reasons, you can ping a team member so t hat the build can be
restarted.		restarted.
* If we suggest changes, then:		* If we suggest changes, then:
* Make the required updates.		* Make the required updates.
* Re-run the AngularJS test suite to ensure tests are still passing.		* Re-run the AngularJS test suite to ensure tests are still passing.
* Commit your changes to your branch (e.g. `my-fix-branch`).		* Commit your changes to your branch (e.g. `my-fix-branch`).
* Push the changes to your GitHub repository (this will update your Pull Reque st).		* Push the changes to your GitHub repository (this will update your Pull Reque st).
You can also amend the initial commits and force push them to the branch.		You can also amend the initial commits and force push them to the branch.
```shell		```shell
git rebase master -i		git rebase master -i
git push origin my-fix-branch -f		git push origin my-fix-branch -f
```		```
This is generally easier to follow, but seperate commits are useful if the P ull Request contains		This is generally easier to follow, but separate commits are useful if the P ull Request contains
iterations that might be interesting to see side-by-side.		iterations that might be interesting to see side-by-side.
That's it! Thank you for your contribution!		That's it! Thank you for your contribution!
#### After your pull request is merged		#### After your pull request is merged
After your pull request is merged, you can safely delete your branch and pull th e changes		After your pull request is merged, you can safely delete your branch and pull th e changes
from the main (upstream) repository:		from the main (upstream) repository:
* Delete the remote branch on GitHub either through the GitHub web UI or your lo cal shell as follows:		* Delete the remote branch on GitHub either through the GitHub web UI or your lo cal shell as follows:
End of changes. 4 change blocks.
6 lines changed or deleted		6 lines changed or added

---