Jump to content

QESTNET Internal:Developer Git etiquette

From QESTonline

Initial Setup

  1. Signup for a GitHub account www.github.com. Tell someone your username so they can add you to the appropriate SpectraQEST team
  2. Download and install Git from http://git-scm.com/download. Windows has two possible ways to run git: choose msysgit instead of Cygwin. When installing, choose all the options that they recommend for Windows development. Install again to something like “C:\Program Files (x86)\Git”.
  • You will be prompted about line ending conversions at some point. Use the auto-convert option, I think it’s the first option. It should produce the line “autocrlf = true” in the default config: “C:\Program Files (x86)\Git\etc\gitconfig”.
  1. You can now:
  • Run the Git console using Git Bash, a shortcut (quotes included): "C:\Program Files (x86)\Git\bin\sh.exe" --login –i
  • Run Git GUI using this entire command (quotes included) in a shortcut: "C:\Program Files (x86)\Git\bin\wish.exe" "C:\Program Files (x86)\Git\libexec\git-core\git-gui"
  • A shortcut for both of these should have been created in the Start Menu automatically.
  1. Your global Git configuration file “.gitconfig” is found under “C:\Users\Your.Name\.gitconfig”. Setup your username and email by using the following commands in Git Bash:
  • git config --global user.name “Your name”
  • git config --global user.email your.name@spectraqest.com
  1. Download and install KDiff3 (this will be used as the merge tool for changes that can’t be automatically merged. Can maybe make it work with WinMerge, but haven’t tried.) This can be installed to the default location, something like “C:\Program Files (x86)\KDiff3”.
  2. Setup Git to use KDiff3 and optionally Notepad++ as your editor instead of Vim by editing the global .gitconfig file. I find it easier to edit manually in Notepad++ than using the console. Here’s an example of a config file:

[core] editor = "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -nosession -noPlugin" autocrlf = true [user] name = John Meegan email = john.meegan@spectraqest.com [merge] 

   tool = kdiff3

[mergetool "kdiff3"] 

   path = c:/Program Files (x86)/KDiff3/kdiff3.exe

[diff] 

   tool = kdiff3

[difftool "kdiff3"] 

   path = c:/Program Files (x86)/KDiff3/kdiff3.exe
  1. Set up your public key: http://github.com/guides/providing-your-ssh-key . Note that the ~ directory in Git Bash corresponds to “C:\Users\Your.Name\”, so your SSH public key can be found in “C:\users\Your.Name\.ssh\id_rsa.pub” after you’ve generated it.
  • By this point you will have a GitHub account and password, a private and public SSH key, and a password to access your private SSH key. This last password is just in case someone steals your computer, they cannot access your private key without a password. This prevents them from accessing anything you use your key for, such as GitHub, once you have added your public SSH key to GitHub.
  1. Make the folder “C:\dev\” on your C Drive for development work.
  2. Get a Git repository from GitHub via something like the following (note the URL comes from GitHub and changes depending on the project):
  • cd /c/dev/
  • git clone git@github.com:spectraqest/qestnet.upgrade.git
  1. That’s pretty much it. There are plenty of tools you can try out to assist with using Git if you wish. Two of the most popular are:


Starting on a new bug/change request

  1. Checkout the development branch (e.g. alien) that the bug/change request will be added to.
  2. Pull or fetch from github the latest of the branch and ensure that your local copy is at the head.
  3. Create a new branch using the bug/cr and some form of descriptor as the name (e.g. cr4321-tv-map or bug1234-tv-map-ucs).
  4. Make regular commits to this branch as you are developing.
  5. Once initial development is complete rebase the bug/cr branch to a single commit.
  6. The bug/cr branch can now be pushed to github for testing.
  7. The tester will fetch and checkout the cr/bug branch to test it and give feedback.
  8. At this point make any required changes on the branch. Commit and push to github so that the tester can re-test.
  9. Once all development is complete, checkout the development branch again. Pull or fetch from github the latest of the branch and ensure that your local copy is at the head.
  10. Merge the bug/cr branch into the development branch, resolving any conflicts.
  11. The development branch can now be pushed to github for integration testing.
  12. Minor fixes required from integration testing can be made directly on the development branch. Any major problems development can revert back to the bug/cr branch.
  13. Once integration testing is complete or if it is not required the bug/cr branch can be deleted locally and on github.
Retrieved from "http://online.spectraqest.com/index.php?title=QESTNET_Internal:Developer_Git_etiquette&oldid=28968"