September 10, 2010 2 Comments
By popular demand (and by demand I mean Donna), here’s a blog about what I know about my basic knowledge of Git Gui (which stands for graphical user interface). I’m going to skip the installation part, since Anna’s done a pretty comprehensive guide here (for Windows) and here (for Mac). There’s also the Github resources for Windows, for Linux and for Mac.
After installation, you can immediately access the gui. For Linux, the easiest way I’ve found is to open up a terminal and type git gui and hit enter. That’ll bring it up for you. For Windows, you can do the same thing with the mysysgit terminal or use the icon provided in the installed folder. I’ve had someone test this with a Mac (I could be wrong since I didn’t do any of the testing myself) and you can only open it up through the icon provided – typing git gui on the console of a Mac just comes up with errors. I’ve also not included how to link your git client to the Github repo (using SSH keys). If you need help with that, just follow these links for Windows, Linux, and Mac.
So after starting up the application, the first screen you get will be the following:
Since this is most likely you’re first start up, I’ve highlighted the clone existing repository link which you would have to click. If you’ve already cloned a repo, just open it using the link below the one I highlighted that says “Open Existing Repository” and skip to the next image past the one below. Cloning, however, gives you the next following screen:
The screen above is pretty self-explanatory. The source is the remote repository and the target is the local one you wish to put it in. After clicking the clone button, you’ll get the main screen as shown below.
I’ve loaded up the main screen with a few changes to help explain the ideas better.
1) It’s what I believe is the most important part. The label tells you what current branch you’re working on. This in itself is way better than the command line as you’d have to type git branch over and over again just to make sure you’re on the right branch. It’s a very useful item.
2) This section includes all the files that have changes and needs to be looked over and staged. This is where you would find items with merge errors as well.
3) This is the staging area. All the files here are ready to be committed.
4) The diff box is what I like to call this area. It tells you the changes made in the file. + for additions and – for subtractions at the beginning of each line.
5) I’m labeling this area as the git (tool)kit. These buttons are going to be the most used buttons while you use git gui. This is especially true if you submit a lot of patches for your remote repo. “Rescan” looks through the local repo for any changes. “Stage Changed” takes everything that can be staged in section 2 and puts it into the staging section 3. “Sign Off” puts your name in the commit message (you’d have to have this configured already with SSH keys and such). “Commit” takes all the files in the staging section and commits it to your local repo. The “Push” button, of course, pushes to your already linked remote repo.
How do you link your repo to your remote one? Good question. It’s normally generally already linked when you create it. Which brings me to the next topic at hand, how do we create a repo with git gui? The picture below shows the menu to create and deal with branches.
When you click the Branch menu, the drop down brings up the list above. Checkout allows you to switch to other branches linked to your repo (more on this later). Rename, reset and delete are pretty self explanatory. Note: All those commands, only apply to your local repo (until you push to your remote one). Creating a new branch on your local machine is as easy as clicking Branch then create (or Ctrl-N for those ahead of everyone else). Creating a new branch brings up this screen:
When creating a new branch, I generally like to leave everything defaulted. However, there are generally a few options to fiddle with still.
1) You have to name this branch. Totally up to you on what it could be… there are probably limits but I haven’t found the need to be that creative with my naming convention yet.
2) This shows all the branches on your local machine.
3) This shows all the branches you are keeping track of. This is especially useful for those who pull from other people’s remote repositories.
4) The list of the radio button list option above. This is also what you would select your new branch be based on. (Note: General good practice is to update/merge your master and create new branches off your master branch).
If you’re switching branches, you click Checkout on the branch menu and you’d get the screen below.
Look familiar? Probably because it’s very similar to the create screen (minus the naming of the branch). Checkout works an awful lot like creating a branch. You pick which branch you would like to switch to and you have the option of using a local branch or a branch you are tracking (either your remote repo or other people’s remote repo). This brings up the question of “How do you track other people’s repo?” Look at the next screenshot to find out!
Generally, the top 3 sub-menus would only be initially filled with “origin”. Which is to say, your original remote repo. To track more repos, you would have to go to the Add section of the Remote menu. I didn’t provide a screenshot of that menu as it is pretty self explanatory. You provide a name and the git link for the repo you wish to track and voila that repo shows up in the top 3 sub-menus. The main function I tend to use is the “Fetch from specific repo”. This allows me to track the branches of that repo and helps populate the tracking branch section of the create and checkout menus shown above. After fetching a repo, my normal course of action is merging a branch from that repo to the current working branch of my local repo. The merging menu is shown below.
Abort merge removes all the changes you made with the current merging that’s being done. It’s only normally used if you’re in the middle of a merge and made a mistake. Clicking local merge brings up this next screenshot.
Again with the familiarity. It looks similar to the checkout and create menus! Now, this list (under the tracking branch) should be filled. If it’s not, you probably haven’t “fetch from” someone else’s remote repo. If it’s not and you have done that, then your current branch is up to date with everything they have in their branch. You can also merge from other branches in your local repo if you click the local branch radio button option. If you merge quite often, which I do suggest, then you shouldn’t really have any merge problems. If you end up with merge errors (git couldn’t complete the merge for you), it’ll show up in the diff box. You will have to go into the files and fix it manually though. Git makes it easy enough to find those problems by providing you with <<< and >>> notation.
One last piece of information for git gui comes from the Commit drop-down menu shown below.
Some of these options are presented in the buttons below, like Rescan, Sign Off, Commit and Stage Changed. “Stage to Commit” stages only the specific file selected in the Unstaged section. “Unstage from Commit” does the opposite and removes a single file from the staged section and puts it in the unstaged section. “Revert changes” turns back the specified files and returns it to it’s original standing (before any recent uncommitted changes were made to it).
Well, that’s all the basics I think should be out on the web. If you have specific questions, feel free to leave a comment and I’ll try to answer it as best I can. Thanks for reading and I hope it helps!