Basic Git
- Resources on the Web
- Looking at history
- Switching Branches
- Looking at local changes
- Rebasing a feature branch
- Dealing with Merge Conflicts
- Getting the Latest Changes From the Main Repo
- Bypass Code Review
ProGit book http://git-scm.com/book
In Git Gui select Repository-->Visualize ’s History or Visualize All Branch History. The latter shows the history of all branches. It also shows the state of the different branches and visualizes merges between different branches.
It’s also possible to select Git History in the context menu of Windows Explorer. Doing that on a file or on a subfolder of the repo gives the history for that particular file or folder.
$ git log
Open Git Gui and select Branch-->Checkout. Select the branch you want to switch to and press the Checkout button.
$ git checkout feature/F-010
To see what code has changed locally, you can open Git Gui. The left side shows the modified files and files that are not in the repo yet. After selecting one, the differences are shown in the top right. To see the changes of a file side-by-side, select Tools-->Visual Diff. This will show the differences of the selected file in P4Merge or kdiff3 (depending on what you selected in the initrepo script).
To see what files changed:
$ git status
To see the differences:
$ git diff
or
$ git diff relative/path/to/file
To see the differences in a UI tool:
$ git difftool
If someone else submitted changes to the remote repo after you uploaded changes to Gerrit for review, Gerrit will add an error as comment when you try to submit your change. In this case you need to rebase your feature branch to the latest changes in the develop branch.
In Git Gui select Tools-->Rebase while you’re on the feature branch. This will fetch the latest changes and rebase your feature branch to the latest develop branch. Afterwards you can re-upload your changes to Gerrit for code review. If it was a simple rebase without any conflicts, Gerrit will realize this and re-apply the verified and reviewed status to the new patch set.
If you get conflicts during the rebase the mergetool will be started automatically. To abort the rebase, exit the merge tool without making any changes. This will cause the rebase script to abort the rebase in process.
(feature/myfeature)$ git fetch origin
(feature/myfeature)$ git rebase origin/develop
If you get any conflicts:
(feature/myfeature)$ git mergetool
(feature/myfeature)$ git rebase --continue
or to abort:
(feature/myfeature)$ git rebase --abort
If a merge or rebase fails because there are conflicts, you can use the mergetool to resolve the conflicts.
In Git Gui select Tools-->Visual Merge. This will open p4merge or kdiff3. When all conflicting files are resolved you need to commit the merged files by pressing the Commit button in Git Gui.
If the merge conflict occurred while finishing a feature/release/hotfix/support branch, select Tools-->Visual Merge and Push instead. This will open p4merge or kdiff3, commit the changes and push them to the remote repo. Afterwards you need to switch to the correct branch and select the feature/release/hotfix/support finish command again.
$ git mergetool
$ git commit
For a merge conflict happening during a feature/release/hotfix/support branch finish, you’ll also need to push the changes to the remote repo:
$ git push review --all
$ git push review --tags
Afterwards you need to switch to the correct branch and issue the feature/release/hotfix/support finish command again.
To get the latest changes for the branch you’re currently working on, open Git Gui and select Tools-->Rebase.
(develop) $ git pullrebase
This fetches the latest changes from origin and rebases the current branch.
It is possible to bypass code review and directly push to the remote repository.
Open Git Gui. If necessary switch to Develop branch (Branch-->Checkout), then select Tools-->Bypass Code Review. This will push all changes on the Develop branch that are not yet on the remote repo.
(develop) $ git push origin develop