Showing posts with label Git. Show all posts
Showing posts with label Git. Show all posts

Sunday, 25 November 2012

TortoiseSVN vs TortoiseGit Introduction

This post is a comparison between TortoiseGit and TortoiseSVN. In an earlier post, we have explained what a trunk, branch and tags are, together with other related concepts. An introduction to Git concepts is available here, it is a prerequisite for this post.

Creating/Cloning A Repository

Assuming you have both TortoiseGit and TortoiseSVN installed on your PC, you can create or clone repositories to your local PC directories. Select a directory and right-click it with your mouse:


  • TortoiseGit allows you to clone an existing repository locally, or to create one from scratch.
  • For TortoiseSVN, you need to open the sub-menu to create a local repository.
  • The equivalent of Git cloning is somehow a checkout in SVN.
  • With Git, a working directory is a fully fledged Git repository (related to the original repository if it was cloned). Cloned repositories can be cloned themselves. You can create chains of repositories.
  • When using a SVN checkout, the working directory is not a SVN repository. It is only a local checkout of the corresponding repository content. One cannot perform a checkout on a checkout in SVN.
  • The export function in TortoiseSVN is about obtaining a copy of files in a repository, but without the meta-data required to record changes made to this content. In other word, this will not be a working directory from a SVN perspective. This function is also available in Git once the repository is created or cloned.
  • TortoiseSVN also offers an import function, which is typically used to import the directory structure within the local directory, into the repository. This function is seldom used. People will rather perform a check out, create directories locally, and commit them.
  • At last, TortoiseSVN offers the Repo-Browser functionality which allows one to work on/browse a repository without checking it out. That same functionality is available in TortoiseGit once the repository is created or cloned.

Sync/Update And Commit

If you right-click the Git or SVN working directory, a different set of functionalities are offered:
  • A Git Sync is a Pull and a Push at the same time (we will cover these operations later). In SVN, the corresponding operations would be Update and Commit.
  • A Git Commit registers modifications made to files in the working directory.
  • A SVN Update imports locally all code committed by other developers into the repository since you performed you last check-out or last update. In others words, it makes your local directory in sync with the repository. This method is also available in Git as Update To Revision once the repository is created or cloned.
  • A SVN Commit is the operation pushing your local directory modifications back to the repository.

Additional Commands

About commands in common:
  • Show Log - Displays the list of commits performed on the directory. 
  • Check For Modifications - Shows the list of file modifications together with files which have not been added for versioning/revision in the repository.
  • Resolve(d) - Sometimes, code conflicts between (remote) repository or branches and the local (working) directory need to be decided and resolved. It can be a matter of giving preference to the local or remote code. This functionality helps resolve this.
  • Revert - If you don't like the uncommitted modifications you have made so far to your files, you can retrieve the original version in the repository. Think at this functionality as a rubber.
  • Clean Up - If something happened while a command was performed, the system may be left in an unstable or unclean status. This command help clearing the mess.
  • Rename - Helps renaming a file or folder in the local directory. One should not use the typical windows explorer rename function, because Git and SVN would not be notified and it would be impossible for them to maintain continuity between files.
  • Delete - Removes a files or a directory in the local directory. Just like for renaming, one
    should not use the typical windows explorer delete function, because Git and SVN would not be notified and it would be impossible for them to maintain continuity.
  • Switch - Assuming you are working on trunk (SVN) or master (Git), or a branch, this method helps you shift between these back and forth, rather than checking them out in another local directory.
  • Merge -  This allows one to merge the modifications made in a branch back to trunk/master (or any other source branch it was created from).
  • Create Branch/Tag - Simply allows the creation of branches and tags.
  • Settings - Enables configuration of TortoiseGit and TortoiseSVN.
  • Add - Tells Git and SVN to take files into consideration for the next commit. In Git, this is called staging.
  • Create Patch (Serial) - This method is about creating patch from modifications made in the local directory.
  • Apply Patch (Serial) - This functionality is about applying patches to the  local directory.
  • Help - Provides documentation about TortoiseGit and TortoiseSVN.
  • About - Provides information about TortoiseGit and TortoiseSVN.
About TortoiseSVN specific commands:
  • Revision Graph - Displays a graph of branches and tags in the repository.
  • Get/Release Lock - Allows one to lock some files in the repository, to make sure no other engineer modifies them while one is working on it locally.
  • Relocate - If the repository has changed of location, this functionality has local checkout point to that new location.
About TortoiseGit specific commands:
  • Fetch - This functionality retrieves modifications from a remote source back to the local repository, but does not merge them.
  • Pull - This is a fetch with merging.
  • Push - This function pushes current modification to a remote repository.
  • Diff (With Previous Version) - Displays staged differences made in the working directory.
  • Rebase - A complex function allowing to move modifications made to a branch back to master (or any other branches), without keeping a continuity trace in the logs.
  • Stash Save - Saves current work made in the local directory without committing it into the repository.
  • Bisect Start - Helps finding a revision that caused an issue and move the HEAD pointer accordingly if necessary.
  • Submodule Add - Adds another Git project/repository in this repository, while keeping commits separated.

Saturday, 24 November 2012

Introduction To Git Concepts

This post is an introduction/reminder to Git concepts. It aims at facilitating the learning curve for those coming from a Subversion (or other) background. For more details, there is nothing like the official book.

Concepts

  • Git operates on repositories which contain a local database of files and corresponding file revisions.
  • Repositories contain files which can have 3 states:
    • Committed - The file is stored in the database.
    • Modified - The file has been modified, but has not been stored in the database.
    • Staged - The file has been  modified and flagged as to be committed in the database.
  • A file can also be considered as untracked by Git. It has no status, until it is added to the working directory. The add function can be used to stage a file.
  • When cloning or creating a Git repository to a local directory, this directory will contain:
    • A Git directory containing the local database and all meta information corresponding to the repository.
    • A staging area file containing information about what will be included in the next commit.
    • The remaining content is called the working directory, which contains files (extracted from the database) corresponding to a specific version of modifications stored in the database.
  • Typically, files are modified in the working directory, then staged for commit, then committed into the repository database.
  • It is possible to ignore files in a repository by marking them as such in the working directory. They will not be stored in the local database.
  • It is possible to remove files from the Git repository, or to move them around in the working directory.

  • When cloning a repository locally, its origin (i.e., the original repository) is registered in the local repository as a remote repository. Several remote repositories can be attached (added) and detached (deleted from) to your local Git repository.
  • One can fetch all data from a remote repository (including branches). This operation will not merge this data with your local work though.
  • One can also pull all data from a remote repository, which is like a fetch and automatic merging.
  • Pushing your repository content to a remote repository is like a pull, but the other way round. All modifications transmitted and merged on the remote repository.

  • One can create tags (of content at a specific version). Eventually, this tag can be annotated with information, such as tag creator, email, etc... It is possible to sign tags too (in a cryptographic way). Signed tags can be verified.

  • One can create branches too. Technically speaking, these are pointers to a specific version in the database repository. The default branch is called Master.
  • In order to remember which branch you are working on, Git has a specific pointer called HEAD.
  • One can use the Git checkout command to switch back and forth between branches. This will update the content of the working directory accordingly.
  • Modifications made to files in different branches are recorded separately.
  • Once a branch has reached a stable level, it can be merged back to Master (or any other branch it came from). Then, it can be deleted.
  • Eventually, a branch can be closed and deleted without merging modified content. This content is lost forever.
  • Branches can evolve independently. If so, a merge operation will first find a common ancestor and create a new version in the Master (or any other target branch). This version will contain both the modifications of the target and merging branches.
  • It is possible to work with remote branches from remote repositories too.
  • Rebasing is about merging the content of a branch back to Master (for example). When there is only one branch, it is not different than a simple merge, except that the log history will not contain the entries (versions) of the rebased branch anymore. This functionality is mostly useful when there are multiple branches created from multiple branches in a Git repository. You may want to merge a branch while keeping alive others having common ancestors.
  • Be careful with rebasing, because if other people were working on that branch (i.e., it is public) or any sub-branches, the continuous integration continuity will be broken for them.

  • Fast Forwarding is the process of moving a branch pointer forward. For example, a branch A is created from Master. Work is performed on A and merged back to Master. The Master pointer may lag behind to an earlier version not containing the merged changes. It can be fast forwarded to the version containing those merged changes.
  • Stashing is the practice of saving unfinished work aside without committing it yet. This allows one to switch branches without committing work in progress.
  • Submodules is a mean to import another Git project into your Git project, but with keeping the commits separated. This is useful when that other project is about developing a library which will be used in several Git projects.