ChipKit, Day in the life of a developer
This is quick guide is designed to go through ChipKit developer work cycle. First configuring your own version of the project in Git using Github, and then review the standard work cycle of getting things done, and resolving issues with the system.
Git is a distributed version control system where you have a complete local copy of the entire project. The commit is a snapshot of all the changes made. You can work continuously without needing to go back to a “master” repository.
Note: If for some reason the SSH port is blocked on a local firewall you can clone a Git project over ssh or https.
To get started you’ll need to:
You need create this keypair to authorize your commits by machine, and your user account.
Set up your environment for development:
1. Go to the ChipKit project
2. Select "fork" of the ChipKit project in the Github interface.
3. Then clone your fork
4. Set the official ChipKit repository as the upstream repository
5. Now you are all set up to begin working
Decide what you’ll be working on
Check the issue list at https://github.com/chipKIT32/chipKIT32-MAX/issues
Note: The issue number related to the issue or task your working on. Put this in the comments you make as your work so you can keep track of what work you did related to a specific bug. Like “Issue #206” It’s also handy at this point to think of a test or way of knowing your fix is working.
Start your day
1. Pull changes from upstream repository
2. Make changes
3. Check status
4. git add new files
5. Check the files you wanted are added
6. Commit your changes
7. Push your changes to you local repository
Check out your changes see if they work. If they look good you can submit a pull request. However, if the master repository which is upstream from you has changed, then you need to fetch the changes from upstream.
Submit your changes to the master project
Submit a pull request, a pull request needs to have the following info:
Common Git Tasks
Rebasing and applying your changes, then submitting that as a pull request http://www.gitready.com/advanced/2009/02/11/pull-with-rebase.html
How to use the stash: http://www.gitready.com/beginner/2009/01/10/stashing-your-changes.html
git clone firstname.lastname@example.org:arduino/Arduino.git
git tag -l
git checkout <tag_name>
git tag -a name
git show name
git diff rev path
git checkout filename
git branch branch_name
git push origin branch_name
git checkout branch_name
git --reset hard
git checkout -b orign/master origin/master
git pull origin master
git checkout --track -b branch_name origin/remote_branch_name
git add -u
git clean -d
Take all the remote changes
git checkout --theirs -- path/to/conflicted-file.txt
Take all of our changes
git checkout --ours -- path/to/conflicted-file.txt
Git Reference Site: http://gitref.org/
How to use the stash:
The Git staging area explanation: