Intro to Git Getting started with Version Control Murray Anderegg February 9, 2018
What is Version Control? * It provides one method for an entire team to use; everybody operates under the same 'ground rules'. * Changes are orderly vs. chaotic, saving development time * The ability to track changes promotes accountability and makes it easier to find the right person to solve problems in the materials maintained. https://web.archive.org/web/20111202083911/http://www.fortnet.org/fortnet/html/presentation/cvs/whyvc.html
What is Version Control? * A list of exact changes made can be generated quickly and easily, making it easier to advise users of the information on how it has changed from version to version. * It is easy to 'roll back' to an earlier version of the information, if a serious mistake was made during a change. https://web.archive.org/web/20111202083911/http://www.fortnet.org/fortnet/html/presentation/cvs/whyvc.html
Why you need Version Control A younger programmer asked an elder about his code and his coding style, and how the older programmer would do certain things. The older programmer said 'Let's take a look at your code', so the younger took out his laptop, opened his editor, and showed him. https://web.archive.org/web/20111104021923/http://stackoverflow.com/questions/132520/good-excuses-not-to-use -version-control/135002
Why you need Version Control The older programmer looked at the code, thought about it for a bit, and then started editing it. He deleted the class internals, leaving only the structure, and then rearranged the structure, saying 'Here's how I would do it to make it more efficient and readable'. After he was done, he saved the file and gave it back to the younger programmer, who was ashen-faced. https://web.archive.org/web/20111104021923/http://stackoverflow.com/questions/132520/good-excuses-not-to-use -version-control/135002
Why you need Version Control 'That... My code is gone!' said the younger programmer. 'But you have it in version control somewhere, right?' asked the elder. 'N... no.' was the reply. 'Well then,' said the older, 'now you've learned two lessons.' https://web.archive.org/web/20111104021923/http://stackoverflow.com/questions/132520/good-excuses-not-to-use -version-control/135002
Two main types of Version Control Centralized and Distributed
Centralized Version Control Subversion and CVS are examples of centralized version control systems.
Distributed Version Control Git, Mercurial and Bazaar are examples of distributed version control systems.
Getting started with git git config --list --global git config --edit --global These are configurable per project as well.
My global git config user.email=anderegg@cs.unc.edu user.name=murray Anderegg color.ui=auto color.diff.frag=magenta bold color.diff.old=red bold color.diff.new=green bold core.pager=less -R core.editor=/home/anderegg/bin/vim-front.sh alias.co=checkout alias.pall=push --all
Getting started with the git tool(s) After setting up global preferences you need to start working with a repository. Two ways of starting with a repository: - Start a new project locally - Clone an existing project
Getting started with git (locally) mkdir -vp ~/projects ; cd ~/projects mkdir -vp new-project ; cd new-project git init.
Getting started with git (locally) build_new_proj () { local name= $1 ; [ -d ~/projects/ ${name} /. -o -d ${name} /. ] && echo Error: Project ${name} already exists && return 1 case ${name} in */*) mkdir -v ${name} && cd ${name} && git init. ; ;; *) mkdir -v ~/projects/ ${name} && cd ~/projects/ ${name} && git init. ; ;; esac; # Start editing vim; }
Getting started with git (cloning) mkdir -vp ~/projects git clone git@git.cs.unc.edu:<repository> E.g. git clone git@git.cs.unc.edu:anderegg/git-intro-sandbox.git
Getting help with git You are going to need help with git sometime. git help, git help <command> man git-<command> git help add = man git-add https://git-scm.com/book/en/v2
Git repository and staging Git allows you to stage or cache files for a commit. This gives you three levels of the repository: - Current working copy (the current change) - The staged or cached version (this is what you already plan to commit) - The committed repository Remember this throughout your time working with git.
The Current Change Commands are: add, mv (rename), reset, rm add - Adds the requested file(s) to the staged content of the repository mv - This is equivalent to the Linux mv command. This renames a file and its history. reset - Resets the current change (working copy) to whichever level is requested. Consider archiving your project before running this. rm - Removes the requested file(s) and stages the removal for the next commit.
Commit and diff commit - commit all currently staged changes to the committed repository. diff - regular Unix diff with enhancements for working with the levels of the repository. git diff, git diff --cached, git diff --color=always, git diff --color=never...
Basic use of git with a local repository Initialize or clone a repository. Make changes. Test your changes. Add or stage the changes. Check the changes you ve made. Commit your changes with meaningful messages. Try not to contaminate repositories with broken changes.
You re ready to start You should be able to create a local repository, edit some files, stage those files for a commit, commit them with a message, make more changes, diff your changes, more commits, etc.
Backups: local and otherwise Backups are important. Make them. Check them. Have at least one available, preferably two (or three).
Rsync and walking along the abyss Rsync is a great tool. Get comfortable creating a side-by-side backup of your project with rsync before you do something you won t be able to undo. This is the abyss. cd ~/project mkdir <project>.pre-abyss cd <project> rsync -xavhs --progress.../<project>.pre-abyss
Branches Git encourages use of sandbox areas for new ideas with lightweight creation, merging and removal of branches. This allows you to create a fork (branch) in the road at your current commit point and try out new ideas, which can then be folded (merged) back into the production code. - git branch, git branch -a, git branch --remote, git branch -d/-d [ --remote ] - git help branch
Git and the bash prompt Consider having your bash prompt provide you information about any git repository, into which you have cd. Use intuitive visual cues. /usr/lib/git-core/git-sh-prompt - on Ubuntu systems this provides a set of shell functions for manipulating prompts. PROMPT_COMMAND is run once before displaying each command prompt. git_ps1 - Shell function for manipulating your prompt (PS1)
Merges At some point you will need to integrate changes that you or other people make in the repository. This is called merging. The further you wander from the fork, the more there is to merge. Good news! Git generally does well with merges and will merge non-conflicting changes automatically. When working with your own repositories, most merging will be automatic.
Department git repository server The department has a git server, git.cs.unc.edu, managed with gitolite. Access is via openssh-compatible key pairs. Users request a new repository by sending email to help@cs.unc.edu. Send the public part of your ssh key pair the first time you request a repository. I suggest multiple small repositories, one per class or project, in order to make collaboration easier.
Setting up ssh for remote repositories You will need to manage your git ssh key(s) for your remote repositories. I recommend one (1) key to access all of your git repositories. You need to load this key into an ssh-agent, so that git can use it to access the repositories via ssh. Bash users are welcome to look at the code in ~anderegg/dot-files/dot-agent. This prepares an ssh-agent for use, and ensures that the agent is killed off when your shell exits. Use ssh-add to add/remove your ssh key to/from the running ssh-agent.
git and an ssh-agent You will need to be able to easily add an openssh-compatible ssh private key to a running ssh-agent. Git obtains this key from the ssh-agent to work with the remote repository using private/public key pair access. You will probably need to use the key + ssh-agent to work with a remote repository, especially within the department.
Manage an ssh-agent (with bash) if [ -t 1 ]; then if [ -n "${SSH_AUTH_SOCK}" ]; then true; else eval $(ssh-agent) &> /dev/null; trap "echo killing ssh-agent ${SSH_AGENT_PID}; kill ${SSH_AGENT_PID}" 0; fi; fi; # <check for your key in the agent; if necessary, add it>
Ssh keys and AFS Beware of AFS directories when setting up ssh keys. AFS has its own access control lists and ignores UNIX file permissions. One way to solve this is to place your private ssh key in ~/.ssh/private and restrict the AFS ACLs. Clear permissions by using permission none: /usr/bin/fs listacl ~/.ssh/private /usr/bin/fs setacl ~/.ssh/private <user or group> none /bin/ln -sv private/<my key>.rsa ~/.ssh/<my key>.rsa
Clone, fetch, pull and push git clone - clone a full copy of the committed repository into a directory with the same name in the current directory. You can also specify a new name for the repository. git fetch - fetch all updates from the remote repository git pull - pull any changes to the current branch from the remote repository and automatically merge them git push - send all merged changes back up to the remote repository.
Version Control, Workflow, Social framework Version Control facilitates software development with granularity of changes and good documentation (commit messages). How does your group operate and interact? How does your group manage prototype, development and production (released versions)? Does your Version Control reflect how your group operates?
Where to from here? (INR) - Version Control should be a part of your daily life from here on out. - Repositories are easy to setup and use here in the department. - Create many small repositories. They are easier to manage. - Be considerate. Binaries and object files change and use a lot of space. Setup good defaults for your project to ignore (git help ignore). - Integrate Version Control into the start of every project. Consider placing your dot files such as.bash_profile,.bashrc, etc into git. Then, you can locally clone your dot files and use the latest committed (=tested) version.
Get things done (The Done Manifesto) Look at and perhaps print the Done Manifesto. It may get you out of school having learned more and better prepared when you go elsewhere. https://medium.com/@bre/the-cult-of-done-manifesto-724ca1c2ff13
Problem Solving Skills Get better at doing things a variety of different ways https://ryanstutorials.net/problem-solving-skills/ If at first you don t succeed, try a different way
Ask Better Questions How To Ask Questions The Smart Way http://catb.org/~esr/faqs/smart-questions.html Can you solve the question on your own first? Are you reinventing the wheel? Everyone was once a beginner.
Do you have the grit to succeed? What kind of person are you? http://angeladuckworth.com/grit-scale/
More grit! (Star Wars Chapter 4, A New Hope) Gold Leader: They're coming in! Three marks at 2-10! [Gold Two is slain by Darth Vader and his wingmen; Gold Leader starts to panic] Gold Leader: It's no good, I can't maneuver! Gold Five: Stay on target. Gold Leader: We're too close! Gold Five: Stay on target! Gold Leader: [shouts] Loosen up! [he too is picked off by Vader and Company; Gold Five tries to escape but is fatally winged] Gold Five: Gold Five to Red leader, lost Tiree, lost Dutch. Red Leader: I copy, Gold Leader. Gold Five: They came from... behind!