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.

  1. http://help.github.com/creating-a-repo/
  1. git clone git@github.com:chipKIT32/chipKIT32-MAX.git
  2. If you don’t need the entire project history
  3. git clone  git@github.com:chipKIT32/chipKIT32-MAX.git --depth 1
  1. http://help.github.com/forking/

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

Collapse your commits for a pull request

Rebasing and applying your changes, then submitting that as a pull request http://www.gitready.com/advanced/2009/02/11/pull-with-rebase.html

The Stash, and staging changes

How to use the stash: http://www.gitready.com/beginner/2009/01/10/stashing-your-changes.html

The Git staging area explanation:

http://www.gitready.com/beginner/2009/01/18/the-staging-area.html

Get a tagged version

git clone  git@github.com:arduino/Arduino.git

git tag -l

git checkout <tag_name>

Create your own tag

git tag -a name

show a tagged version

git show name

Diff a revision and path

git diff rev path

Restore a file from latest revision

git checkout filename

List branches

git branch

Make a branch

git branch branch_name

Push branch to Github repository

git push origin branch_name

Check out the branch

git checkout branch_name

Throw away uncommitted changes

git --reset hard

Create a new branch based on origin branch_name instead of the current branch

git checkout -b orign/master origin/master

git pull origin master

Work on upstream branch other than master

git checkout --track -b branch_name origin/remote_branch_name

Remove files from deleted from the files system, but not yet removed

git add -u

Remove directories and files

git clean -d

Resolve conflicts the quick way when you want all from "their" repository or all from "ours" repository

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 Resources

Git Reference Site: http://gitref.org/

How to use the stash:

http://www.gitready.com/beginner/2009/01/10/stashing-your-changes.html

The Git staging area explanation:

http://www.gitready.com/beginner/2009/01/18/the-staging-area.html