
So, I built a [React app](https://github.com/vraa/gitflowanimated) to visualize and animate the Gitflow. Basically, in Gitflow,

1. There's a `master` branch.
2. You create a `develop` branch off of `master`. This `develop` branch is your bread and butter as most of your changes go in here.
3. `feature` and `release` branches are created off of `develop`.
4. Once you are done with `feature`, you merge it to `develop`.
5. Once you are done with `release`, you merge it to both `develop` and `master`. And you tag the release.
6. If there's a issue in production, you create a `hotfix` branch off of `master`.
7. Once `hotfix` is done, you merge it back to `master` and `develop` and tag the release.

## Animate the Gitflow

Source: [https://github.com/vraa/gitflowanimated](https://github.com/vraa/gitflowanimated)

Click on the buttons below / next to each branch to simulate the action and see the commits flowing.

<iframe className={"gitflow"} src="https://veerasundar.com/gitflowanimated/"/>


Gitflow - Animated


About 7 years ago I wrote about [my Git Workflow](https://veerasundar.com/blog/git-tutorial-my-git-work-flow/). I just happened to read that article now and realised "Hey, that's not how I use Git anymore!?". Of course, when I wrote that post, I was just getting started with Git. But now, the post is so outdated that only the "90s kids remember it anymore"! 🤣

Anyway, Long story short: I decided write again about my Git workflow.

Let's start:

## 1. Cloning / Creating a Git repo

```text
$ git clone git@github.com:vraa/blog.git
$ cd blog
```

![Cloning a git repo](https://i.imgur.com/9VKXisd.png)

The first step is to get a local Git repo going. If I am starting a new project myself, I just needed to do `git init` on my project directory. But at work, it is usually cloning my team's existing repo.

## 2. Making changes and branching

```text
$ git checkout -b vraa-master-feature origin/master
```

![Creating branches in Git](https://i.imgur.com/OsCa0dA.png)

Before I start working on my local repo, I always create a separate branch for my work. Branches are cheap in Git. So, I create as many branches as I need.

I follow this naming convention: `[my-short-name]-[parent-branch-name]-[bug/feature-id]`. This convention helps me in quickly identifying / distinguishing my branch or my pull request from the sea of pull requests.

## 3. Pulling in changes

```shell
$ git pull --rebase
```

![Git rebase](https://i.imgur.com/ZMcnyQ1.png)

Often, even before my changes are committed / pushed, the remote repository is always getting updated with other changes.  So, it is vital to bring in those changes as soon as possible, to avoid creating merge conflicts later.

> Note: if my local changes are not yet pushed, then I tend to use `rebase` option instead of a merge. This helps me to keep my branch history clean. But, use it with caution if you have pushed your branch to a remote repo, as `rebase` rewrites commit history, you will end up with a nightmarish merge conflicts.

## 4. Stashing my local changes

```shell
$ git stash
$ git pull
$ git stash pop
```

![Stashing changes in Git](https://i.imgur.com/pjdoOyu.png)

Sometimes, when I try to pull remote changes and it overwrite my local changes, git won't let me to pull. If I am in middle of the work and not yet ready to commit the changes, I stash my local changes, so that I can safely pull in the remote changes.

After applying the stashed files, if there are any merge conflicts, then I will have to deal with it.

## 5. Reordering and squashing my commits

```text
$ git rebase -i 8e35004e04f352b20eda0eb0a4d46574d8fba216
// re order and combine multiple commits into single one
```

![Squashing multiple commits](https://i.imgur.com/CQYWReL.png)

During development, I usually commit as many times as possible. This helps me to go back in history if something breaks. But this also introduces lots of mid work / partial commits. I usually clean my working history by squashing multiple commits into a single commit.

Be aware that this rewrites history. So, never do this if you have already pushed your changes to remote and other people have got your changes.

## 6. Pushing my changes

```text
$ git push origin
```

![Push changes](https://i.imgur.com/TaCjP4Z.png)

And finally it's time to deliver my changes and break the build.. wait.. no... just deliver the changes. Once my changes are delivered and merged, I usually remove the branch locally and remotely. This helps to keep the branch count at check.
```


My Git Workflow


At work, I use [PowerShell] (http://en.wikipedia.org/wiki/Windows_PowerShell) a lot, mostly for Git commands. By default, the powershell prompt message shows you the full path of the current working directory. i.e. something like this;

    PS C:\vraa\workspace

Which is fine, but I'd like this prompt to be short and informative. In short, I'd want the prompt to:

- Show only the folder name, instead of full path.
- Show the current branch name if inside a Git repo.

Powershell provides an option to customize its behavior. You can write your customization, in terms of functions, and keep them in your $PROFILE file. So, in order to achive my requirement, I used following function.

1.  In Powershell, type `notepad.exe $PROFILE`.
2.  Add following function there.

```shell
function prompt{
  $p = Split-Path (
     Get-Location
     ) -Leaf
  
  git branch | foreach{
    if($_ -match "^\*(.*)"){
     $p += " [" + $matches[1] + " ] "
    }
  }
  
  $p = $p + ">"
  Write-Host $p -NoNewline -ForegroundColor Green
  return " "
}
```

Be sure to keep the function name as `prompt`. Save and restart Powershell.

After the above customization, when you are in a normal folder, Powershell prompt will look like this:

    foldername>

And, when inside a Git repo, the prompt message will look like:

    gitrepo [ master ] >

Thanks to [this] (http://techblogging.wordpress.com/2008/10/12/displaying-git-branch-on-your-powershell-prompt/) for the script to detect current Git branch name.

So, what is your [Powershell customization] (https://veerasundar.com/blog/using-multiple-versions-of-jdk-and-eclipse-in-single-machine/)?


This post explain how you can customize Powershell prompt to show the current Git branch name.

Customize Powershell Prompt Message


Lets say that you have pushed your code live and now want to code for a new feature. And, suddenly a bug found in your live code (it happens! a LOT!) which needs an immediate fix from you. Now, you have two different coding tasks in your hand.

1.  Code for your feature - which you can not commit in your main code base, because of some partial work.
2.  At the same time, you can not fix the bug in the main code base and push it to live because of the partial code which could break the builds (and hearts of some tech support guys!).

So, what will you do? **Branch! **Lets create two different branches - one for feature and one for bug-fixes and you can happily code on your branches without fearing that it might break the main code base.\*\*  
\*\*

## Git Branch:

![git branching][1]

[1]: https://veerasundar.com/img/2011/06/git-branch.jpg "git-branch"

Branching is something that every developer often do. When you branch, Git is taking a copy of your main code base and saving it in a different name (imagine the _File -> Save as_). So, the changes you do in your branched code will not affect your main code.

Having said that, lets see how to create new branches in Git. I'm opening my [_helloworld_][2] project again with the clean working directory.

[2]: https://veerasundar.com/blog/git-tutorial-my-git-work-flow "My Git Workflow"

    ~/work/projects/helloworld$ git status
    # On branch master
    nothing to commit (working directory clean)

So, now I'm on the *master *branch which is the **default **branch in Git. I want to create a new feature to add line of text 'Hello India' to my file. For that, lets create a branch _india_.

    ~/work/projects/helloworld$ git branch india
    ~/work/projects/helloworld$ git branch
      india
    * master

There we go! In the first line, I ask Git to _create_ a new branch by giving a branch name _india_. In the second, I ask Git to *list *all the available branches which lists *india *and the default branch _master_. The \* marks denotes the branch you are currently in.

Now you created a new branch. But you are still in the *master *branch. You have to switch to the newly created branch before making any changes. Lets do that.

    ~/work/projects/helloworld$ git checkout india
    Switched to branch 'india'

Now we switched to the* india *branch. you can make your changes and commit as many times as you wish. This will not affect the *master *branch in any way (until your merge your changes back).\*

- ~/work/projects/helloworld$ gedit helloworld.txt
  ~/work/projects/helloworld$ git add helloworld.txt
  ~/work/projects/helloworld$ git status

  # On branch india

  # Changes to be committed:

  # (use "git reset HEAD ..." to unstage)

  #

  # modified: helloworld.txt

  #

  ~/work/projects/helloworld$ git commit -m "modified in india branch"
  [india 2b2fa49] modified in india branch
  1 files changed, 1 insertions( ), 0 deletions(-)

## Merging changes back to main branch:

![git merge][3]

[3]: https://veerasundar.com/img/2011/06/git-merge.jpg "git-merge"

Now it is time to merge your feature code to the main branch. In a simpler words, we are going to do this: **_master = master india_**!

    ~/work/projects/helloworld$ git checkout master
    Switched to branch 'master'
    ~/work/projects/helloworld$ git merge india
    Updating 8f8c6ba..2b2fa49
    Fast-forward
     helloworld.txt |    1
     1 files changed, 1 insertions( ), 0 deletions(-)

As you can see, to merge, first switch back to *master *branch then give the *merge *command with the branch name you want to merge. That simple! If you open the *helloworld.txt *file, you can see the changes made in the *india *branch. Also, you can give the command *git log helloworld.txt *which will display all the commits you made on this files, including the *india *branch changes too.

Life is not always this simple. When you merge, there's a possibility that conflicts could occur. I'll explain how to resolve these conflicts in my next post.


Git tutorial - branching and merging


Continuing from my last post, which explained [my Git workflow][2], in this post I'm sharing how to compare different versions of files. Before that, you might want to read the [Getting started with Git][3] post too if you haven't done already.

[1]: https://veerasundar.com/img/2011/06/compare-apple-orange-300x255.gif "compare-apple-orange"
[2]: https://veerasundar.com/blog/git-tutorial-my-git-work-flow "Git tutorial - my Git work flow"
[3]: https://veerasundar.com/blog/git-tutorial-getting-started "Git tutorial - Getting Started"

The main objective of version controlling is to enable you to work with different versions of files. Git provides a command **diff** to let you to compare different versions of your files.

The most common scenario to use **diff** is to see what changes you made after your last commit. Let's see how to do it.

I opened the **helloworld** project from [my last example][4] with a clean working directory. i.e. I have already committed all my code changes. So, a git status will give an output like this:

[4]: https://veerasundar.com/blog/git-tutorial-my-git-work-flow "My Git work flow"

```shell

    C:/vraa/projects/helloworld> git status
    # On branch master
    nothing to commit (working directory clean)

```

Let's make a change in the _helloworld.txt_ file now and compare this file with previously committed version.

```shell

    C:/vraa/projects/helloworld> edit helloworld.txt
    C:/vraa/projects/helloworld> git diff HEAD helloworld.txt
    diff --git a/helloworld.txt b/helloworld.txt
    index e4f37c4..557db03 100644
    --- a/helloworld.txt
        b/helloworld.txt
    @@ -1  1 @@
    -Hello India
     Hello World

```

There it is. Git shows the exact change I made in the file. But, if you look at the diff command, you might wonder what HEAD is doing there! Well, it is there for a purpose.

If you can recall, Git has an _index_ between local repository and your working directory. So most of Git commands can either refer to _index_ or the local repo. When you say HEAD in your Git command, it refers the _local repo_.

```shell

    //  compare the working directory with local repository.
    git diff HEAD [filename]

    // compare the working directory with index.
    git diff [filename]

    // compare the index with local repository.
    git diff --cached [filename]
```

You can also compare files between two different commits. Every commit in Git has a commit id which you can get when you give **git log**. Then you can use the commit id if diff command like this.

```shell

    git diff 7eb2..e03 812...a3f35

```

You can compare not just a single file, but all your changes at once. If you made changes in many files, just don't mention any file name in the diff command which will diff all the changed files.

```shell

    // compares working directory with index,
    // i.e. shows the changes that are not staged yet.
    git diff

    // compares working directory with local repository.
    // shows the list of changes after your last commit.
    git diff HEAD

    // compares index with local repository.
    // shows the diff between your last commit and changes to be committed next.
    git diff --cached

```

That's it about the basic introduction to compare files in Git. If you have any comments about this series, do let me know. I'll continue with other topics in my next post.


Git tutorial - comparing files with diff


As I promised on my previous article on [Getting started with Git][1], here is how I use Git in my day to day activities. Rather than explaining with a real project that I'm working (which I can't share!), I'm taking the 'ËœHello World' approach. What I'm going to do is to create a text file that contains the 'hello world' and then going to track it in Git.

[1]: https://veerasundar.com/blog/git-tutorial-getting-started "Git Tutorial - Getting Started"

I assume that you have [installed Git][2] on your machine and you have the PATH environment variable updated with Git's location. Also, I'm going to explain it with a local repository which means that I'll be creating the repository locally instead of cloning it from some remote repository. Let's start.

[2]: http://help.github.com/win-set-up-git/

## 1. Git repository creation

Open a terminal or command prompt and CD to your project directory. Then give the below command.

    c:> cd vraa/projects/helloworld
    C:/vraa/projects/helloworld>git init
    Initialized empty Git repository in C:/vraa/projects/helloworld/.git/

Now what I did was to create a** new local Git repository** to track my hello world project.

## 2. Git configuration - user name and email (one time)

Next thing is to setup a user name and email to be used in all my git commits. This is a one time activity per Git installation.

    C:/vraa/projects/helloworld> git config --global user.name "yourname"
    C:/vraa/projects/helloworld> git config --global user.email "your@mail.com"

## 3. Add a file to Git index and check status

Let's create a simple text file and see what Git feels about this file using **git status** command. Status will tell you the current status of the repository and branch details. And, in Git you don't need to check out anything before you start working on it. Just modify the file directly and then commit the changes later.

    C:/vraa/projects/helloworld> edit helloworld.txt
    C:/vraa/projects/helloworld> git status
    # On branch master
    #
    # Initial commit
    #
    # Untracked files:
    #   (use "git add ..." to include in what will be committed)
    #
    #       helloworld.txt
    nothing added to commit but untracked files present (use "git add" to track)

Ha! Git knows that there's a file but it is not tracking it yet. Well, we'll tell Git to track it (after all that is what Git is for!)

    C:/vraa/projects/helloworld> git add helloworld.txt
    C:/vraa/projects/helloworld> git status
    # On branch master
    #
    # Initial commit
    #
    # Changes to be committed:
    #   (use "git rm --cached ..." to unstage)
    #
    #       new file:   helloworld.txt

Now you can see that the status command tells you the list of files that will be committed. So, when you say **git add [filename]** you are asking the git to keep the file in _git index_ and track the changes. Simple, you are staging this file for commit. Next time when you do a commit all the files that are in index will be committed.

## 4. Let's commit the changes

By committing, you are moving your changes from _index_ to the _local repository_. Unlike Subversion, where a commit means saving code to a central repository, in git even after a commit the code will reside in your local repo. The outside world won't know about your changes, yet. So, you can fearlessly do as many commits as you wish.

    C:/vraa/projects/helloworld> git commit -m "initial commit"
    [master (root-commit) 812befb] initial commit
    warning: CRLF will be replaced by LF in helloworld.txt.
    The file will have its original line endings in your working directory.
     1 files changed, 1 insertions( ), 0 deletions(-)
     create mode 100644 helloworld.txt
    C:/vraa/projects/helloworld> git status
    # On branch master
    nothing to commit (working directory clean)

So, that's how my basic git workflow looks like. Creating a simple and committing and tracking changes using Git. In my [next post][3], I'll explain how I do more changes and differentiate between several file versions.

[3]: https://veerasundar.com/blog/git-tutorial-comparing-files-with-diff


Git Tutorial - My Git work flow


![git logo][1]I was a long time Subversion user then. So, when I got introduced to Git few months back, I was \*\*really\*\* confused. First of all, I couldn't visualize some of the concepts that Git talked about.

[1]: https://veerasundar.com/img/2011/06/git-logo.png "git-logo"

But then, as I started using Git in my day-to-day work, it got much easy to use and understand. Now there isn't a single day (except some of the weekends!) in which I don' t use a single Git command. It became an inseparable tool at my work.

So, just thought of writing my learning as a Git tutorial series to help a bit my fellow developers who want to switch over to Git. Let' start.

## Say Hello to Git

First of all, if you are coming from a Subversion/CVS background - mark my words - **forget everything you learned about version controlling**. Because Git has a completely different approach to version controlling. Lets see how it differs from other systems.

Git is distributed. Which means, when you clone a Git repo, you'll get a your own copy of that repo to work with in your local machine. In Git, you get your own code base, you make changes, commit as many times as you want without the fear of polluting the central repo and once you are confident push the code to central repository.

Before diving too much further, let's look at this awesome diagram which explains the Git workflow (thanks to [osteele.com][2], I have a printout of this pasted at my desk).

[2]: http://osteele.com

![git workflow][3]

[3]: https://veerasundar.com/img/2011/06/git.png "git"

As you can see in the above diagram, in Git, code lives in 4 different places

- **_remote repository _**- think of it as a Github repository or a remote server hosted in your company. As the name suggests, this code base does not live your local machine and You don't talk with remote repository often. Only when you pull a code initially and pushing the changes when you are done with it.
- **\*local repository** - \*when you clone a remote Git repo / or create a new repo, the code base is created here in the local repository. All commits you do will come here first. This lives in your local machine.
- **_index _**- one of the most confusing thing you'll ever hear in Git. This is something like a intermediate place between your working copy of code and your local repository. It's like a _staging area_ for your code. You use it to stage which files you want to track & commit. In my next post about *[My Git workflow][4] *you'll see how index is used. This code base too, lives in your local machine.
- **_workspace _**- it's your working directory where you create/edit/delete your files. This code resides in your local machine.

[4]: https://veerasundar.com/blog/git-tutorial-my-git-work-flow "Git tutorial - my git workflow"

Hope you get the basic concepts of Git. It is very important to understand it well before you start using Git. In my next post, I'll be writing about [my Git workflow][4]. Till then, feel free to [setup your Git environment][5].

[5]: http://help.github.com/win-set-up-git/ "This guide will walk you through the basics and explain a little bit about how everything works along the way."


#git (7)