This page describes the commands often used while working with git.
In addition to these basic commands, please make sure you have read:
To modify existing files:
git add filename git commit -m "ISIS-nnn: yada yada"
git add command adds the changes to the file(s) to the git index (aka staging area). If you were to make subsequent changes to the file these would not be committed.
git commit takes all the staged changes and commits them locally. Note that these changes are not shared public with Isis' central git repo.
You can combine these two commands using
-am flag to git commit:
git commit -am "ISIS-nnn: yada yada"
To add a new file:
git add . git commit -m "ISIS-nnn: yada yada"
Note that this sequence of commands is identical to modifying an existing file. However, it isn't possible to combine the two steps using
git commit -am; the
git add is always needed when adding new files to the repo.
To delete a file:
git rm filename git commit -m "ISIS-nnn: yada yada"
To rename or move a file:
git mv filename newfilename git commit -m "ISIS-nnn: yada yada"
The contributing page describes the workflow for non-committers. This section is therefore primarily for the benefit of Isis committers.
The easiest way of working is to make your commits directly on your local
master. This is perhaps somewhat hacky, but acceptable for very small changes.
When you are ready to push your changes, use:
git pull --rebase
This will bring down all the latest commits made to the central repo, and update origin/master. It will then apply all commits made in your master branch on top of that.
Alternatively, you can do this in two stages:
git fetch git rebase origin/master
git fetch, you will see that
gitk --all shows the new set of commits as a branch separate from your own commits on branch. The
git rebase command then applies all your changes on top of that branch. (Your original commits are orphaned and are eventually garbage collected by git).
Once you're happy with all your changes, push your local repository onto the central repo:
If you are working on a branch for a significant period (eg to implement a ticket), then it probably makes sense to create a local branch:
git checkout -b branchname
If you use
gitk --all, then you'll see a new tag for the current commit. The command line in the shell also changes.
Any commits made now advance the new branch, but leave the
master branch alone.
If you want to switch to some other branch, use:
git checkout branchname
Any changes in your working directory and index/staging area are preserved. This makes it easy to separate out different strands of work... you realize that some set of changes just made should be on a different ticket, so you create a new branch and commit those changes there.
When you want to 'catch-up' with the changes made by others and in the remote
git checkout branchname git rebase master
This will reapply the commits from
origin on top of the
master branch. If there are conflicts then they will occur a this point. Conflicts are resolved by editing the file, then:
git add filename git rebase --continue
Once the rebase is finished, you'll see the branch branchname as a direct descendent of
gitk --all to confirm). You will still be on the branchname. To catch up
git checkout master git merge branchname --ff-only
--ff-only ensures that the merge is a fast-forward; ie all commits will have only a single parent, and no conflicts.
At this point you can delete the branch:
git branch -d branchname
Immediately prior to pushing your changes, check one more time that you are up-to-date:
If this pulls down any commits, then reintegrate first (using
git rebase) and try again.
Assuming that now new commits were brought down, you can now simply do a fast forward merge of master, and then push the changes:
git checkout master git merge --ff-only ISIS-123-blobs git push
master branch is a direct ancestor of the topic branch, the fast-forward merge should work. The
git push then pushes those changes back to the master Isis repo.
To clean up, you can delete your topic branch:
git branch -d ISIS-123-blobs
If committing to a local branch, the changes are still just that: local, and run risk of a disk failure or other disaster.
To create a new, similarly named branch on the central repo, use:
git push -u origin branchname
gitk --all will show you this new branch, named origin/branchname.
Thereafter, you can push subsequent commits using simply:
Doing this also allows others to collaborate on this branch, just as they would for
When, eventually, you have reintegrated this branch, you can delete the remote branch using:
git push origin --delete branchname
If you are working on something but are not ready to commit, then use:
If you use
gitk --all then you'll see new commits are made that hold the current state of your working directory and staging area.
You can then, for example, pull down the latest changes using
git pull --rebase (see above).
To reapply your stash, then use:
git stash pop
Note that stashing works even if switching branches
Put file patterns into
.gitignore. There is one at the root of the git repo, but they can additionally appear in subdirectories (the results are cumulative).
Suppose you committed to
master, and then pushed the change, and then decided that you didn't intend to do that:
C1 - C2 - C3 - C4 - C5 - C6 - C7 ^ master ^ origin/master
To go back to an earlier commit, first we wind back the local
git reset --hard C5
C5 is the long sha-id for that commit.
This gets us to:
C1 - C2 - C3 - C4 - C5 - C6 - C7 ^ master ^ origin/master
Then, do a force push:
git push origin master --force
If this doesn't work, it may be that the remote repo has disabled this feature. There are other hacks to get around this, see for example here.
If at any time the
git pull from your upstream fails, it most likely means that you must have made commits on the
master branch. You can use
gitk --all to confirm; at some point in time both
origin\master will have a common ancestor.
You can retrospectively create a topic branch for the work you've accidentally done on
First, create a branch for your current commit:
git branch newbranch
Next, make sure you have no outstanding edits. If you do, you should commit them or stash them:
Finally, locate the shaId of the commit you want to roll back to (easily obtained in
gitk -all), and wind
master branch back to that commit:
git checkout master git reset --hard shaId # move master branch shaId of common ancestor
One of our committers, Alexander Krasnukhin, has put together some git scripts to help his workflow. Using one of these,
git prefix, you:
can just commit with proper message without bothering about prefix and add prefix only in the end before the final push.
For example, to prefix all not yet prefixed commits
git prefix ISIS-666 master..isis/666
You can grab this utility, and others, from this repo.
All edits are reviewed before going live, so feel free to do much more than fix typos or links. If you see a page that could benefit from an entire rewrite, we'd be thrilled to review it. Don't be surprised if we like it so much we ask you for help with other pages :)NOTICE: unless indicated otherwise on the pages in question, all editable content available from apache.org is presumed to be licensed under the Apache License (AL) version 2.0 and hence all submissions to apache.org treated as formal Contributions under the license terms.