-
Notifications
You must be signed in to change notification settings - Fork 0
Git Commands
This page list specific commands for doing things in Git that we used to do in SVN on Google code, that people on the project have asked about.
git status will tell you what branch you are on, and summarize changes you've made, divided into the changes you've staged (marked to include in your next commit), and other changes. It also includes useful reminders of the commands to unstage or to completely forget and overwrite the local changes.
With the --ignored flag it also lists all files that exist but are covered by the .gitignore files, in case you want to check on that.
gitk displays a graph of the commit and branch history starting from whatever you've checked out, annotating any of the older commits that happen to be the head of some branch or tagged with some tag,
and letting you inspect lots of things.
It can take as arguments as many local branch names like and remote branch names like origin/ as you like, and then will show a combined graph including history back from each of those points. (there are tons of extra options and argument forms you can find in man pages, one particularly useful form is <branch>...<branch> to show only commits from the two branches back up to common ancestors, if you are thinking about a merge).
The command git checkout -- <file> will overwrite file with it's contents in whatever version you have checked out, replacing deleted files and overwriting modifications.
The easiest way to use it is probably to run git status whose output includes a reminder of this command and a list of all (non-ignored) modified and deleted files so you can just copy and paste filename.
"svn up" was used to replace deleted files, "git pull" doesn't do that because it considers deleting files to be possibly an intentional local change that it doesn't want to overwrite.
Sometimes you try to rebase changes in order to sync your branch with the upstream repository and run into weird problems where it has conflicts that you don't think should be there, or it adds a bunch of changes that aren't yours to your pull request.
In my experience this is generally because your commit history is not what you expect. Perhaps you have commits in your history in two different places, or you are branched from a different commit than you thought. To resolve this issue, we can use cherry-picking.
- From a clean master branch, create a new branch for your change to be transplanted into. To do this, run
git checkout -b <branch_name>. If you do not have a clean master branch, proceed to the second set of instructions, then return to step 2. - From your clean new branch, cherry-pick the changes you want. If you have only one change, you can do this by running
git cherry-pick <branch_name>. Otherwise, collect the hashes of all the commits you want to cherry pick and rungit cherry-pick <hash1> <hash2> ....
To create a clean branch without a clean master to begin with:
- If your remote repository is kframework/k, simply run
git checkout -b <branch_name> origin/master, and you're done. Otherwise, proceed to step 2. - Make sure you have the kframework/k repository added as a remote repository named
upstream. - Run the following commands:
git checkout -b <branch_name> upstream/mastergit branch <branch_name> --set-upstream-to origin/master
The result of these commands is that you have a branch that branches off of the latest commit to the main kframework repository, but pushes to whichever repository you normally push upstream to.