Corregir mi último commit:
git commit –amend
Cambiar de branch:
git checkout branch_name
Renombar una branch:
git branch -m old_name new_name
Borrar una branch:
git branch -d branch_name
Cambiar la referencia remota de un branch:
git branch --set-upstream origin remote_branch
Pulling a new branch from a remote repository
git fetch origin [remote-branch]:
GitHub git cheatsheet: help.github.com/git-cheat-sheets/
Basado en reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html Lo iremos tuneando de acuerdo a nuestra realidad
1. Pull to update your local master 2. Check out a feature branch 3. Click "start" on PivotalTracker's story 4. Do work in your feature branch, committing early and often 5. Rebase frequently to incorporate upstream changes 6. Comment about your progress/issues on PivotalTracker's story. 7. Interactive rebase (squash) your commits 8. Merge your changes with master 9. Push your changes to the upstream 10. Click "finish" on PivotalTracker's story 11. Click "deliver" on PivotalTracker's story and comment with a link to squashed commit
git pull origin master
First, check out a feature branch named with the story id and a short, descriptive title:
git checkout -b 3275-add-commenting
When attempting several approachs to a feature create various branchs, all from master:
git branch 3275-A-feature git branch 3275-B-feature
Rebase against the upstream frequently to prevent your branch from diverging significantly:
git fetch origin master git rebase origin/master
OR
git checkout master git pull git checkout 3275-add-commenting git rebase master
When you finish the story click “finish” on PivotalTracker
Once work on the feature is complete, you will have a branch with a lot of small commits like “adding a model and a migration”, “adding a controller and some views”, “oh crap – adding tests” and so on. This is useful while developing but larger, incremental commits are more easier to maintain. We will use an interactive rebase to squash them together. Also, squashing these commits together will allow us to pretend that we wrote the tests first…
We want the rebase to affect only the commits we’ve made to this branch, not the commits that exist on the upstream. To ensure that we only deal with the “local” commits, use:
git rebase -i origin/master
Git will display an editor window with a list of the commits to be modified, something like:
pick 3dcd585 Adding Comment model, migrations, spec pick 9f5c362 Adding Comment controller, helper, spec pick dcd4813 Adding Comment relationship with Post pick 977a754 Comment belongs to a User pick 9ea48e3 Comment form on Post show page
Now we tell git what we to do. Change these lines to:
pick 3dcd585 Adding Comment model, migrations, spec squash 9f5c362 Adding Comment controller, helper, spec squash dcd4813 Adding Comment relationship with Post squash 977a754 Comment belongs to a User squash 9ea48e3 Comment form on Post show page
Save and close the file. This will squash these commits together into one commit and present us with a new editor window where we can give the new commit a message. We’ll use the story id and title for the subject and list the original commit messages in the body:
[#3275] User Can Add A Comment To a Post * Adding Comment model, migrations, spec * Adding Comment controller, helper, spec * Adding Comment relationship with Post * Comment belongs to a User * Comment form on Post show page
git checkout master git merge 3275-add-commenting
git push origin master
Only click “deliver” when you have actualy delivered your work by pushing your changes to the github repo.