This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
collab:git [2011/03/26 13:20] c7031007@ZID1.UIBK.AC.AT |
collab:git [2018/09/03 19:35] (current) |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== Git ====== | ====== Git ====== | ||
- | Git is an extremely powerful and flexible revision control system, and using it effectively requires adherence to conventions. | ||
- | ===== Usage Policy ===== | + | Git is an extremely powerful and flexible revision control system, and using it effectively requires adherence to conventions. |
- | Here is a proposal; comments and adjustments are welcome. | + | ===== IIS Repository Policy ===== |
* A distinct tree / a repository - is maintained for each independent (software, paper, ...) project. | * A distinct tree / a repository - is maintained for each independent (software, paper, ...) project. | ||
- | * For each project, the mainline (master) tree is hosted here at the iis uibk servers. | + | * For each repository, the mainline (master) tree is hosted on the git.uibk.ac.at 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. | * 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. | * 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. | * 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. | ||
- | ===== Obtaining a Git Project ===== | ||
- | ==== Creating a New Git Project ==== | + | Please adhere to basic guidelines for [[git-usage]]. |
+ | ===== Basic Workflow ===== | ||
- | cd PROJECT-ROOT | ||
- | git init --shared | ||
- | git add . | ||
- | git commit -m "initial import" | ||
- | Then, ask the sysadmin to put your tree onto the lab server. | + | {{ :collab:git-usage.png?300|git std. usage}} |
- | If your tree will not be accessed by anybody else, there is no need to talk to the sysadmin or to specifiy ''--shared''. | + | Retrieve an %%IIS%% Git tree for you to work on: |
- | ==== Retrieving an Existing Git Project ==== | + | git clone https://git.uibk.ac.at/iis-XXXX/PROJECTNAME |
- | To get the source code initially use ''git clone'': | + | |
+ | ''PROJECTNAME'' will typically include a path portion. | ||
- | git clone ssh://iis.uibk.ac.at:2222/projects/git/PROJEKTNAME LOCALREPO | + | Prepend the hostname with ''USERNAME@'' if your Git username does not match your local username. |
- | e.g. | + | Now make your edits. To see the status of your files with respect to your repository, do: |
- | git clone ssh://iis.uibk.ac.at:2222/projects/git/FeatureHierarchies | + | |
+ | git status | ||
- | ===== Standard Usage ===== | + | For each reasonable unit of changes, tell Git that you want to keep it, and then commit it to your local tree: |
- | **Develop locally, within your own trees, and push (or request to pull) only generally-useful, tried-and-proven patch sets | + | git add FILENAME |
- | into the main tree.** | + | git commit -m "brief documentation of your changes" |
- | ==== Example usage ==== | + | Each self-contained, fully-functional set of changes that you want to make public should be pushed upstream to the %%IIS%% master tree: |
- | for local commits use just something like | + | git push |
- | git commit -a -m "Commit Message" | + | 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). | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ===== 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}} | ||
+ | |||
+ | | ||
+ | |||
+ | ==== 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)) | Generate Patches and use Peer-to-peer patch exchanges ((example taken from http://linuxwireless.org/en/developers/Documentation/git-guide)) | ||
Line 60: | Line 98: | ||
- | ===== For Releases ===== | + | ==== ssh Config ==== |
- | push the local commits to the server (master tree) - as mentioned above only generally-useful, tried-and-proven code. | + | You could also create an ssh config file in your home-directory to shorten the git commands: |
+ | The ~/.ssh/config file could look like: | ||
- | git push origin master | + | <file> |
+ | Host iis | ||
+ | HostName iis.uibk.ac.at | ||
+ | Port 22 | ||
+ | User username | ||
+ | #IdentityFile ~/.ssh/PRIVATEKEYFILE | ||
+ | </file> | ||
- | to get updates from the server | + | The IdentityFile line is only for ssh key auth necessary. |
- | git pull origin master | + | The commands then would look like |
- | | + | git clone ssh://iis/projects/git/projectname |
- | + | ||
- | ===== References ===== | + | {{tag>git Usage}} |
- | howto think like git: | + | |
- | http://gitref.org/ | + | |
- | this may also be a good starting point: | ||
- | http://www.kernel.org/pub/software/scm/git/docs/everyday.html | ||