oofem-wiki

User Tools

Site Tools

Trace:
git-tutorial

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
Last revisionBoth sides next revision
git-tutorial [2012/11/02 11:29] – [Contributing to OOFEM] bpgit-tutorial [2017/11/01 08:56] – updated to github workflow bp
Line 18: Line 18:
    git config --global user.email "your.email@gmail.com"     git config --global user.email "your.email@gmail.com" 
  
-====== Git Basics ======+====== Git Basics - Just for Understanding ======
  
 Our two main branches are: Our two main branches are:
  
     master     master
-    develop+    stable
  
-The master branch is stable and should be in a state that allow a release at any time. The develop branch is used to our development.+The master branch is used to our development, while stable branch should be in a state that allow a release at any time.
  
 ==== Local and remote repositories ==== ==== Local and remote repositories ====
Line 40: Line 40:
 If you want to get a copy of an existing Git repository — for example, a project you’d like to contribute to — the command you need is git clone. If you want to get a copy of an existing Git repository — for example, a project you’d like to contribute to — the command you need is git clone.
  
-   $ git clone http://www.oofem.org/git/oofem.git oofem.git+   $ git clone https://github.com/oofem/oofem.git
  
  
  
 ==== Staging Modified Files ==== ==== Staging Modified Files ====
- If you modify a file and you want to persist this change in the repository you need to perform two steps. First you need to mark them to be relevant for Git. Afterwards you add this change to the Git repository.+If you modify a file and you want to persist this change in the repository you need to perform two steps. First you need to mark them to be relevant for Git. Afterwards you add this change to the Git repository.
  
 Marking changes as relevant for the version control is called staging or to add them to the index. Adding the changes to the repository is called committing.  Marking changes as relevant for the version control is called staging or to add them to the index. Adding the changes to the repository is called committing. 
Line 56: Line 56:
  
     git commit -m "your commit message"       git commit -m "your commit message"  
 +    
 +The commit does not go to a remote server (oofem.org) - this is the major difference with svn.
  
 ==== Viewing Your Staged and Unstaged Changes ==== ==== Viewing Your Staged and Unstaged Changes ====
Line 72: Line 74:
    #    #
  
-==== Committing Your Changes ==== +==== Committing Your Changes to Local Repository==== 
-When the staging area is set up, you can commit your changes. Please note, that anything that is still unstaged — any files you have created or modified won’t go into this commit. They will stay as modified files on your disk. The simplest way to commit is to type git commit:+When the staging area is set up, you can commit your changes to local repository. Please note, that anything that is still unstaged — any files you have created or modified won’t go into this commit. They will stay as modified files on your disk. The simplest way to commit is to type git commit:
  
     $ git commit     $ git commit
Line 83: Line 85:
  
 ==== Viewing the Commit History ==== ==== Viewing the Commit History ====
-You can show the history of commits in the current branch using gil log command+You can show the history of commits in the current branch using git log command
  
     git log     git log
Line 100: Line 102:
  
 To track remote branch, for example the develop branch on origin, use To track remote branch, for example the develop branch on origin, use
-    $ git checkout -b develop origin/develop+    $ git checkout -b stable origin/stable
 If you have Git version 1.6.2 or later, you can also use the --track shorthand: If you have Git version 1.6.2 or later, you can also use the --track shorthand:
-    $ git checkout --track origin/develop+    $ git checkout --track origin/stable
  
 You can switch between branches using git checkout <branchname>.  You can switch between branches using git checkout <branchname>. 
-    $ git checkout develop +    $ git checkout stable 
-If you now call git branch, you will see that a new branch named newfeature has been set up and is the active one:+If you now call git branch, you will see that a new branch named stable has been set up and is the active one:
     $ git branch     $ git branch
       master       master
-    * develop+    * stable
                      
 To synchronize your work, you run  To synchronize your work, you run 
-    $ git fetch origin +    $ git pull origin 
-This command looks up which server origin is, fetches any data from it that you don’t yet have, and updates your local database, moving your origin/master pointer to its new, more up-to-date position. +This command looks up which server origin is, fetches any data from it that you don’t yet have, and updates your local database, moving your origin/master pointer to its new, more up-to-date position. It merges files from remote server with your data. The command ''$ git fetch origin'' only downloads files without merging them.
  
  
-====== Contributing to OOFEM ====== +====== Contributing to OOFEM - Practical workflow ====== 
-Contributing to oofem project is different. Typically, you don’t have the permissions to directly update branches on the project reference repository and you have to pass your contribution(s) to the maintainers in some way. In OOFEM, some people ('lieutenants') are in charge of a specific subsystem of the project and they merge in all changes related to that subsystem and +For people without write permissions to the GitHub oofem repository, the preferred way is to create a pull requests to propose and collaborate on changes in repository. The changes are proposed in a separate branch.
-push to the reference (blessed) repository that everyone then clones from again. In general, lieutenants prefer to accept contributed patches via e-mail.+
  
-**Before contributing, please make sure you have followed [[coding-conventions|oofem coding conventions]].**+You can read more about [[https://help.github.com/articles/creating-a-pull-request/|Creating a pull requests on GitHub help pages]].
  
-First, you’ll probably want to clone the main repository, create a topic branch for the patch or patch series you’re planning to contribute, and do your work there. The sequence looks basically like this:+Typically, one have to create a fork, or copy, of the repository. Forks let you make changes to a project without affecting the original repository. You can fetch updates from or submit changes to the original repository using pull requests. 
 +  * Read more about [[https://help.github.com/articles/working-with-forks/|working with forks on GitHub help]] 
 +  * [[https://help.github.com/articles/creating-a-pull-request-from-a-fork/|How to Create a pull request from a fork]]
  
-  # clone reference repo +If you have write access to the repository, you can also create branch directly within oofem repository. This should be reserved only to agreed, long-term, project-wide branches. For day-to-day and personal development, the forks are recommended. 
-  $ git clone http://www.oofem.org/git/oofem.git oofem.git +  * [[https://help.github.com/articles/creating-and-deleting-branches-within-your-repository/|How to Create and delete branches within your repository]]
-  $ cd oofem.git +
-  # track remote develop branch on reference repo; it will became active one +
-  $ git checkout -b develop origin/develop +
-  # create a new brach for a new development +
-  $ git checkout -b featureA +
-  $ (work) +
-  $ git commit +
-  $ (work) +
-  $ git commit+
  
-:!: **It is stronlgly recommended to use ''rebase -i'' to squash your work down to a single commit, or rearrange the work in the commits to make the patch easier for the maintainer to review — see Git book for more information about interactive rebasing. 
-** 
  
-Now you have your commits that you want to send to the maintainers. You use git format-patch to generate the mbox-formatted files that you can e-mail — it turns each commit into an e-mail message with the first line of the commit message as the subject and the rest of the message plus the patch that the commit introduces as the body. +After you have created a pull request, you can ask a specific person to review the changes you've proposed. 
 +In OOFEM, these people ('lieutenants') are in charge of a specific subsystem of the project and they merge in all changes related to that subsystem and push them to the reference (blessed) repository that everyone can clone from again. 
  
-  $ git format-patch -M origin/master +**Before contributing, please make sure you have followed [[coding-conventions|oofem coding conventions]].**
-  0001-add-limit-to-log-function.patch +
-  0002-changed-log-output-to-30-from-25.patch+
  
-The format-patch command prints out the names of the patch files it creates. The -M switch tells Git to look for renames.  
-To e-mail this to a maintainers, you can either paste the file into your e-mail program or send it via a command-line program.  
  
 ===== Maintainers ===== ===== Maintainers =====
Line 153: Line 142:
  
 ====== Links ====== ====== Links ======
-  * Online version of [[http://git-scm.com/book|Git book]]. Higly recommended! +  * Online version of [[https://help.github.com/|GitHub help]]. Higly recommended! 
-  * Git-SVN [[http://git.or.cz/course/svn.html|Crash Course]] +
  
git-tutorial.txt · Last modified: 2017/11/01 09:08 by bp