Getting Started - Git

Version Control

We use git as our version control software of choice. Pretty much everyone does now-a-days. Here is the Reference Manual. Familiarize yourselves with basic git usage. A set of common commands is listed below. Try git out on your own stuff for practice! It can be used for code development or other things like versioning your thesis / dissertation.

Common Git Commands Used

• git clone
• git fetch
• git checkout
• git push
• git pull
• git rebase
• git merge
• git log
• git remote -v

Hierarchy

• Git is used as version control for all shared code
• We follow the Fork / Pull Request Paradigm. In the example, replace all master with pass#.
• This is the same workflow use for hcana contributions
• The replay repo is no longer a fork of hallc_replay. We need to watch that repo closely for changes.
• Dave is in charge of accepting pull requests into the JeffersonLab/hallc_replay_XEM repo.
• All XEM group members will 'Fork' Jefferson Lab's hallc_replay_XEM repository. The fork will appear on your GitHub account, that is your 'origin'.
  • JeffersonLab/hallc_replay_XEM is your 'upstream' repo. This area is common to all XEM2 users.
  • Changes can be made on a 'local' repo and then pushed to your 'origin'. All changes should fall under a specific pass#. Make sure you rebase your 'local' and 'origin' often to have the most up-to-date repo.
  • Once you have pushed your changes to your 'origin' under a new_feature_branch based on pass# branch, you can make a pull request to JeffersonLab/hallc_replay_XEM to add your changes into our 'upstream' pass# branch.
• Communications about new features / calibrations / etc will be sent via the hallc_replay_XEM Slack channel. Please watch the main repo (JeffersonLab/hallc_replay_XEM). This will notify you when collaborator have accepted pull requests and you should merge the changes into your pass# branch.

Remember: The point of this scheme is for us to Collaborate! We can independently work on different calibrations / scripts / etc and bring all of our changes together to spread out the workload.

Setting SSH for GitHub at JLab

1. Generate ssh key if you do not have one.
   1. ssh-keygen (when prompted for file in which to save the key and pass phrase, just hit return )
2. Put ssh public key on Github
   1. Open "Settings" from the pull down menu in the top right.
   2. Go to "SSH and GPG keys"
   3. Click on "new ssh key" button. At terminal type "more ~/.ssh/id_rsa.pub". Copy the code and paste into github.
   • Note: The ssh key may not work right away. If this happens, just log off from the iFarm machine and wait a few minutes for the key to start working. You may be unable to login to the iFarm for a few minutes, this is OK. Once you are able to login to the iFarm again the ssh key should be working, so you should be able to start cloning remote repositories.

Used before, complicated

Lets say Casey added a branch to hallc_replay_XEM that you'd like to use. We want to put that on our origin, but the fetch upstream button on github does not add the new branch to your origin. To do this we must: First ensure you are tracking the remote upstream: git remote -v Lists all names of remote repositories and the path to them git remote add upstream git@github.com/mrcmor100/hallc_replay_XEM.git Now that we told our local where upstream is, we can track the new branch in our local: git checkout upstream_branch_name You could alternatively name this whatever you'd like (don't) git pull upstream upstream_branch_name Pulls from upstream to local git push origin local_branch_name local_branch_name should match upstream_branch_name! Great, now you have the upstream branch on your origin. Thing to check If Casey updates upstream_branch_name, will there be a fetch upstream option for that branch? Lets say we want to stop tracking old branches that no longer exist: git remote prune origin That'll do it for ya'!

Reset Repo (go back a commit)

http://www.inanzzz.com/index.php/post/zaqd/revert-last-commit-but-keep-all-the-changes-to-the-files-with-git-reset-soft-head

Working With Git Submodules

I found this to be a very good resource that covers git submodules with simple examples.

https://git-scm.com/book/en/v2/Git-Tools-Submodules