All,
I've seen a few similar "growing pains" since we've switched to the
pull-request model. One reoccurring issue seems to be not using the
topic-branch model and/or sending requests to the wrong upstream branch.
Working directly on your local 'next' or 'master' branch is a sure-fire
way to loose code (Ask lmr or Yu, they will tell you how many times I
have lost my code). Instead, maybe you can learn from my difficulties
by working from local "topic-branches". Try to reserve "next" and
"master" branches to just track upstream changes. Do all your work on
separate topic-branches...
git help remote
# make 'origin' point at your github fork,
# and 'upstream' point at main repo. (suggestion)
# you can rename them if needed
# (assuming your origin already points upstream)
git remote rename origin upstream
# add upstream (if needed)
git remote add upstream git://github.com/autotest/virt-test.git
# make sure remotes are pointing to right places
git remote show
git remote show origin
git remote show upstream
# download all change references from upstream and github
# (doesn't change HEAD)
git remote update
To get your local next/master branches in-sync with upstream and origin,
use the "git remote update command" and move their heads.
Warning: These next steps will destroy any changes you made to local
next branch, maybe back them up to another branch first ("git checkout
next; git checkout -b old_next").
# download upstream changes (if not already)
git remote update
# change to local next branch
git checkout next
# Re-point your local HEAD to same place as upstream
# (this is where code can be lost if you make changes to next/master)
git reset --hard upstream/next
# do same for master
git checkout master
git reset --hard upstream/master
# If everything is good, update your github fork
git push origin next
git push origin master
Before you start working on a new set of commits, make a topic-branch
(-b option) that tracks (-t option) your local "next" branch. By making
it a tracking branch, "git status" will always tell you how far ahead or
behind you are (after update).
# Change to starting-point branch
git checkout next
# make topic branch (do this first, before adding any code)
git checkout -tb my_topic_branch_name
# write code, commit changes, push up to your github fork
git push origin my_topic_branch_name
This way, you can make a pull request from "my_topic_branch_name" to
autotest/virt-test:next" and everything is nice and tidy. You can have
as many topic-branches as you want so you can work on code in parallel
without anything getting mixed up.
As time goes by, you may want to keep your topic-branch updated with
what happens on next, (i.e. git status shows you're behind upstream).
This is simple with rebase your local branch:
# make sure next is up to date
git remote update
git checkout next
git reset --hard upstream/next
# switch to topic branch
git checkout my_topic_branch_name
# Make a pre-rebase backup (doesn't hurt)
git branch preRebase_my_topic_branch_name
# Pull in upstream changes
git rebase --interactive --autosquash next
# Force push up to your github account (required due to rebase)
git push --force origin my_topic_branch_name
Just remember that git branches take up almost no disk space. As long
as you don't make any local changes to "next" or "master" then
everything will stay in sync. nicely. Your pull request
source/destination will line up nicely, and it's easy to keep branches
up to date.
I've learned many of these lessons by loosing code and getting commits
mixed up. Please let us know if you need any help with this, I know
well it can be confusing at first.
--
Chris Evich, RHCA, RHCE, RHCDS, RHCSS
Quality Assurance Engineer
e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
