Intelligent and Interactive Systems

User Tools

Site Tools


collab:git

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

collab:git [2015/11/24 17:14]
c703101
collab:git [2018/09/03 19:35]
Line 1: Line 1:
-====== Git ====== ​ 
-<​code>​ 
-  Update (15/​03/​2012):​ Port 2222 is depricated. All services run additionally on Port 22 
-  Update (13/​03/​2012):​ More than 5 wrong authentications yield into a 10 minute ip-address ban 
-</​code>​ 
-Git is an extremely powerful and flexible revision control system, and using it effectively requires adherence to conventions. 
- 
-===== IIS Repository Policy ===== 
- 
-  * A distinct tree / a repository - is maintained for each independent (software, paper, ...) project. 
-  * For each repository, the mainline (master) tree is hosted on the IIS server. 
-  * Contributors develop locally and maintain their own trees, and push (or request to pull) only generally-useful,​ tried-and-proven patch sets into the main tree. 
-  * Where appropriate,​ multiple external developers can exchange patches among each others before committing to the mainline. 
-  * Branches are used to maintain multiple releases simultaneously while developing new features in the trunk. As long as we will not generally have formal releases, there will be little or no need for branches. 
- 
- 
-Please adhere to basic guidelines for [[git-usage]]. 
-===== Basic Workflow ===== 
- 
- 
-{{ :​collab:​git-usage.png?​300|git std. usage}} 
- 
-Retrieve an %%IIS%% Git tree for you to work on: 
- 
-  git clone ssh://​iis.uibk.ac.at/​projects/​git/​PROJECTNAME 
-  ​ 
-''​PROJECTNAME''​ will typically include a path portion. 
- 
-Prepend the hostname with ''​USERNAME@''​ if your Git username does not match your local username. 
- 
-Now make your edits. ​ To see the status of your files with respect to your repository, do: 
- 
-  git status 
- 
-For each reasonable unit of changes, tell Git that you want to keep it, and then commit it to your local tree: 
- 
-  git add FILENAME 
-  git commit -m "brief documentation of your changes"​ 
- 
-Each self-contained,​ fully-functional set of changes that you want to make public should be pushed upstream to the %%IIS%% master tree: 
- 
-  git push 
- 
-At this point you are free to delete your local Git tree. 
- 
-In the meantime, you can retrieve updates from the %%IIS%% master tree with: 
- 
-  git pull 
- 
-For more information,​ see the [[http://​gitref.org/​|Git Reference]] and [[http://​www.kernel.org/​pub/​software/​scm/​git/​docs/​everyday.html|Everyday Git]]. 
- 
-A ''​git pull''​ will automatically merge any edits other people have pushed in the meantime. ​ However, this will fail if such edits happened in the same section of a file as the changes you are trying to push.  In this case, ''​git pull''​ will signal a merge conflict, which needs to be resolved by hand. 
- 
-[[http://​www.rosipov.com/​blog/​use-vimdiff-as-git-mergetool/​|Here]] you may find a nice tutorial on how you can do merging by using vimdiff (you should be able to use vim for using it). 
- 
- 
-==== Creating a New Git Project ==== 
- 
-To create your personal Git repository for your own, local use only: 
- 
-  cd PROJECTROOT 
-  git init --shared 
-  git add . 
-  git commit -m "​initial import"​ 
- 
-To create a Git repository on the IIS server: 
- 
-  - Decide on a name and a place for the repository under ''/​projects/​git/''​. It should live inside the appropriate subdirectory (''​papers/'',​ ''​projects/'',​ etc.), and should follow the repository naming conventions. For example, repositories holding published papers should be named by [[:​intranet:​public:​papers#​publication_ids|Publication ID]]. Use ''/​projects/​git/​personal/''​ only for material that is not and will not be useful to the lab. 
-  - [[intranet:​systems:​docs:​git-ssh#​creating_a_shared_git_repository|Initialize]] your new repository on the lab server. 
-  - Inside the newly-created repository directory on the server, edit the ''​description''​ file. This is diplayed e.g. [[:​intranet:​git-repos|here]]. 
-  - [[#​basic_workflow|Clone and populate]] your new repository. 
- 
- 
-===== Understanding Git ===== 
- 
-[[http://​eagain.net/​articles/​git-for-computer-scientists/​|Here]] is an excellent and brief explanation of Git's internal representation and how it supports user-level interactions. ​ Very useful to understand Git. 
- 
- 
-Two key distinctions from Subversion (SVN) are 
- 
-  * the //staging area// ("​index"​) where you define the changes to be commited. (SVN commits directly from the working directory.) 
-  * the //​distributed//​ nature. Commits are done to the local clone of the repository. Sharing your changes requires explicit action, e.g., ''​git push''​. (SVN commits directly to a central repository.) 
- 
- 
-===== More Advanced Hints ===== 
- 
-==== Git Revisions ==== 
- 
-The following diagram is an example '​commit'​ view of a master tree (w.o. branches). 
-it describes the difference between revert and reset. 
- 
-{{ :​collab:​git_revisions_without_branches.png?​400|git revisions wo branches}} 
- 
-  ​ 
-==== Moving or Renaming a Git Repository ==== 
- 
-A Git repository does not know its own name or location; it is simply identified by its location in the filesystem. ​ It can be moved or renamed ad libitum. 
- 
-To keep any cloned copies in sync, you have essentially two options: 
- 
-  * Commit and push everything before the move, delete the clone, move the repo on the server, and create a fresh clone. 
- 
-  * Point an existing clone to the updated location: From the root directory of the cloned tree, issue <​html><​pre class="​code">​git remote set-url origin ssh://​iis.uibk.ac.at/​projects/​git/​SUBDIR/​REPONAME</​pre></​html>​ See [[http://​stackoverflow.com/​a/​2432799|here]] and ''​man git-remote''​ for more information. 
- 
-==== Textmode Tool For Git ==== 
-a nice (commandline) tool for viewing commits, logs, diffs and other changes is tig. to install tig on a debian based machine 
-  apt install tig 
-change into the git working directory and start 
-  tig 
- 
-==== Patches ==== 
- 
-Generate Patches and use Peer-to-peer patch exchanges ((example taken from http://​linuxwireless.org/​en/​developers/​Documentation/​git-guide)) 
- 
-  git format-patch --cover-letter -o some-dir d8a285c8f83f728be2d056e6d4b0909972789d51..9202ec15da36ca060722c363575e0e390d85fb71 
-  # this is equivalent to, this is the short form 
-  git format-patch --cover-letter -n -o some-dir d8a28..9202e 
- 
-Where d8a28 was the last commit before you started hacking and 9202e is the current head, meaning the commit ID of your latest commit. ​ 
- 
-For renaming files add "​-M"​ to the git-format-patch arguments then patches wont create removals and adds for a simple rename. 
- 
-Sending Patches: 
-  git send-email --no-chain-reply-to --from "My Name <​my.name@uibk.ac.at>"​ --to recipient@domain some-directory/​ 
- 
- 
-==== Ssh Config ==== 
- 
-You could also create an ssh config file in your home-directory to shorten the git commands: 
-The ~/​.ssh/​config file could look like: 
- 
-<​file>​ 
-Host iis 
-    HostName iis.uibk.ac.at 
-    Port 22 
-    User username 
-    #​IdentityFile ​ ~/​.ssh/​PRIVATEKEYFILE ​ 
-</​file>​ 
- 
-The IdentityFile line is only for ssh key auth necessary. 
- 
-The commands then would look like 
-  git clone ssh://​iis/​projects/​git/​projectname 
- 
-{{tag>​git Usage}} 
- 
  
collab/git.txt · Last modified: 2018/09/03 19:35 (external edit)