User Tools

Site Tools


how_to_work_with_git

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
how_to_work_with_git [2016/06/08 15:59] tsauehow_to_work_with_git [2017/10/02 15:20] (current) tsaue
Line 1: Line 1:
-====== Working with Git (adapted from the Dalton&Dirac wiki) ======+====== Working with Git  ======
  
  
 Git is a program that helps multiple developers work together on a program simultaneously. Every revision to the source code is retained, so if something goes wrong it is always possible to go back to a previous state.  Git is a program that helps multiple developers work together on a program simultaneously. Every revision to the source code is retained, so if something goes wrong it is always possible to go back to a previous state. 
  
-=== Main differences that surprise Subversion users ===+===== Main differences that surprise Subversion users ===== 
 + 
 +You can probably skip this if you have never worked with Subversion or CVS.  
 + 
 +In Subversion you check out a working copy, typically trunk, typically only the last revision (''HEAD''). With Git you clone the full repository, all branches, entire history. But the repository remembers where it came from: the origin, where git pull and git push will refer to. Subversion identifies revisions with IDs of decimal numbers growing monotonically which are typically small. That is impractical in distributed systems like Git. Git identifies revisions with SHA1 IDs, which are long 160-bit numbers written in hexadecimal. It may look scary at first, but in practice it is not a big hurdle - you can refer to the latest revision by ''HEAD'', its parent as ''HEAD^'' and its parent as ''HEAD^^'' = ''HEAD~2''. Cut'n'paste helps a lot and you can write only the few leading digits of a revision as long as it is unique, Git will guess the rest.  
 + 
 +In Git you cannot pull (update) or merge or branch or switch branches with uncommitted modifications. When you get used to the Git way this restriction starts to make a lot of sense. But sometimes you want to pull and do not want to commit, in this case you can ''git stash'' your modifications and "unstash" (''git stash pop'') them after you have updated. ''git commit'' and ''git push'' are not the same thing. You commit locally (''git commit'') and then you publish your changes to origin (''git push'') or not. You can ''git commit'' several times before you ''git push''. A ''svn commit'' corresponds to ''git commit'' with immediate ''git push''.  
 + 
 +Git does not track directories or files, only content. So you cannot ''git add'' and commit an empty directory.  
 + 
 +''git checkout'' is at first sight rather different from ''svn checkout''. You can use ''git checkout'' to switch to another branch or to revert modifications but not to clone the repository. However, the more you use Git the more ''git checkout'' will resemble ''svn checkout''
 + 
 +===== Before you start working with git ===== 
 + 
 +It is highly recommended to set the following for the optimum git experience: Colorize your life!  
 + 
 +   $ git config --global color.branch auto 
 +   $ git config --global color.diff   auto 
 +   $ git config --global color.status auto 
 +    
 +Identify yourself - set your name and your e-mail:  
 + 
 +   $ git config --global user.name "Slim Shady" 
 +   $ git config --global user.email slim.shady@ctcc.no 
 +    
 +Set the default mode for git push (current, matching or tracking):  
 + 
 +   $ git config --global push.default current 
 +    
 +Disable fast-forward merges (read for instance [[http://robey.lag.net/2008/07/13/git-for-the-real-world.html|here]])  
 + 
 +   $ git config branch.master.mergeoptions "--no-f 
 +    
 +===== Recommended reading and viewing ===== 
 +  
 +  * [[http://git-scm.com/course/svn.html|Here]] is a very nice collection of essential commands especially for people coming from the Subversion world:  
 +  * [[http://progit.org/book/|Here]] is probably the best book about Git, and it is online and free 
 +  * [[http://video.linux.com/video/1516|Here]] is a nice webcast - by the author of "Pro Git" - "Git in One Hour" 
 +  * [[http://gitready.com/|Git Ready]] is also very nice 
 +  * A very nice branching model with branching and merging examples is found [[http://nvie.com/posts/a-successful-git-branching-model/|here]]  
 +  * And finally a [[http://cheat.errtheblog.com/s/git|cheat sheet]] 
 +  * The following man pages can be useful as well (especially when you are not online):  
 + 
 +   $ man gittutorial 
 +   $ man gittutorial-2 
 +   $ man gitcore-tutorial 
 +   $ man gitworkflows 
 +   $ man gitglossary 
 +    
 +===== Basic work ===== 
 + 
 +You can live a fulfilled life with the following few Git commands:  
 +  * Clone the repository (checkout a working copy in Subversion speak):  
 + 
 +   $ git clone git@gitlab.com:project_name.git 
 + 
 +  * Update your repository with changes from origin (svn update): 
 + 
 +   $ git pull 
 + 
 +  * Browse the history: 
 + 
 +   $ git log --topo-order --decorate [--oneline --graph] 
 + 
 +  * Add a file: 
 + 
 +   $ git add 
 + 
 +  * Move or rename: 
 + 
 +   $ git mv 
 + 
 +  * Remove: 
 + 
 +   $ git rm 
 + 
 +  * See which files are modified since last commit: 
 + 
 +   $ git status 
 + 
 +  * Browse the history and see which files have been modified: 
 + 
 +   $ git log --stat 
 + 
 +  * See your modifications: 
 + 
 +   $ git diff 
 + 
 +  * Commit all uncommitted modifications: 
 + 
 +   $ git commit -a 
 + 
 +  * Commit a specific file: 
 + 
 +   $ git commit  
 + 
 +  * Publish your changes to upstream (svn commit): 
 + 
 +   $ git push 
  
-You can probably skip this if you have never worked with Subversion or CVS. In Subversion you check out a working copy, typically trunk, typically only the last revision (HEAD). With Git you clone the full repository, all branches, entire history. But the repository remembers where it came from: the origin, where git pull and git push will refer to. Subversion identifies revisions with IDs of decimal numbers growing monotonically which are typically small. That is impractical in distributed systems like Git. Git identifies revisions with SHA1 IDs, which are long 160-bit numbers written in hexadecimal. It may look scary at first, but in practice it is not a big hurdle - you can refer to the latest revision by HEAD, its parent as HEAD^ and its parent as HEAD^^ = HEAD~2. Cut'n'paste helps a lot and you can write only the few leading digits of a revision as long as it is unique, Git will guess the rest. In Git you cannot pull (update) or merge or branch or switch branches with uncommitted modifications. When you get used to the Git way this restriction starts to make a lot of sense. But sometimes you want to pull and do not want to commit, in this case you can @git stash@ your modifications and "unstash" (@git stash pop@) them after you have updated. @git commit@ and @git push@ are not the same thing. You commit locally (@git commit@) and then you publish your changes to origin (@git push@) or not. You can @git commit@ several times before you @git push@. A @svn commit@ corresponds to @git commit@ with immediate @git push@. Git does not track directories or files, only content. So you cannot @git add@ and commit an empty directory. @git checkout@ is at first sight rather different from @svn checkout@. You can use @git checkout@ to switch to another branch or to revert modifications but not to clone the repository. However, the more you use Git the more @git checkout@ will resemble @svn checkout@. 
how_to_work_with_git.1465394372.txt.gz · Last modified: 2016/06/08 15:59 by tsaue

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki