You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update: This gist is from when I was a student participating in UCOSP and helped me to plan and keep track of my progress on Freeseer.
This public gist is for team members and myself to keep track of what I'm working on, what I plan to work on, and to read any miscellaneous notes or tips about the project I feel are worth adding.
Fetch any changes from your remote fork (optional)
$ git fetch fork
Push your new local branch to the remote fork, where it should have the same name
$ git push fork myfeature:refs/heads/myfeature
Configure your new local branch so that it automatically pushes changes to your new remote branch on GitHub when we do a plain git push, and automatically pulls from your branch on the remote fork when we do a plain git pull
So you can pull changes from origin directly to your local copy, with the assurance that those changes will be automatically migrated to your remote fork repository when you push.
Install dependencies
Build
Branches & rebasing
Most of these tips are from zxiiro in #freeseer
always make your own branch
always rebase your branch against upstream's development branch (or working branch whichever it is)
when your code is done and ready to be pulled send a pull request to upstream, and if your going to work on something else, make a new branch again off of upstream's development branch to work on your new project
(when they pull your original branch, then when you rebase the new upstream working branch, your new branch will have the feature you added - makes merging much easier)
rebase often if you're pulling from upstream
it's cleaner to rebase than fetch and merge
you can't rebase after a merge, so if you merge instead of rebase from upstream, then when upstream pulls from you, they get the merge too which screws up history
so do all your work on a separate branch
when done, send a pull request (when they pull from you they'll only get your changes in that case)
if you didn't rebase, they'll get your changes + their changes back and then they have to remerge stuff
you can't rebase if you've already pushed your changes onto github
push when done working for the day, and pull before start working
that way when you go to another computer you get the latest
also it's nice to have people comment about what you screwed up on :)
The import branch
The import branch is a local branch of incoming code which parallels the remote development branch.
NEVER make changes in this branch! That way it stays trivial to update it with "git pull".
(It's possible to pull direct from upstream without creating a local branch, but this is handy for comparing even when offline.)
Create a local branch (e.g. 'mybranch') that pulls from 'import':
$ git checkout -b mybranch import
For merges, you want to be in the branch you're bringing content into:
$ git checkout master
$ git merge mybranch # Merges the commits from "mybranch" into "master"
$ git branch -d mybranch
To get the latest code (from upstream) when online:
$ git rebase upstream/development import # Do this often
or
$ git checkout import # Make 'import' the active branch
$ git pull # Merges any pulled commits into the current branch
Once you have the latest code in your import branch, you can then update your working branch with:
$ git rebase import mybranch # Do this often
When you're done working for the day, push your branch back up to your fork so that the changes are visible & preserved:
$ git push origin mybranch:mybranch # After the first time, you can simply use 'git push'
Make sure to commit and push often! Cheap and quick way to preserve your work. Changes can always be undone.
Closing issues
When one of your commit fixes and closes an issue, please use the following in the commit message:
Closes #NN.
Where NN is the issue number. This automatically closes it and links to it.
Example:
git commit -m "Fixed recording issue with vga2usb on Fedora 17 Linux. Closes #721"
Pull requests
Send a pull request from your development branch (e.g. mybranch).
While you wait for it to be pulled, you can start development for a different task on a new branch.
For help, visit: http://help.github.com/send-pull-requests
Potential Issues/Ideas
Change README from text to markdown (+ easier to read on github, - harder to read raw file)
Remove git_tips_and_tricks + git_cheat_sheet after developer docs completed
There are 2 license files (in freeseer/ and freeseer/src/), remove one
Recording from webcam (USB source option in Freeseer) doesn't work well with frames (experimental)
Tickets that tickle my fancy
issue #114 (gracefully shutdown GST when stop)
issue #113 (remove test button)
issue #111 (pause)
issue #119 (prompt when erasing all talks)
issue #99 (shorten long title/speaker names)
issue #94 (select area to record)
issue #80 (prevent screensaver from killing recording)
issue #59 (create man and html docs)
issue #19 (talk timer)
issue #34 (add black screen/image option when recording)
Cleanup README once documentation is done, too cluttered
Shorten intro
Replace Users, Developers, Packaging, Bug Tracker, Mailing List, and IRC Channel, with a section named "Support and Documentation" which will contain subsections.