Command line is always better for that.... Agreed there is a learning curve associated to that though.
This could be used as a draft to be added there.
1. Create a fork under Github at https://github.com/osresearch/heads/fork so that changes can be localized and branches submitted on personal fork
2. Have github know your ssh public key so you can upload back your changes to github in your fork https://medium.datadriveninvestor.com/how-to-clone-a-github-repository-using-ssh-for-windows-linux-macos-78ad9a3959e?gi=a48768b328cd
3. Have GitHub know your pulic key so that you can sign your commits (this is important so that commits can be trusted and have accountability) https://www.freecodecamp.org/news/git-ssh-how-to/
4. Clone Heads (osresearch/master : will be origin) : `git clone https://github.com/osresearch/heads`
5. Make sure latest version of osresearch/heads `git fetch origin`
6. Add your fork's remote to be useable with ssh: `git remote add GITHUB_USERNAME git@github.com:GITHUB_USERNAME/heads.git`
7. `git fetch GITHUB_USERNAME`
8. I always make sure I'm at the right latest commit against master prior of changing branch : `git checkout GITHUB_NAME/master`
9. `git reset --hard`
10. Change to a branch you want to track your changes: `git checkout -b NAME_OF_CHANGESET`
11. Do limited changes to accomplish a goal (a commit should contain changes linked to accomplish one single thing at a time, and a branch should contain the smallest number of commits needed to accomplish that goal. Think iterative, your branch might be asked to be reworked to seperate your changes across multiple pull requests (different goals) if too many commits are present. A good pull request (your branch pushed against master) should contain maximum 4 commits unless really justifiable.
12. git add `FILE1 FILE2 FILE3`
13. Get information on current changes: `git status`
14. `git commit` / `git commit -m "goal: adding function xyz"`
15. continue doing your changes
16. Add your changed and do commits as above
17. When done, `git push GITHUB_USERNAME`, or force pushing changes if you modified history of commits `git push GITHUB_USERNAME --force`
On step 16 above, when it is asked of you to modify your pull request, you might have to dig a little bit more the internals of git.
* git commit -amend will permit you to modify your last commit
* Interactive rebasing will permit you to go back in your commit history to squash changes, amend commits etc: https://thoughtbot.com/blog/git-interactive-rebase-squash-amend-rewriting-history
Otherwise, there is plenty of GUI frontends to git out there that you might want to investigate if command line git is giving you nausea. Unfortunetaly, I do not use them so I cannot really recommend any of them. I would go against using the web based VisualStudio frontend proposed by github, since even though it might seem attractive since proposed by Github, amending/rebasing and pushing changes results in a lot of back and forth and many pull requests being opened/closed in the past. Doing changes locally and pusshing them is definitely more interesting, both for your learning and collaborating to other projects and for maintainership of this perticular project.
CircleCI:
1. Open account on CircleCI
2. Subscribe on your github project.
3. That's it. When you will push commits to your fork, CircleCI will build automatically and will inform your branch of success/failed commits. that should probably be another entree.
Will edit this post later on following feedback, and will use that entree here to open another issue in wiki documentation.
From https://github.com/osresearch/heads/issues/1221#issuecomment-1267260439