A simple mock up of a modular, nested python package for group collaboration without 8 people editing the same file.

• solarsys is meant to represent a standalone repository
• it is incomplete and imperfect by design but provides a "sandbox" to practice software development
• use trygit-4-8-plus as a template to create your custom repo for a customized team experience
• These participant instructions are designed assuming your new repo name is solarsys, but <central_repo> has been used in the text below to provide easier editing for customization.

A simple mock up of a modular, nested python repositiory for group collaboration. The <repo_name> project is a sandbox for gaining experience with collaborative coding projects and provides opportunites to develop and practice more advanced skills.

See the bottom of this document to find some common Reference Materials.

• Each participant has a github account
• Each participant has git installed on their computer
• Each participant has python on their computer
• Team messaging platform if working remotely
• Link from organizer to the team's custom repo with additional instructions --> <team_name>/<repo_name>

• Group Git webpage of the central repo (GG)
• Your Git webpage of forked repo (YG)
• Your Computer (YC)

Check YG, GG, and git status in between steps as you go to underand how git works.

Getting a local copy for future contributions via git

Now your computer is setup to track your remote fork (default origin or generically <your_fork_remote_name>) and the remote central repo (<repo_name>). You can change the names representing the remotes if more convenient for you. But this tutorial assumes you have not done this.

Test the library by starting a python session and importing the library. No python packaging has been performed. If you are having trouble, maybe an Issues exists on the GG that you can use.

Things to know before you start changing files

• Do not locally commit and push changes to the central repo. Use your fork for this purpose.
• Git commands to check things before committing: git status, git remote -v, and git branch.
• Use git commit and git push regulary to track incremental changes for your future self and backup your work.
• If you get stuck or confused, see the links at the bottom for more details, but git rm can be useful if you commit something by accident.

Starting local contributions and submitting them using a feature branch

If you have extensive changes, then it is a good practice to add, commit, and push regularly so you don't lose work.

Ready to merge your new code with the central repo on github.com

Practice code reviews on central repo For private repos, there may be not notifciation on a request to review. In this case, navigate to the central repo's github page (GG) and select Pull requests. You may see your avatar on the right. Additionally, you can hover over each PR link to see if you have been assigned something. Click on those links and the next steps will most likely be highlighted.

Updating local repos to match most current version of the central repo as seen on github.com

From here, further development is easiest if you create new central branches instead of using older ones. git branch -d <feature_branch> can be used to clean up the display of your local feature branches.

Updating an in progress feature branch with the central repo as seen on github.com This is usually not required and the method here is probably not recommended by professionals. This task can get complicated, especially if changing the same file (and more so the same lines). If you proceed with this method, then you will lose uncomitted changes. Professionals will rebase instead and this method may create unwanted issue. The good news is that this repo is designed to make a mess and learn how git works!

More advanced development The instructions outlined above can be used as a reference in the future. In addition, this project can be developed to add more complexity to the code with a richer description of our solar system or provide enhanced functionality (display pretty tables or create binder website). Finally, this project has room for more advanced practice of software carpentry skills: python packaging, version tagging, unit tests, code style requirements, json templating, and more.

1. Typically there is never a need to pull from your fork's remote master.
2. Never push to the central repo's remote master. Use Pull requests after pushing your fork's feature branch to its remote.
3. If you are instructed by git to rebase, decline if possible and research futher. See scikit-beams recommendations as a starting point for its discussion. Use rebase instead of pulling from the central repo's master branch to your fork's feature branch.

For your implementation of this template or in your future projects.

• solar system
• markdown cheat sheet
• git cheat sheet
• See Contributing and Developer Materials for detailed practices used by a community repo (scikit-beam)
• scikit-beam's cited resource for common git problems
• more git tutorials and examples
• configure upstream repo remote (central branch master)
• update (sync) your local fork master from remote central branch master
• update (sync) your remote fork to your synced local fork