Git Extensions USER Manual


Git Extensions U S E R M A N U A L Henk Westhuis Version 0.93 Git Extensions User Manual Page 2 of 58 Index 1 GIT EXTENSIONS ................................................................................................................................4 1.1 FEATURES ........................................................................................................................................4 1.2 VIDEO TUTORIALS .............................................................................................................................4 2 GETTING STARTED .............................................................................................................................5 2.1 INSTALL ............................................................................................................................................5 2.2 SETTINGS .........................................................................................................................................6 2.3 START PAGE ................................................................................................................................. 13 2.4 CLONE EXISTING REPOSITORY ........................................................................................................ 14 2.5 CREATE NEW REPOSITORY ............................................................................................................. 15 3 BROWSE REPOSITORY ................................................................................................................... 16 3.1 VIEW COMMIT LOG ......................................................................................................................... 16 3.2 SEARCH HISTORY .......................................................................................................................... 17 3.3 SINGE FILE HISTORY ....................................................................................................................... 19 3.4 BLAME .......................................................................................................................................... 20 4 COMMIT ............................................................................................................................................. 21 4.1 COMMIT CHANGES ......................................................................................................................... 21 4.2 CHERRY PICK COMMIT .................................................................................................................... 25 4.3 REVERT COMMIT ............................................................................................................................ 25 4.4 STASH CHANGES ........................................................................................................................... 26 5 TAG .................................................................................................................................................... 27 5.1 CREATE TAG .................................................................................................................................. 27 5.2 DELETE TAG .................................................................................................................................. 27 6 BRANCHES ....................................................................................................................................... 28 6.1 CREATE BRANCH ........................................................................................................................... 28 6.2 CHECKOUT BRANCH ....................................................................................................................... 28 6.3 MERGE BRANCHES ........................................................................................................................ 29 6.4 REBASE BRANCH ........................................................................................................................... 30 6.5 DELETE BRANCH ............................................................................................................................ 31 7 PATCHES .......................................................................................................................................... 32 7.1 CREATE PATCH .............................................................................................................................. 32 7.2 APPLY PATCHES ............................................................................................................................ 33 8 REMOTE FEATURES ........................................................................................................................ 34 8.1 MANAGE REMOTE REPOSITORIES .................................................................................................... 34 8.2 CREATE SSH KEY ......................................................................................................................... 35 8.2.1 PuTTY and github ................................................................................................................ 35 8.2.2 OpenSSH and github ........................................................................................................... 37 8.3 PULL CHANGES .............................................................................................................................. 38 8.4 PUSH CHANGES ............................................................................................................................. 41 9 MERGE CONFLICTS ......................................................................................................................... 42 9.1 HANDLE MERGE CONFLICTS ............................................................................................................ 42 10 NOTES ............................................................................................................................................. 44 11 SUBMODULES ................................................................................................................................ 45 11.1 MANAGE SUBMODULES ................................................................................................................ 45 11.2 ADD SUBMODULE ......................................................................................................................... 46 11.3 REMOVE SUBMODULE .................................................................................................................. 46 12 MAINTENANCE ............................................................................................................................... 47 Git Extensions User Manual Page 3 of 58 12.1 COMPRESS GIT DATABASE ........................................................................................................... 47 12.2 RECOVER LOST OBJECTS ............................................................................................................. 47 12.3 FIX USER NAMES .......................................................................................................................... 49 12.4 IGNORE FILES .............................................................................................................................. 50 13 TRANSLATIONS ............................................................................................................................. 51 13.1 CHANGE LANGUAGE ..................................................................................................................... 51 13.2 TRANSLATE GIT EXTENSIONS ....................................................................................................... 51 14 INTEGRATION ................................................................................................................................. 53 14.1 VISUAL STUDIO ............................................................................................................................ 53 14.2 WINDOWS EXPLORER .................................................................................................................. 55 15 COMMAND LINE ............................................................................................................................. 56 15.1 GIT EXTENSIONS COMMAND LINE .................................................................................................. 56 GIT CHEAT SHEET ............................................................................................................................. 58 1 Git Extensions Git Extensions is a toolkit aimed to make working with Git under Windows more intuitive. The shell extension will integrate in Windows Explorer and presents a context menu on files and directories. There is also a Visual Studio plug-in to use Git from the Visual Studio IDE. The source code of Git Extensions is located here: http://github.com/spdr870/gitextensions/tree/master 1.1 Features • Windows Explorer integration for Git 77 • Visual Studio (2005/2008/2010) plug-in for Git • Feature rich user interface for Git • Single installer installs Git, Git Extensions and the merge tool KDiff3 • 32bit and 64bit support 1.2 Video tutorials There are video tutorials for some basic functions on YouTube. • 1 Clone - Git Extensions - http://www.youtube.com/watch?v=TlZXSkJGKF8 • 2 Commit changes - http://www.youtube.com/watch?v=B8uvje6X7lo • 3 Push changes - http://www.youtube.com/watch?v=JByfXdbVAiE • 4 Pull changes - http://www.youtube.com/watch?v=9g8gXPsi5Ko • 5 Handle merge conflicts - http://www.youtube.com/watch?v=Kmc39RvuGM8 2 Getting started 2.1 Install There is a single click installer that installs MSysGit, kdif3 and Git Extensions. The installer will detect if 32bit and/or 64bit versions should be installed. The installer can here: http://code.google.com/p/gitextensions/ Git Extensions depends heavily on MSysGit. When MSysGit is not installed install this first. Kdiff3 is optional, but is advised as a merge tool. Choose the options to install. Choose the SSH client to use. PuTTY is the default because it has better windows integration. 2.2 Settings All settings will be verified when Git Extensions is started for the first time. If Git Extensions requires any settings to be changed the settings dialog will be shown. All incorrect settings will be marked red. You can ask Git Extensions to try to fix the setting for you by clicking on it. All settings that are specific to Git Extensions will be stored in the Windows registry. The settings that are used by Git are stored in the configuration files of Git. The global settings are stored in a file called .gitconfig in the user directory. The local settings are stored in the .git\config file of the repository. The 'Git' tab contains the settings needed to access git repositories. The database will be accessed using external tools. For Windows usually msysgit or cygwin are used. Git Extensions will try to configure these settings automatically. Command to run git (git.cmd or git.exe) Needed for Git Extensions to run Git commands. Set the full command used to run git (msysgit or cygwin). Path to Linux tools A few linux tools are used by Git Extensions. When msysgit is installed, these tools are located in the bin directory of msysgit. The global configuration file used by git will be put in the home directory. On some systems the home directory is not set or is pointed to a network drive. Git Extensions will try to detect the optimal setting for your environment. When there is already a global git configuration file, this location will be used. If you need to relocate the home directory for git, change this setting. Otherwise leave this setting on default. The ‘Git Extension’ tab contains all settings needed for Git Extension to run properly. The path to git.cmd and git.exe can be set here. This is only needed when these are not in the system path. Limit number of commits that will be loaded in list at start-up. Git Extensions uses lazy loading to load the commit log. Lower this number to increase the start-up speed. Increase the number for faster scrolling. Turn of revision graph for optimal result! Language Choose the language for the Git Extensions interface Dictionary for spelling checker Choose the dictionary to use for the spelling checker in the commit dialog. Smtp server for sending patches Smtp server to use for sending patches. Show current working dir changes in revision graph. When enabled, two extra revisions are added to the revision graph. The first shows the current working directory status. The second shows the staged files. This option can cause slowdowns when browsing large repositories. Show stash count on status bar in browse window When you use the stash a lot, it can be useful to show the number of stashed items on the toolbar. This option causes serious slowdowns in large repositories and is turned off by default. Close process dialog automatically when process is succeeded When a process is finished, clause the process dialog automatically. Leave this option off if you want to see the result of processes. When a process has been failed, the dialog will keep open. Show Git command line dialog when executing process. Git Extensions uses command line tools to access the git database. In some environments it might be useful to see the command line dialog. Show revision graph in commit log. Turn revision graph in commit log on/off. Show Git command line dialog when executing process. Turn this option on if you want to see the Git command line dialog when a process is executed. Use FileSystemWatcher to check if index is changed Using the FileSystemWatcher to check index state improves the performance is some cases. Turn this off if you experience refresh problems in commit log. Show relative date instead of full date. Show relative date, e.g. 2 weeks ago, instead of full date. Follow renames in file history Try to follow file renames in the file history. Revision graph quicksearch timeout [ms] The timeout used for the quicksearch feature in the revision graph. The quicksearch will be enabled when you start typing and the revision graph is focussed. Encoding Choose the encoding you want GitExtensions to use The items on the Start Page can be edited. In this tab you can add and remove categories. Per category you can either configure a RSS feed or add repositories. The order can be changed using the context menus in the Start Page. In the appearance tab the following items can be set: Revision graph colors The colors that are used in the revision graph Difference view colors The colors that are used to mark changes Application Icon The color of the application icon. This is useful for recognising various open instances. Author images Enable or disable downloading author images from gravatar.com. With the “Clear image cache” the cached items can be removed. No image service In the ‘Global settings’ tab some global Git settings can be set. User name User name shown in commits and patches User email User email shown in commits and patches Editor Editor that git.exe opens (e.g. for editing commit message). This is not used by Git Extensions, only when you call git.exe from the command line. By default Git will use the command line text editor vi. Mergetool Merge tool used to solve merge conflicts. Git Extensions will search for common merge tools on your system. Path to mergetool Path to merge tool. Git Extensions will search for common merge tools on your system. Mergetool command Command that Git uses to call the merge tool. Git Extensions will try to set this automatic when a merge tool is chosen. This setting can be left empty when Git supports the mergetool (e.g. kdiff3) DiffTool DiffTool that is used Path to DiffTool The path to the difftool. DiffToolCommand Command that Git uses to start the DiffTool. This setting should only be filled when Git doesn't support the mergetool. Line endings Choose how git should handle line endings. In the tab ‘SSH’ you can configure the SSH client you want Git to use. Git Extensions is optimized for PuTTY. Git Extensions will show command line dialogs if you do not use PuTTY and user input is required. Git Extensions can load SSH keys for PuTTY when needed. 2.3 Start Page The start page contains the most common tasks, recently opened repositories and favourites. The left side of the start page is static. The other items can be edited. Repositories can be moved to favourites using the context menu. Choose edit to add new repositories to any category. 2.4 Clone existing repository You can clone an existing repository using the ‘Clone’ menu option. You can choose the repository type to clone to. For personal use you need to choose ‘Personal repository’. For a central or public repository, choose ‘Central repository’. A central repository does not have a working directory. The repository you want to clone could be on a network share or could be a repository that is accessed through an internet or intranet connection. Depending on the protocol (http or ssh) you might need to load a SSH key into PuTTY. There are two different types of repositories you can create when making a clone. A personal repository contains the complete history and also contains a working copy of the source tree. A central repository is used as a public repository where developers push there changes they want to share with others to. A central repository contains the complete history but to not have a working directory like personal repositories. 2.5 Create new repository When you do not want to work on an existing project, you can create your own repository. Choose the menu option ‘Init new repository’ to create a new repository. You can choose to create a Personal repository or a Central repository. A personal repository looks the same as a normal working directory but has a directory named .git on root level containing the version history. This is the most common repository. Central repositories only contain the version history. Because a central repository has no working directory you cannot checkout a revision in a central repository. It is also impossible to merge or pull changes is a central repository. This repository type can be used as a public repository where developers can push changes to or pull changes from. 3 Browse repository You can browse a repository by starting Git Extensions and select the repository to open. The main window contains the commit log. You could also open the ‘Browse’ window from the shell extensions and from the Visual Studio IDE. 3.1 View commit log The full commit history can be browsed. There is a graph that shows branches and merges. You can show the difference between two revision by selection them using ctrl-click. In the context menu of the commit log you can enable or disable the revision graph. You can also choose to only show the current branch instead of showing all branches. The other options will be discussed later. 3.2 Search history The history can be searched using regular expressions are basic search terms. The quick filter in the toolbar searches in the commit message, the author and the committer. In the context menu of the commit log you can open the advanced filter dialog. The advanced filter dialog allows you to search for more specific commits. To remove the filter either remove the filter in the toolbar and press enter or remove the filter in the advanced filter dialog. 3.3 Singe file history The single file history viewer shows all revisions of a single file. You can view the content of the file in after each commit in the ‘View’ tab. You can view the difference report from the commit in the ‘Diff’ tab. Added lines are marked with a ‘+’, removed lines are marked with a ‘–‘. 3.4 Blame There is a blame function in the file history browser. It shows the last person editing a single line. Double clicking on a code line shows the full commit introducing the change. 4 Commit A commit is a set of changes with some extra information. Every commit contains the follow information: • Changes • Committer name and email • Commit date • Commit message • Cryptographically strong SHA1 hash Each commit creates a new revision of the source. Revisions are not tracked per file; each change creates a new revision of the complete source. Unlike most traditional source control management systems, revisions are not named using a revision number. Each revision is named using a SHA1, a 41 long characters cryptographically strong hash. 4.1 Commit changes Changes can be committed to the local repository. Unlike most other source control management systems you do not need to checkout files before you start editing. You can just start editing files, and review all the changes you made in the commit dialog later. When you open de commit dialog, all changes are listed in the top-left. There are three kinds of changes: Untracked This file is not yet tracked by Git. This is probably a new file, or a file that has not been committed to Git before. Modified This file is modified since the last commit. Deleted This file has been deleted. When you rename or move a file Git will notice that this file has been moved, but currently Git Extensions does not show this in the commit dialog. Occasionally you will need to undo the file change. This can be done in the context menu of any unstaged file. During your initial commit there are probably lots of files you do not want to be tracked. You can ignore these files by not staging them, but they will show every time. You could also add them to the .gitignore file of you repository. Files that are in the .gitignore file will not show up in the commit dialog again. You can open the .gitignore editor from the menu ‘Working dir changes’. You need to stage the changes you want to commit by pressing the ‘Stage selected files’ button. You also need to stage deleted files because you stage the change and not the file. When all the changes you want to commit are staged, enter a commit message and press the commit button. It is also possible to add files to you last commit using the ‘Amend to last commit’ button. This can be very useful when you forgot some changes. This function rewrites history; it deletes the last commit and commits it again including the added changes. Make sure you only use ‘Amend to last commit’ when the commit is not yet published to other developers. There is a build in spelling checker that checks the commit message. Incorrect spelled words are underlined with a red wave line. By right-clicking on the misspelled word you can choose the correct spelling or one of the other options. Git Extensions installs a number of dictionaries by default. You can choose another language in the context menu of the spelling checker or in the settings dialog. To add a new spelling dictionary add the dictionary file to the 'Dictionaries' folder inside the Git Extensions installation folder. 4.2 Cherry pick commit A commit can be recommitted by using the cherry pick function. This can be very useful when you want to make the same change on multiple branches. 4.3 Revert commit A commit cannot be deleted once it is published. If you need to undo the changes made in a commit, you need to create a new commit that undoes the changes. This is called a revert commit. 4.4 Stash changes If there are local changes that you do not want to commit yet and not want to throw away either, you can temporarily stash them. This is useful when working on a feature and you need to start working on something else for a few hours. You can stash changes away and then reapply them to your working dir again later. Stashes are typically used for very short periods. You can create multiple stashes if needed. Stashes are shown in the commit log with the text [stash] . The stash is especially useful when pulling remote changes into a dirty working directory. If you want a more permanent stash, you should create a branch. 5 Tag Tags are used to mark a specific version. Usually a tag will not be moved anymore. The image below shows the commit log of Git Extensions with to tags indicating version [1.08] and [1.06] . 5.1 Create tag In Git Extensions you can tag a revision by choosing ‘Create new tag’ in the commit log context menu. A dialog will prompt for the name of the tag. You can also choose ‘Create tag’ from the ‘Commands’ menu, which will show a dialog to choose the revision and enter the tag name. Once a tag is created, it cannot be moved again. You need to delete the tag and create it again to move it. 5.2 Delete tag For some operation it is very useful to create tags for temporary usage. Git uses SHA1 hashes to name each commit. When you want to merge with an unnamed branch it is good practise to tag the unnamed branch, merge with the tag and then delete the tag again. 6 Branches Branches are used to commit changes separate from other commits. It is very common to create a branch when you start working on a feature and you are not sure if this feature will be finished in time for the next release. The image on the right illustrates a branch created on top of commit B. In Git branches are created very often. Creating a branch is very easy to do and it is recommended to create a branch very often. In fact, when you make a commit to a cloned repository you start a new branch. I will explain this in the pull chapter. You can check on what branch you are working in the toolbar. 6.1 Create branch In Git Extensions there are multiple ways to create a new branch. In the image below I create a new branch from the context menu in the commit log. This will create a new branch on the revision that is selected. I will create a new branch called ‘Refactor’. In this branch I can do whatever I want without considering others. In the ‘Create branch’ dialog there is a checkbox you can check if you want to checkout this branch immediate after the branch is created. When the branch is created you will see the new branch [Refactor] in the commit log. If you chose to checkout this branch the next commit will be committed to the new branch. Creating branches in Git requires only 41 bytes of space in the repository. Creating a new branch is very easy and is very fast. The complete work flow of Git is optimized for branching and merging. 6.2 Checkout branch You can switch from the current branch to another branch using the checkout command. Checkout a branch sets the current branch and updates all sources in the working directory. Uncommitted changes in the working directory can be overwritten, make sure your working directory is clean. 6.3 Merge branches In the image below there are two branches, [Refactor] and [master] . We can merge the commits from the master branch into the Refactor. If we do this, the Refactor branch will be up to date with the master branch, but not the other way around. As long as we are working on the Refactor branch we cannot tough the master branch itself. We can merge the sources of master into our branch, but cannot make any change to the master branch. To merge the Refactor branch into the master branch, we need to switch to the master branch first. Once we are on the master branch we can choose merge by choosing ‘Merge branches’ from the ‘Commands’ menu. In the merge dialog you can check the branch you are working on. After selected the branch to merge with, click the ‘Merge’ button. After the merge the commit log will show the new commit containing the merge. Notice that the Refactor branch is not changed by this merge. If you want to continue working on the Refactor branch you can merge the Refactor branch with master. You could also delete the Refactor branch if it is not used anymore. When you need to merge with on unnamed branch you can use a tag to give it a temporary name. 6.4 Rebase branch The rebase command is the most complex command in Git. The rebase command is very similar to the merge command. Both rebase and merge are used to get a branch up-to-date. The main difference is that rebase can be used to keep the history linear contrary to merges. A rebase of Refactor on top of master will perform the following actions: • All commits specific to the Refactor branch will be stashed in a temporary location • The branch Refactor will be removed • The branch Refactor will be recreated on the master branch • All commits will be recommitted in the new Refactor branch During a rebase merge conflicts can occur. You need to solve the merge conflicts for each commit that is rebased. The rebase function in Git Extensions will guide you through all steps needed for a successful rebase. The image below shows the commit log after the rebase. Notice that the history is changed and is seems like the commits on the Refactor branch are created after the commits on the master branch. Because this function rewrites history you should only use this on branches that are not published to other repositories yet. When you rebase a branch that is already pushed it will be harder to pull or push to that remote. If you want to get a branch up-to-date that is already published you should merge. 6.5 Delete branch It is very common to create a lot of branches. You can delete branches when they are not needed anymore and you do not want to keep the work done in that branch. When you delete a branch that is not yet merged, all commits will be lost. When you delete a branch that is already merged with another branch, the merged commits will not be lost because they are also part of another branch. You can delete a branch using ‘Delete branch’ in ‘Commands’ menu. If you want to delete a branch that is not merged into another branch, you need to check the ‘Force delete’ checkbox. 7 Patches Every commit contains a change-set, a commit date, the committer name, the commit message and a cryptograph SHA1 hash. Local commits can be published by pushing it to a remote repository. To be able to push you need to have sufficient rights and you need to have access to the remote repository. When you cannot push directly you can create patches. Patches can be e-mailed to someone with access to the repository. Each patch contains an entire commit including the commit message and the SHA1. 7.1 Create patch Format a single patch or patch series using the format patch dialog. You need to select the newest commit first and then select the oldest commit using ctrl-click. You can also select an interrupted patch series, but this is not recommended because the files will not be numbered. When the patches are created successfully the following dialog will appear. 7.2 Apply patches It is possible to apply a single patch file or all patches in a directory. When there are merge conflicts applying the patch you need to resolve them before you can continue. Git Extensions will help you applying all patches by marking the next recommended step. 8 Remote features Git is a distributed source control management system. This means that all changes you make are local. When you commit changes, you only commit them to your local repository. To publish your local changes you need to push. In order to get changes committed by others, you need to pull. 8.1 Manage remote repositories You can manage the remote repositories in the ‘Remotes’ menu. When you cloned your repository from a public repository, this remote is already configured. You can rename each remote for easy recognition. The default name after cloning a remote is ‘origin’. If you use PuTTY as SSH client you can also enter the private key file for each remote. Git Extensions will load the key when needed. How to create a private key file is described in the next paragraph. In the ‘Default pull behaviour’ tab you can configure the branches that need to be pulled and merged by default. If you configure this correctly you will not need to choose a branch when you pull or push. There are two buttons on this dialog: Prune remote branches Throw away remote branches that do not exist on the remote anymore Update all remote branch info Fetch all remote branch information After cloning a repository you do not need to configure all remote branches manually. Instead you can checkout the remote branch and choose to create a local tracking branch. 8.2 Create SSH key Git uses SSH for accessing private repositories. SSH uses a public/private key pair for authentication. This means you need to generate a private key and a public key. The private key is stored on your computer locally and the public key can be given to anyone. SSH will encrypt whatever you send using your secret private key. The receiver will then use the public key you send to decrypt the data. This encryption will not protect the data itself but it protects the authenticity. Because the private key is only available to the sender, the receiver can be sure about the origin of the data. In practise the key pair is only used for the authentication process. The data itself will be encrypted using a key that is exchanged during this initial phase. 8.2.1 PuTTY and github PuTTY is SSH client that for Windows that is a bit more user friendly then OpenSSH. Unfortunately PuTTY does not work with all servers. In this paragraph I will show how to generate a key for github using putty. First make sure GitExtensions is configured to use PuTTY and all paths are correct. In the Re mot es me nu you can choose “Generate or import key” to start the key generator. PuTTY will ask you to move the mouse around to generate a more random key. When the key is generated you can save the public and the private key in a file. You can choose to protect the private key with a password but this is not necessary. Now you have a key pair you need to give github the public key. This can be done in “Account Settings” in the tab “SSH Public Keys”. You can add multiple keys here, but you only need one key for all repositories. After telling github what public key to use to decrypt, you need to tell GitExtensions what private key to use to encrypt. In the clone dialog there is a “Load SSH key” button to load the private key into the PuTTY authentication agent. This can also be done manually by starting the PuTTY authentication agent and choose “add key” in the context menu in the system tray. GitExtensi ons can load the private keys automatica lly for you when communic ating with a remote. You need to configure the private key for the remote. This is done in the “Manage remote repositories” dialog. 8.2.2 OpenSSH and github When you choose to use OpenSSH you need to configure GitExtensions as shown in the screenshot below. OpenSSH is the best SSH client there is but it lacks Windows support. Therefore it is slightly more complex to use. Another drawback is that GitExtensions cannot control OpenSSH and needs to show the command line dialogs when OpenSSH might be used. GitExtensions will show the command line window for every command that might require a SSH connection. For this reason PuTTY is the prefered SSH client in GitExtensions. To generate a key pair in OpenSSH you need to go to the command line. I recommend to use the git bash because the path to OpenSSH is already set. Type the following command: ssh-keygen -C “ your@email.com ” -t rsa Use the same email address as the email address used in git. You will be asked where if you want to protect the private key with a password. This is not necessary. By default the public and private keys are stored in “c:\Documents and Settings\[User]\.ssh\” or “c:\Users\[user]\.ssh\”. You do not need to tell GitExtensions about the private key because OpenSSH will load it for you. Now open the public key using notepad and copy the key to github. This can be done in “Account Settings” in the tab “SSH Public Keys” on http://www.github.com . 8.3 Pull changes You can get remote changes using the pull function. Before you can pull remote changes you need to make sure there are no uncommitted changes in your local repository. If you have uncommitted changes you should commit them or stash them during the pull. You can read about how to use the stash in the Stash chapter. In order to get your personal repository up-to-date, you need to fetch changes from a remote repository. You can do this using the ‘Pull’ dialog. When the dialog starts the default remote for the current branch is set. You can choose another remote or enter a custom url if you like. When the remote branches configured correctly, you do not need to choose a remote branch. If you just fetch the commits from the remote repository and you already committed some changes to your local repository, the commits will be in a different branch. In the pull dialog this is illustrated in the image on the left. This can be useful when you want to review the changes before you want to merge them with your own changes. When you choose to merge the remote branch after fetching the changes a branch will be created, and will be merged you’re your commit. Doing this creates a lot of branches and merges, making the history harder to read. Instead of merging the fetched commits with your local commits, you can also choose to rebase your commits on top of the fetched commits. This is illustrated on the left in the image below. A rebase will first undo your local commits (c and d), then fetch the remote commits (e) and finally recommit your local commits. When there is a merge conflict during the rebase, the rebase dialog will show. Next to the pull button there are some buttons that can be useful: Solve conflicts When there are merge conflicts, you can solve them by pressing this button. Stash changes When the working dir contains uncommitted changes, you need to stash them before pulling. Auto stash Check this checkbox if you want to stash before pulling. The stash will be reapplied after pulling. Load SSH key This button is only available when you use PuTTY as SSH client. You can press this button to load the key configured for the remote. If no key is set, a dialog will prompt for the key. 8.4 Push changes In the browse window you can check if there are local commits that are not pushed to a remote repository yet. In the image below the green labels mark the position of the master branch on the remote repository. The red label marks the position of the master branch on the local repository. The local repository is ahead three commits. To push the changes press ‘Push’ in the toolbar. The push dialog allows you to choose the remote repository to push to. The remote repository is set to the remote of the current branch. You can choose another remote or choose a url to push to. You can also specify a branch to push. Tags are not pushed to the remote repository. If you want to push a tag you need to open the `Tags` tab in the dialog. You can choose to push a singe tag or all tags. No commits will be pushed when the `Tags` tab is selected, only tags. You can not merge your changes in the remote repository. Merging must be done locally. This means that you cannot push your changes before the commits are merged locally. In practice you need to pull before you can push most of the times. 9 Merge conflicts When merging branches or commits you can get merge conflicts. Git will try to resolve these, but some conflicts need to be resolved manually. Git Extensions will show warnings when there is a merge conflict. 9.1 Handle merge conflicts To solve merge conflicts just click on a warning or open the merge conflict dialog from the menu. A dialog will prompt showing all conflicts. You can solve a conflict by double-click on a filename. There are three kinds of conflicts: File deleted and changed Use modified or deleted file? File deleted and created Use created or deleted file? File changed both locally and remotely Start merge tool. If the file is deleted in one commit and changed in another commit, a dialog will ask to keep the modified file or delete the file. When there is a conflicting change the merge tool will be started. You can configure the tool you want to use for merge conflicts. The image below shows Perforce P4Merge a free to use merge tool. Git Extensions is packaged with KDiff3, an open source merge tool. In the merge tool you will see four versions of the same file: Base The latest version of the file that exist in both repositories Local The latest local version of the file Remote The latest remote version of the file Merged The result of the merge When you are in the middle of a merge the file named local represents your file. When you are in the middle of a rebase the file named remote represents your file. This can be confusing, so double check if you are in doubt. 10 Notes Notes can be added to a commit. Notes will be stored separately and will not be pushed. To add a new note choose “add notes” in the context menu of the commit information box. The editor that has been configured in the settings dialog will be used to enter or edit the notes. The Git Extensions editor is advised. 11 Submodules Large projects can be split into smaller parts using submodules. A submodule contains the name, url and revision of another repository. To create a submodule in an existing git repository you need to add a link to another repository containing the files of the submodule. 11.1 Manage submodules The current state of the submodules can be viewed with the ‘Manage submodules’ function. All submodules are shown in the list on the left. Add submodule Add a new submodule to the repository Synchronize Synchronizes the remote URL configuration setting to the value specified in .gitmodules for the selected submodule. Initialize Initialize the selected submodules, i.e. register each submodule name and url found in .gitmodules into .git/config. The submodule will also be updated. Update Update the registered submodules, i.e. clone missing submodules and checkout the commit specified in the index of the containing repository. 11.2 Add submodule To add a new submodule choose ‘Add submodule’ in the ‘Manage submodules’ dialog. Path to submodule Path to the remote repository to use as submodule. Local path Local path to this submodule, relative to the root of the current repository. Branch Branch to track 11.3 Remove submodule It is currently not possible to remove a submodule using the Git Extensions user interface. To remove a submodule you need to manually: • Delete the relevant line from the .gitmodules file. • Delete the relevant section from .git/config. • Run git rm --cached path_to_submodule (no trailing slash). • Commit and delete the now untracked submodule files. 12 Maintenance In this chapter some of the functions to maintain a repository are discussed. 12.1 Compress Git database Git will create a lot of files. You can run the ‘Compress git database’ to pack all small files building up a repository into one big file. Git will also garbage collect all unused objects that are older then 15 days. When a database is fragmented into a many small files compressing the database can increase performance. 12.2 Recover lost objects If you accidently deleted a commit you can try to recover it using the `Recover lost objects´ function. A dialog will show you all dangling objects and will allow you to review and recover them. Normally Git will not delete files right away when you remove something from your repository. The reason for this is that you can restore deleted items if you need to. Git will delete removed items when they are older then 15 days and you run ‘Compress git database’. There are several functions to help you find the lost items. By default Git Extensions will only show commits. To show all items, just uncheck the 'Show only commits' option. The other options can be checked/unchecked to get more/less results. Double-click on on item to view the content. When you located the item you want to recover you can tag it using the 'Tag selected object' button. Git Extensions also is able to tag all lost objects. Doing this will make all lost objects visible again making it very easy to locate the commit(s) you would like to recover. After recovering a commit using the 'Tag all lost commits' button, you can remove all tags using the 'Delete all LOST_AND_FOUND tags' button. 12.3 Fix user names When someone accidentally committed using a wrong username this can be fixed using the ‘Edit .mailmap’ function. Git will use the username for an email address when it is set in the .mailmap file. Fix user name using commit email: Proper Name Fix email address using commit email: Fix email address and name using commit email: Proper Name Fix email address and name using commit name and email Proper Name Commit Name 12.4 Ignore files Git will track all files that are in the working directory. Normally you do not want to exclude all files that are created by the compiler. You can add files that should be ignored to the .gitignore file. You can use wildcards and regular expressions. All entries are case sensitive. The button ‘Add default ignores’ will add files that should be ignored when using Visual Studio. A short overview of the syntax: # Lines started with '#' are handled as comments ! Lines started with '!' are exclude patterns [Dd] Characters inside [..] means that 1 of the characters must match * Wildcard / A leading slash matches the beginning of the pathname; for example, "/*.c" matches "cat-file.c" but not "mozilla-sha1/sha1.c" / If the pattern ends with a slash, it is removed for the purpose of the following description, but it would only find a match with a directory. In other words, foo/ will match a directory foo and paths underneath it, but will not match a regular file or a symbolic link foo (this is consistent with the way how pathspec works in general in git). For more detailed information: http://www.kernel.org/pub/software/scm/git/docs/gitignore.html 13 Translations 13.1 Change language In the settings dialog a translation can be chosen. The translation files are located in a directory located in the Git Extensions installation directory. The files are readable xml files. 13.2 Translate Git Extensions The application has a build in translation tool to help create and edit translations. To open the translation tool choose “Translate” in the “Help” menu. The functions of the translation tool are described in the image below. To contribute any translations you can either e-mail a patch or send a pull request using github. 14 Integration During installation you can choose to install the Visual Studio plug-in and shell extensions. 14.1 Visual Studio There are two options in the context menu on files. - View the file history by choosing the ‘File history’ option. - Reset the file changes to the last committed revision. A Git Extensions toolbar allows you to perform the most common actions. Commit (branch) Browse Pull Push Stash changes Settings Almost all function can be started from the ‘Git’ menu in Visual Studio. 14.2 Windows Explorer The common commands can be started from Windows Explorer using the shell extensions. This option is only available when Shell Extensions are installed. 15 Command line 15.1 Git Extensions command line Most features can be started from the command line. It is recommended to add gitex.cmd to the path when using from the command line. The following functions are available from the command line: • browse • add • addfiles • apply • applypatch • branch • checkout • checkoutbranch • checkoutrevision • cleanup • clone [path] • commit [--quiet] • filehistory [file] • formatpatch • init • pull [--rebase] [--merge] [--fetch] [--remotebranch] [--quiet] • push [--quiet] • settings • viewdiff • rebase [--branch name] • merge [--branch name] • cherry • tag • stash • synchronize [--rebase] [--merge] [--fetch] [--quiet] Git Cheat Sheet Create new repository $ git init Create shared repository $ git init –-bare –-shared=all Clone repository $ git clone c:/demo1 c:/demo2 Checkout branch $ git checkout Create branch $ git branch Delete branch $ git branch -d Merge branch (from the branch to merge into) $ git merge PDC Solve conflicts (add --tool=kdiff3 if no mergetool is specified) $ git mergetool $ git commit Create tag $ git tag Add files/changes (. for all files) $ git add . Commit added files/changes (--amend to amend to last commit) $ git commit –m “Enter commit message” Discard changes $ git reset --hard Create patch (-M = detect renames –C = detect copies) $ git format-patch –M –C origin Apply patch without merging $ git apply c:/patch/0001-employee.patch Merge patch $ git am -–3way –-signoff c:/patch/0001- employee.patch Solve conflicts (add --tool=kdiff3 if no mergetool is specified) $ git mergetool $ git am –-3way -–resolved Stash changes $ git stash Apply stashed changes $ git stash apply Pull changes (add --rebase to rebase instead of merge) $ git pull c:/demo1 master Solve conflicts (add --tool=kdiff3 if no mergetool is specified) $ git mergetool $ git commit Push changes (in branch $ git push c:/demo1 master master:) $ git push c:/demo1 Blame $ git blame –M –w Help $ git --help Default names master : default branch origin : default upstream repository HEAD : current branch HEAD^ : parent of HEAD HEAD~4 : the great-great grandparent of HEAD
还剩57页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享pdf获得金币 ] 0 人已下载

下载pdf

pdf贡献者

1185391239

贡献于2014-04-20

下载需要 8 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf