0024336: Content of OCCT documentation should be updated. Iter 2
[occt.git] / dox / dev_guides / git_guide / git_guide.md
1 Guide to installing and using Git for OCCT development {#dev_guides_git_guide}
2 =================================
3
4 @tableofcontents 
5
6 @section occt_gitguide_1 Overview
7
8 @subsection occt_gitguide_1_1 Purpose
9
10   The purpose of this document is to provide a practical introduction to Git 
11   to OCCT developers who are not familiar with this tool 
12   and to facilitate the use of the official OCCT Git repository for code contribution to OCCT.
13
14   Reading this document does not exempt from the need to learn Git concepts and tools. 
15   Please consult a book or manual describing Git to get acquainted with this tool. 
16   Many good books on Git can be found at http://git-scm.com/documentation 
17   
18   For the experienced Git users it can be enough to read sections 1 and 3
19    of this document to start working with the repository.
20    
21   Please make sure to get familiar with the Contribution Workflow document 
22   that describes how Git is used for processing contributions to OCCT.
23   
24   This and related documents are available at the Resources page 
25   of the OCCT development portal at http://dev.opencascade.org/index.php?q=home/resources. 
26
27 @subsection occt_gitguide_1_2 Git URL
28
29   URL of the official OCCT source code Git repository (accessed by SSH protocol) is:
30   
31    gitolite@git.dev.opencascade.org:occt
32   
33   or 
34   
35    ssh://gitolite@git.opencascade.org/occt.git
36
37 @subsection occt_gitguide_1_3 Content
38
39 The official repository contains:
40
41   * The current certified version of OCCT: the "master" branch. This branch is updated by the Bugmaster only. Official OCCT releases are marked by tags.
42   * Topic branches created by contributors to submit changes for review / testing or for collaborative development.    The topic branches should be named by the pattern "CR12345" where 12345    is the ID of the relevant issue registered in Mantis (without leading zeroes),    and "CR" stands for "Change Request". The name can have an additional postfix used if more than    one branch was created for the same issue.
43   * Occasionally topic branches with non-standard names can be created by the Bugmaster for special needs.
44
45 @subsection occt_gitguide_1_4 Short rules of use
46
47   The name specified in the user.name field in Git configuration should correspond 
48   to your login name on the OCCT development portal. 
49   This is important to clearly identify the authorship of commits. 
50   (The full real name can be used as well; in this case add the login username in parentheses.)
51   
52   By default, contributors are allowed to push branches only with the names starting with CR 
53   (followed by the relevant Mantis issue ID). 
54   Possibility to work with other branches can be enabled by the Bugmaster on request.
55   
56   The branch is created by the developer in his local repository when the development of a contribution starts. 
57   The branch for new developments is to be created from the current master. 
58   The branch for integration of patches or developments based on an obsolete version 
59   is created from a relevant tag or commit. The branch should be pushed to the official repo 
60   only when sharing with other people (for collaborative work or review / testing) is needed. 
61   
62   Rebasing the local branch to the current master is encouraged before the first submission 
63   to the official repository. If rebasing was needed after the branch is pushed to the official repo, 
64   the rebased branch should have a different name (use suffix).
65   
66   Integration of contributions that have passed certification testing is made exclusively by the Bugmaster. 
67   Normally this is made by rebasing the contribution branch on the current master 
68   and squashing it into a single commit. This is made to have the master branch history plain and clean, 
69   following the general rule “one issue – one commit”. 
70   The description of the commit integrated to the master branch is taken from the Mantis issue 
71   (ID, 'Summary', followed by the information from 'Documentation' field if present).
72   
73   In special cases when it is important to save the  commits history in the branch 
74   (e.g. in case of  a long-term development integration) it can be integrated by merge (no fast-forward).
75   
76   The authorship of the contribution is respected by preserving the Author field of the commit when integrating.
77   Branches are removed from the official repository when integrated to the master. 
78   The Bugmaster can also remove branches which have no commits during one-month period.
79   
80   The Bugmaster may ask the developer (normally the one who produced the contribution) 
81   to rebase a branch on the current master, in the case if merge conflicts appear during integration.
82
83 @subsection occt_gitguide_1_5 Version of Git
84
85   The repository is tested to work with Git 1.7.6 to 1.7.9. 
86   Please do not use versions below 1.7.1 as they are known to cause troubles.
87
88 @section occt_gitguide_2 Installing Tools for Work with Git
89
90 @subsection occt_gitguide_2_1 Windows platform
91
92   Installation of Git for Windows (provided by MSysGit project) is required. 
93   
94   In addition, it is recommended to install TortoiseGit to work with Git on Windows. 
95   If you do not install TortoiseGit or any other GUI tool, 
96   you can use GitGui and Gitk GUI tools delivered with Git and available on all platforms.
97
98 @subsubsection occt_gitguide_2_1_1 Installation of Git for Windows
99
100   Download Git for Windows distributive from http://code.google.com/p/msysgit/downloads/list.
101   During the installation:
102
103   * Select Windows Explorer integration options:
104     * Git Bash Here
105     * Git GUI Here
106     
107 @image html OCCT_GitGuide_V2_image001.png
108 @image latex OCCT_GitGuide_V2_image001.png
109
110   * To avoid a mess in your PATH, we recommend selecting ‘Run Git from Windows Prompt’ in the environment settings dialog: 
111   
112 @image html OCCT_GitGuide_V2_image002.png
113 @image latex OCCT_GitGuide_V2_image002.png
114
115   * In "Configuring the line ending conversions" dialog, select "Checkout Windows-style, commit Unix style endings".
116   
117 @image html OCCT_GitGuide_V2_image003.png
118 @image latex OCCT_GitGuide_V2_image003.png
119  
120   Note that by default Git user interface is localized to the system default language. 
121   If you prefer to work with the English interface, remove or rename .msg localization file 
122   in subdirectories *share/git-gui/lib/msgs* and *share/gitk/lib/msgs* of the Git installation directory.
123   
124   Before the first commit to the OCCT repository, make sure that your User Name in the Git configuration file (file *.gitconfig* in the $HOME directory) is equal to your username on the OCCT development portal. 
125
126 @subsubsection occt_gitguide_2_1_2 Installation and configuration of TortoiseGit
127
128   Download TortoiseGit distributive from http://code.google.com/p/tortoisegit/downloads/list. 
129   Launch the installation.
130
131   * Select your SSH client. Choose OpenSSH if you prefer to use command-line tools 
132    for SSH keys generation, or TortoisePLink if you prefer to use GUI tool (PuttyGen, see 3.2):
133    
134 @image html OCCT_GitGuide_V2_image004.png
135 @image latex OCCT_GitGuide_V2_image004.png
136
137   * Complete the installation.
138   
139 @image html OCCT_GitGuide_V2_image005.png
140 @image latex OCCT_GitGuide_V2_image005.png
141   
142   TortoiseGit integrates to Windows Explorer, thus it is possible to use popup menu in Windows Explorer to access its functionality:
143  
144   Note that if you have installed MSysGit or have Git installed in non-default path, 
145   on the first time you use TortoiseGit you may get the message demanding to define path to Git. 
146   In such case, click on **Set MSysGit path** button and add the path to git.exe 
147   and path to MigGW libraries in the Settings dialog.
148
149   * After the installation  select Start -> Programs -> TortoiseGit Settings to configure TortoiseGit.
150   
151   Select Git->Config to add your user name and Email address to the local .gitconfig file
152   
153   @image html OCCT_GitGuide_V2_image006.png
154   @image latex OCCT_GitGuide_V2_image006.png
155
156 @subsection occt_gitguide_2_2 Linux platform
157
158   We assume that Linux users have Git already installed and available in the PATH.
159   
160   Make sure to configure Git so that the user name is equal to your username 
161   on the OCCT development portal, and set SafeCrLf option to true:
162
163 ~~~~~
164     > git config --global user.name "Your User Name"
165     > git config --global user.email your@mail.address
166     > git config --global your@mail.address
167 ~~~~~
168
169 @section occt_gitguide_3 Getting access to the repository
170
171 @subsection occt_gitguide_3_1 Prerequisites
172
173   Access to the repository is granted to the users who have signed the Contributor License Agreement.
174   
175   The repository is accessed by SSH protocol, thus you need to register your public SSH key 
176   on the development portal to get access to the repository.
177   
178   SSH keys are used for secure authentication of the user when accessing the Git server. 
179   Private key is the one stored on the user workstation (optionally encrypted). 
180   Open (or public) key is stored in the user account page on the web site. 
181   When Git client accesses the remote repository through SSH, 
182   it uses this key pair to identify the user and acquire relevant access rights.
183   
184   Normally when you have Git installed, you should have also SSH client available. 
185   On Unix/Linux it is installed by default in the system. 
186   On Windows it is typical to have several SSH clients installed; 
187   in particular they are included with Cygwin, Git, TortoiseGit.
188   
189   It is highly recommended to use the tools that come 
190   with the chosen Git client for generation of SSH keys. 
191   Using incompatible tools (e.g. ssh-keygen.exe from Cygwin for code generation, 
192   and TortoiseGit GUI with a default Putty client for connection to server) 
193   may lead to authentication problems.
194
195 @subsection occt_gitguide_3_2 How to generate a key
196
197 @subsubsection occt_gitguide_3_2_1 Generating key with Putty
198
199   Use this option if you have installed TortoiseGit (or other GUI Git client on Windows) 
200   and have chosen “TortoisePLink” (or other Putty client) as SSH client during installation.
201   
202   To generate the key with this client, run Puttygen (e.g. from Start menu -> TortoiseGit -> Puttygen), 
203   then click Generate and move mouse cursor over the blank area until the key is generated. 
204   
205 @image html OCCT_GitGuide_V2_image007.png "Putty key generator"
206 @image latex OCCT_GitGuide_V2_image007.png "Putty key generator"
207
208   After the key is generated, you will see GUI controls to define the public key comment 
209   and / or specify the password for the private key protection. 
210   When done, save both the public and the private key to the files of your choice 
211   (make sure to store your private key in a secure place!).
212   
213   Copy the public key as shown by Puttygen to the clipboard to add it in your account. 
214   Do not copy the Putty public key file content -- it is formatted in a way not suitable for the web site.
215
216 @subsubsection occt_gitguide_3_2_2 Generating key with command-line tools
217
218   Use this option if you work on Linux or if you have chosen “OpenSSH” as SSH client 
219   during installation of TortoiseGit (or other Windows tool).
220   
221   Make sure that you have *ssh* and *ssh-keygen* commands in the path. 
222   On Windows, you might need to start 'Git Bash' command prompt window provided by Git for Windows.
223   
224   Use the following command to generate SSH keys:
225 ~~~~~  
226     > ssh-keygen -t rsa -C "your@mail.address"
227 ~~~~~  
228
229   The last argument is an optional comment, which can be included with the public key and used to distinguish between different keys (if you have many).  The common practice is to put here your mail address or workstation name.
230   
231   The command will ask you where to store the keys. It is recommended to accept the default path *$HOME/.ssh/id_rsa*. Just press Enter for that. You will be warned if a key is already present in the specified file; you can either overwrite it by the new one, or stop generation and use the old key.
232     
233   If you want to be on the safe side, enter password to encrypt the private key. You will be asked to enter this password each time you use that key (e.g. access a remote Git repository), unless you use the tool that caches the key (like TortoiseGit). If you do not want to bother, enter an empty string.  
234   
235   On Windows, make sure to note the complete path to the generated files (the location of your $HOME might be not obvious). Two key files will be created in the specified location (by default in $HOME/.ssh/):
236   
237   * *id_rsa* - private key
238   * id_rsa.pub - public key
239   
240   The content of the public key file (one text line) is the key to be added to the user account on the site (see below).
241
242 @subsubsection occt_gitguide_3_2_3 Generating key with Git GUI
243
244   GitGUI (standard GUI interface included with Git) provides the option 
245   to either generate the SSH key (if not present yet) or show the existing one. 
246   Click Help/Show SSH key and copy the public key content for adding to the user account page (see below).
247
248 @subsection occt_gitguide_3_3 Adding public key in your account
249
250   Log in on the portal http://dev.opencascade.org and click on 'My account' link to the right. 
251   If you have a Contributor status, you will see 'SSH keys' tab to the right. 
252   Click on that tab, then click 'Add a public key', and paste the text of the public key 
253   (see above sections on how to generate the key) into the text box. 
254   Click "Save" to input the key to the system. 
255   
256   Note that a user can have several SSH keys. 
257   You can distinguish between these keys by the Title field ID; by default it is taken from SSH key comment. 
258   It is typical to use your e-mail address or workstation name for this field; no restrictions are set by the portal.
259   
260 @image html OCCT_GitGuide_V2_image008.png
261 @image latex OCCT_GitGuide_V2_image008.png
262
263   Please note that some time (5-10 min) is needed for the system 
264   to update the configuration after the new key is added. 
265   After that time, you can try accessing Git.
266
267 @section occt_gitguide_4 WORK WITH REPOSITORY: DEVELOPER OPERATIONS
268
269 @subsection occt_gitguide_4_1 General workflow
270
271   To start working with OCCT source repository, you need to create its clone in your local system. 
272   This cloned repository will manage your working copy of the sources 
273   and provide you the means to exchange code between your clone and the origin. 
274   
275   In most cases it is sufficient to have one clone of the repository; 
276   your working copy will be updated automatically by Git when you switch branches.
277   
278   The typical development cycle for an issue is as follows:
279
280   * Create a new branch for your development, basing on the selected version of the sources 
281    (usually the current master) and switch your working copy to it
282   * Develop and test your change. Note that for the first time, and after any changes 
283    made in CDL files you will have to re-generate build scripts or Visual Studio projects using WOK. 
284   * Do as many commits in your branch as you feel convenient; 
285    the general recommendation is to commit every stable state (even incomplete), to record the history of your development.
286   * Push your branch to the repository when your development is complete or when you need to share it with other people (e.g. for review)
287   * Before the first push, rebase your local branch on the latest master; 
288    consider collapsing the history in one commit unless you think the history of your commits is interesting for others. 
289    Make sure to provide a good commit message.
290   * Do not amend the commits that have been already pushed in the remote repository, 
291    If you need to rebase your branch, commit the rebased branch under a different name, and remove the old branch.
292   
293   You can switch to another branch at any moment 
294   (unless you have some uncommitted changes in the working copy) 
295   and return back to the branch when necessary (e.g. to take into account review remarks). 
296   Note that only the sources that are different between the switched branches will be modified, 
297   thus required recompilation should be reasonably small in most cases.
298
299 @subsection occt_gitguide_4_2 Cloning official repository
300
301   Clone the official OCCT repository in one of following ways:
302
303   * From command line by command: 
304
305 ~~~~~  
306     > git clone gitolite@git.dev.opencascade.org:occt <path>
307 ~~~~~
308
309   where <i><path></i> is the path to the new folder which will be created for the repository.
310     
311   * In TortoiseGit: right-click in the Explorer window, then choose "Git Clone":
312  
313 @image html OCCT_GitGuide_V2_image009.png
314 @image latex OCCT_GitGuide_V2_image009.png
315
316   If you have chosen Putty as SSH client during TortoiseGit installation, check the “Load Putty Key” option and specify the location of the private key file saved by PuttyGen (see 3.2.1). This shall be done for the first time only.   
317   
318   Note that on the first connection to the repository server you may be requested to enter a password for your private SSH key; further you can get a message that the authenticity of the host cannot be established and will be asked if you want to continue connecting or not:
319
320 @image html OCCT_GitGuide_V2_image010.png
321 @image latex OCCT_GitGuide_V2_image010.png
322
323   Choose “Yes” to continue. Then the host’s key will be stored in $HOME/.ssh/known_hosts file.
324
325 @subsection occt_gitguide_4_3 Branch creation
326
327   You need to create a branch when you are going to start development of a new change, 
328   apply a patch, etc. It is recommended to fetch updates from the remote repository 
329   before this operation, to make sure you work with the up-to-date version.
330   
331   Create a branch from the current master branch unless you need to base your development on a particular version or revision. 
332
333 In the console:
334
335 ~~~~~
336     > git checkout -b CR12345 origin/master
337 ~~~~~
338   
339 In TortoiseGit: 
340   * Go to the local copy of the repository. 
341   * Right-click in the Explorer window, then choose "Git Create Branch".
342   
343 @image html OCCT_GitGuide_V2_image011.png
344 @image latex OCCT_GitGuide_V2_image011.png
345
346   * Select “Base On” Branch remotes/origin/master 
347
348 @image html OCCT_GitGuide_V2_image012.png
349 @image latex OCCT_GitGuide_V2_image012.png
350
351   Check option ‘Switch to new branch’ if you are going to start working with the newly created branch immediately.
352
353 @subsection occt_gitguide_4_4 Branch switching
354
355   If you need to switch to another branch, use Git command checkout for that.
356   In the console:
357
358 ~~~~~
359     > git checkout CR12345
360 ~~~~~
361   
362   In TortoiseGit: right-click, TortoiseGit -> Checkout/switch
363  
364 @image html OCCT_GitGuide_V2_image013.png
365 @image latex OCCT_GitGuide_V2_image013.png
366
367   Note that in order to work with the branch locally you need to set option 
368   “Create new branch” when you checkout the branch from the remote repository for the first time. 
369   Option “Track” stores association between the local branch and the original branch in a remote repository.
370
371 @subsection occt_gitguide_4_5 Committing branch changes
372
373   Commit your changes locally as soon as a stable status of the work is reached. 
374   Make sure to review carefully the committed changes beforehand to avoid unintentional commit of a wrong code. 
375   
376   * In the console:
377   
378 ~~~~~
379     > git diff
380     …
381     > git commit -a -m "Write meaningful commit message here"
382 ~~~~~
383
384   Option –a tells the command to automatically include (stage) files 
385   that have been modified or deleted, but it will omit the new files that might have been added by you. 
386   To commit such new files, you must add (stage) them before commit command.
387
388   To find new unstaged files and them to commit, use commands:
389
390 ~~~~~
391     > git status -s
392       ?? file1.hxx 
393       ?? file2.cxx
394     > git add file1.hxx file2.cxx
395 ~~~~~
396
397   * In TortoiseGit: right-click, choose “Git Commit -> CR…”:
398  
399 @image html OCCT_GitGuide_V2_image014.png
400 @image latex OCCT_GitGuide_V2_image014.png
401
402   Unstaged files will be shown if you check the option ‘Show Unversioned Files’. 
403   Double-clock on each modified file to see the changes to be committed (as a difference vs. the base version). 
404
405 @subsection occt_gitguide_4_6 Pushing branch to the remote repository
406
407   When the code developed in your local branch is ready for review, 
408   or you need to share it with others, push your local changes to the remote repository.
409   
410   * In the console:
411
412 ~~~~~  
413     > git push "origin" CR12345:CR12345
414 ~~~~~
415
416   * In TortoiseGit: right-click, TortoiseGit -> Push
417
418 @image html OCCT_GitGuide_V2_image015.png
419 @image latex OCCT_GitGuide_V2_image015.png
420
421 Note that Git will forbid pushing a branch if the corresponding remote branch already exists and has some changes, which are not in the history of your local branch. This may happen in different situations:
422   * You have amended the last commit which is already in the remote repository. 
423    If you are sure that nobody else uses your branch, push again with ‘force’ option. 
424   * You have rebased your branch, so that now it is completely different 
425    from the branch in the remote repository. In this case, push it under a different name (add a suffix): 
426  
427 @image html OCCT_GitGuide_V2_image016.png
428 @image latex OCCT_GitGuide_V2_image016.png
429
430   Then remove the original remote branch so that other people recognize that it has been replaced by the new one. For that, select TortoiseGit -> Push again, then select an empty line for your local branch name, 
431   and enter the name of the branch to be removed in ‘Remote’ field:
432
433 @image html OCCT_GitGuide_V2_image017.png
434 @image latex OCCT_GitGuide_V2_image017.png
435
436   * The other developer has committed some changes in the remote branch. 
437    In this case, pull changes from the remote repository to have them merged 
438    with your version, and push your branch after it is successfully merged.
439
440 @subsection occt_gitguide_4_7 Synchronizing with remote repository
441
442   Maintain your repository synchronized with the remote one and clean unnecessary stuff regularly.
443   Use Git command fetch with option prune to get update of all branches 
444   from the remote repository and to clean your local repository from the remote branches that have been deleted.
445   
446   * In the console:
447
448 ~~~~~  
449     > git fetch --prune 
450 ~~~~~
451     
452   * In TortoiseGit:
453   
454 @image html OCCT_GitGuide_V2_image018.png
455 @image latex OCCT_GitGuide_V2_image018.png
456
457   If some changes have been made to the branch you are working with in the remote repository, 
458   use Git command pull to get the remote changes and merge them with your local branch. 
459   This operation is required in particular to update your local master branch when the remote master changes.
460   
461   * In console:
462 ~~~~~  
463     > git pull
464 ~~~~~    
465   * In TortoiseGit:
466
467 @image html OCCT_GitGuide_V2_image019.png
468 @image latex OCCT_GitGuide_V2_image019.png
469
470   Note that the local branches of your repository are the primary place 
471   where your changes are stored until they get integrated to the official version 
472   of OCCT (master branch). The branches submitted to official repository 
473   are for collaborative work, review, and integration; 
474   that repository should not be used for long-term storage of incomplete changes. 
475   
476 Remove the local branches that you do not need any more. Note that you cannot delete the current branch, thus you need to switch to another one (e.g. master) if the branch you are going to delete is the current one.
477   
478   * In the console:
479 ~~~~~ 
480     > git branch -d CR12345
481 ~~~~~
482     
483   * In TortoiseGit: right-click, select TortoiseGit -> Show log
484
485 @image html OCCT_GitGuide_V2_image020.png
486 @image latex OCCT_GitGuide_V2_image020.png
487
488   Select “All branches” to view all branches.
489   Right-click on the branch you want to delete and select Delete… menu item corresponding to this branch. 
490  
491   Note that the log view in TortoiseGit is a convenient tool 
492   to visualize and manage branches; it provides short-cuts to many functions described above.
493
494 @subsection occt_gitguide_4_8 Applying a fix made on older version of OCCT
495
496   If you have a fix made on a previous version of OCCT, 
497   perform the following sequence of operations to prepare it 
498   for testing and integration to the current development version.
499
500   * Identify the version of OCCT on which the fix has been made. 
501    In most cases, this will be an OCCT release, e.g. OCCT 6.7.0.; 
502    then just find a tag or a commit corresponding to this version in the Git history log of the master branch.
503   * Create a branch basing on this tag or commit. In TortoiseGit history log: right-click on the base commit, then select **Create branch at this version**.
504   
505 @image html OCCT_GitGuide_V2_image021.png
506 @image latex OCCT_GitGuide_V2_image021.png
507
508   Check option **Switch to the new branch** to start working within the new branch immediately, or switch to it separately afterwards.
509
510   * Put your fix in the working copy, build and check that it works, then commit to the branch.
511   * Rebase the branch on the current master.
512   
513   In TortoiseGit: right-click on the working directory, 
514   then choose TortoiseGit->Rebase; then select *remotes/origin/master* as UpStream revision, and click **Start**:
515  
516 @image html OCCT_GitGuide_V2_image022.png
517 @image latex OCCT_GitGuide_V2_image022.png
518
519   Note that you can get some conflicts during rebase. 
520   To resolve the conflicts double-click on each conflicted file 
521   (highlighted by red in the file list) to open visual merge tool. 
522   Switch between conflicting fragments by red arrows, and for each one 
523   decide if the code of one or both conflicting versions is to be taken. 
524   Use the toolbar.
525
526 @subsection occt_gitguide_4_9 Rebasing with history clean-up
527
528   At some moments you might need to rebase your branch on the latest version of the master. 
529   
530   We recommend rebasing before the first submission of the branch 
531   for review or when the master has diverged substantially from your branch. 
532   
533   Rebasing is a good occasion to clean-up the history of commits in the branch. 
534   Consider collapsing (squashing, in terms of Git) the history of your branch 
535   into a single commit unless you deem that having separate commits is important 
536   for your future work with the branch or its code reviewing. 
537   Git also allows you to change the order of commits, edit commit contents and messages, etc. 
538   
539   Here is the sequence of actions to rebase your branch into a single commit:
540   
541   * Switch to your branch (e.g. “CR12345”)
542   * In TortoiseGit history log, select a branch to rebase on (usually remotes/origin/master) 
543    and in the context menu choose **Rebase “CR12345” onto this**.
544   * In the Rebase dialog, check **Squash All**.
545
546 @image html OCCT_GitGuide_V2_image023.png
547 @image latex OCCT_GitGuide_V2_image023.png
548
549   **Note** that you can also change the order of commits and define for each commit 
550   whether it should be kept (“pick”), edited, or just skipped.
551   
552   * Click **Start**.
553   * The process will stop if a conflict is detected. 
554    In such case, find files with status ‘Conflicted’ in the list (marked by red), 
555    and double-click on them to resolve the conflict. 
556    When all conflicts are resolved, click ‘Continue’.
557    
558 @image html OCCT_GitGuide_V2_image024.png
559 @image latex OCCT_GitGuide_V2_image024.png
560  
561   * At the end of the process, edit the final commit message (it should start from the issue ID and  a description from Mantis in the first line, followed by a summary of actual changes), and click **Commit**.
562    
563 @image html OCCT_GitGuide_V2_image025.png
564 @image latex OCCT_GitGuide_V2_image025.png
565
566 @section occt_gitguide_5 Work with repository: Reviewer operations
567
568 @subsection occt_gitguide_5_1 Review branch changes using GitWeb
569
570   The changes made in the branch can be reviewed without direct access to Git, using GitWeb interface:
571
572   * Open GitWeb in your web browser: http://git.dev.opencascade.org/gitweb/?p=occt.git 
573   * Locate the branch you want to review among heads (click ‘…’ at the bottom of the page to see the full list).
574   * Click log (or shortlog) to see the history of the branch. 
575     
576   **Note** that the branch can contain more than one commit, and you need to distinguish commits 
577   that belong to that branch (those to be reviewed) from the commits 
578   corresponding to the previous state of the master branch. 
579   Normally the first commit in the list that starts from the ID 
580   of the other issue indicates the branching point; 
581   commits above it are the ones to be reviewed.
582   
583   * Click *commitdiff* on each log entry to review the changes (highlighted with color format).
584
585 @subsection occt_gitguide_5_2 Review branch changes with TortoiseGit 
586
587   Use of TortoiseGit is recommended for convenient code review:
588
589   * Fetch the changes from the remote repository as described in 4.7;
590   * Right-click on the repository, choose TortoiseGit -> Show log;
591   * Locate the remote branch you need to review;
592   * To review commits one-by-one, select each commit in the log. 
593    The list of changed files is shown at the bottom of the window; 
594    double-click on the file will open visual compare tool.
595   * To review all changes made in the branch at once, or to compare 
596    two arbitrary revisions, select the corresponding commits in the log 
597    (e.g. the last commit in the branch and the branching point), 
598    right-click for the context menu, and choose **Compare revisions**.
599
600 @image html OCCT_GitGuide_V2_image026.png
601 @image latex OCCT_GitGuide_V2_image026.png
602