It all started on a terminal of a macOS machine, with getting latest version of ruby,

\curl -sSL https://get.rvm.io | bash -s stable

restarting terminal

rvm install ruby-2.4.1

then updating gems (as it was already there, to get new see RubyGems)

gem update --system

then installing the creator of the subject of this story, Rails, together with Postgres the remember of necessary information.

gem install rails

# Install postgres

# Install pg gem
gem install 'pg'

# Install pg OS X driver with homebrew
gem install pg -- --with-pg-config=/usr/local/bin/pg_config

Creator was there, now it was the turn to bring the change to life

rails new change --database=postgresql

cd change

bundle install

rails db:create db:migrate

rails s

There the change was born at http://localhost:3000. Change needed to know the people with whom the story would develop, it came in contact with a gem called devise.

Devise, the one who knows to identify people.

Change realized that in today’s world to know more people it has to know Facebook and it would be easier to let those people connect to it via Facebook, devise then introduced omniauth to change.

With omniauth change could let people connect to it by using Facebook’s OAuth2 login mechanism.

At this moment it got facebook integrated inside views that are accessible at http://localhost:3000/users/sign_in and http://localhost:3000/users/sign_up

But it felt the need to make them accessible from http://localhost:3000 its home address. Then came the need of a navbar that can have links to those pages so that no one needs to remember those links. Thus came bootstrap (4 to be precise) which not only would give navbar but also make it possible to style ‘change’s’ home

Then came the navbar to allow access to log-in and sign-up under one hood

After user signs-in, there is a need to welcome them to the home

$ rails generate controller Pages home

# Update route in routes.rb
root to: 'pages#home'

Users entering the home from facebook would see their profile pictures but there is no way for the users that created an account using email/pwd. For now, change thought to generate random gravatar

On the way devise told change that putting the facebook app id and secret inside config/initializers/devise.rb directly isn’t a good idea and said figaro can help to keep secret

Now that change can start making contact, it wished to go out and establish contact with real people, it decided to move to a metropolis, Heroku

Change still needed to add facebook app id and secret to Heroku, figaro kept that secret

$ figaro heroku:set -e production

if this doesn't work
$ heroku config:set FB_APP_ID="<APP_ID>"
$ heroku config:set FB_APP_SECRET="<APP_SECRET>"

Change is now out in the real world with the help of its creator rails and postgres then with devise, omniauth, gravatar, bootstrap, figaro and eventually Heroku. The change proved to be there with least coding and gems :-)

But this is only the beginning of the change, it will change every day

Since past few years I have been working in continuous integration and continuous deployment practice environments. Automation from end-to-end i.e. from development to deployment.

Salesforce development is very different. The development you do resides in the environment itself, in their cloud. So typically you have multiple environments like Development, Test, Production, etc. You do your development in ‘Development’ environment and when you are happy with it you move those changes (via change-sets that is also managed in cloud) to ‘Test’ environment and so forth.

One could argue that the above way is also continuous integration in its own way and to me it is true for integration but not so for continuous. Because creating and deploying those changesets is manual and also testing for lighting community part is manual. You could setup external ways to doing automated tests but still you will need to trigger them and once they run OK trigger the deployment.

The drawbacks I find with this way for working are,

1. No version control
2. Change-sets do no guarantee isolated changes (No private workspace)
3. Manual testing and deployments
4. No rollback

Continuous integration is about the ease of development, having a version control for source code, writing automated tests, build server that builds and runs automated tests and a possible post build-test action to deploy to production.

First step, doing changes locally on your machine like a developer rather then making changes on the cloud environment. Mavensmate together with Atom. Mavensmate can sync data from Salesforce to local machine and vice-versa. Atom and IDE with mavensmate plugin allows editing the code.

Second step, writing automated tests. Writing BDD tests with Cucumber-BDD + Selenium. The tests justify and guard the expectations.

Third step, ensuring the custom development and configuration are maintained in source control. With the sources now available locally, it is easy to push to a version control system. I choose GitHub to maintain code.

Fourth step, running automated tests automatically. Using Jenkins server to run the automated tests. Whenever there is a commit pushed to GitHub it send an event on the Jenkins web-hook and that triggers a Jenkins job. Jenkins job runs all the tests and if there is a failure notifies concerned people. These tests are run against the sandbox environment where the changes were synced by Mavensmate.

Fifth step, deploy if all checks pass. With Ant scripts as Jenkins job post-build step deploy changes to the Salesforce production or another sandbox environment. Only the changes committed to GitHub that triggered the build are deployed, to ensure isolated changes.

Next steps

• Rollback changes with the help of Ant scripts if and when required.
• Use separate environments for each user-story/bug.

Salesforce DX

This is similar to what Salesforce DX proposes, build together and deliver continuously.

With scratch-orgs we get isolated environments for development. It will allow us to run our automated tests by hooking up with build pipelines like Heroku pipelines, that will also take care of the deployments.

The approach mentioned above it flexible and adaptable with DX tools, the systems in the pipeline are interchangeable and have similar way of usage.

Continuous integration for Salesforce lightning development was originally published in Salesforce Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Pull request (GitHub, BitBucket) Merge request (GitLab)

Some git implementations like GitHub, BitBucket have a feature that is called pull request. A pull request is a placeholder of all the changes you have on server to be merged into a specific branch. It gives you an overview of changes and allows other members to have a look into those changes like a review and comment on them. It will tell you if the changes are merge-able or there are possible conflicts.

A pull request has

• Base — this is the branch where you want your changes to go.
• Compare — this is the branch with your changes i.e. branch that has changes that are to be merged

Merge

Once you have completed all the necessary checks like code implementation, review, testing you want to get your changes to the master branch and get them released.

If you have a pull request then you just do this by a click of the button ‘Merge pull request’ but if you do not follow the practice of pull requests then you merge it first locally on your machine and then push the changes to server.

To do manual merge, lets say we want to merge ‘feature-awesome’ into ‘master’ then we first checkout latest of master then merge feature-awesome into master and push the master branch to server.

Pull rebase

Very often there more than one person is working on the same branch. Then it is necessary to keep taking other persons changes to ensure that you are making your changes on top of their changes.

Suppose in our example other person has made changes (css styling) on our feature and we need to have those to continue further implementation then we need to pull those changes on our local branch. Lets first see how it looks like before we do any local changes, so that means we only do fetch.

Here we see that the server version (‘origin/feature-awesome’) of our local branch (‘feature-awesome’) has an additional commit ‘Create awesome.css’. Now we need to get it, we can do it simply by pulling those changes as we do not have any commits or changes that are not on server. After we do a pull it looks like this,

Now assume that we had some local commits i.e. some commits that are only done on local repository on branch ‘feature-awesome’ then the original fetch would look like this,

Here we see that the server version of the branch has one additional commit but is missing one commit from our local branch. Here only pulling the changes will not work, this is where we do pull rebase that will allow use to first get all the changes on server and then apply local commits on top of it. Then it will look like this,

See our local commit is now on top of the branch again. It is the head now.

Rebase on another branch

It is about time where we think that the feature implementation is done and we want to get it tested or reviewed, then we want to ensure that we have all the changes of our main branch here it is ‘master’. If you see in the earlier image then we see that the master branch has one commit that our feature branch is missing.

Most version controls would give you an option to merge the master branch into your branch so that you will get all the missing changes but with git you have an additional option where it allows you to rebase a branch on top of another branch.

When you rebase your branch on another branch, git will

• Save the commits on your local branch to temporary area
• Get the commits from the other branch to your local branch
• Apply the commits previously saved in temporary area to your branch

The benefits of this over merging to me are,

• There is no additional commit on your branch
• It allows you to resolve conflicts on the required commit. With merging approach if there are any conflicts then you need to resolve it on that merge commit but with rebase you solve the conflicts on the commits that are saved to temporary area as the conflicts arise when applying them not before.

So when we rebase our ‘feature-awesome’ branch on ‘master’ branch it looks like this,

Remove commits

Suppose you have a commit that you do not want to have anymore, it was a temporary commit and no longer required then with git you are remove a particular commit, yes git allows to rewrite history.

Suppose in our example we want to remove ‘Configuring awesomeness’ the commit as it is no longer needed. We can do that by rebase’ing’ our branch on one commit before the commit (yes we can rebase not only on a branch but also a commit) that is not required but this time doing interactive rebase.

Then when rebasing choose interactive rebase.

Then click rebase. You will be presented with an editor or a window that will show you the commits that will be rebased.

From this window you can remove the commit that is no longer required, save and close that window to continue rebase.

After rebase is complete that commit will disappear (it is still on the server as we have not pushed the branch yet)

Squash commits

When you working with multiple people on one branch in order to communicate your changes to each other you commit often but before you send it out to review or test or merging in the main branch you do not need all those small separate commits. With git you can squash two or more commits into one commit and also re-write the commit message to make your intention clear.

As we did before to remove commits an interactive rebase, to squash commits (which is also a history re-write operation) we do an interactive rebase.

There are two ways to squash commits,

• Squash and reuse exiting commit message, operation s
• Squash but change the commit message, operation f

In the above window, lets say we want to squash all the commits in one commit and also change the commit message we prefix all but the first commit (as we need at least one commit for the changes) with ‘f’ or ‘fixup’ instead of ‘pick’ and for the first commit say ‘r’ or ‘reword’. Save the window and continue. It will show another window where you are see the first commit’s commit message and you can change it by new commit message like ‘Feature awesomeness complete’ and continue rebase. Now it will look like this,

Now we push our changes to the server so that review, builds and test can proceed. Only this time git will tell you that there are changes on server that are not locally because,

• Either someone else added new commit on the same branch then you need to first do pull-rebase.

OR

• There were no new changes on the server but as we re-wrote the history by rebaseing on different branch, removing commits, squashing commits, changing commit message, that now commits of the server pulled earlier do not match with the commit on the server. So now we do a ‘force push’ instead. Force push will re-write the branch on server. Just be cautious and check with others on your team about the force push to ensure you do not overwrite any commits in transit.

Making changes

Once you have created your branch you start making changes to the files i.e. start implementing your feature or fixing the bug.

Commit

Make sure you are committing regularly, when you commit you are making changes to your local branch on your local repository. This is important when there is more than one person contributing to the development on the same branch.

Push

To make your changes available to other team members, it is important to push your changes. By pushing the changes you send the commits to server. Now other team members can get latest of the branch and continue working.

Fetch

When you are working you make sure that every day you have the latest code and then you work from there. With Git being distributed version control system you not only need to know latest on your local repository but also the server repository. For this Git has something called fetch.

To know what is latest on the server repository you do “fetch”, this shows you the current status of all branches on the server.

Pull

With fetch you know the changes that are on server but not on your local repository yet. To get the changes on your local copy of the branch you need to pull the changes. Pull will first do ‘fetch’ and then apply the commits of the pulled branch on the branch tracked to your local repository. If the branch does not exist locally it will create the branch and establish tracking for future references.

From the above image we see our local ‘master’ branch is not in sync with server ‘origin/master’ branch. So we checkout master and then pull from origin i.e. server.

Repository

Like with most version control systems the first thing you do is, either create a repository or get an existing repository.

Create a repository

Create a Git repository locally by executing ‘git init’ command OR via GUI OR you can create Git repository on server like (GitHub, BitBucket, GitLab, etc) and clone it locally.

Get an existing repository

Using command line go to the directory you wish to clone the repository type:

git clone <git repo url.git>

Using GitExtensions click on Clone Repository and then use your Git repository URL of the server and clone it locally.

How to differentiate what is local and what is server’s?

Most Git GUIs will show the branch name on the commit, when there is no prefix to the branch like ‘origin/’ you know that it is your local repository. The prefix is to show an external path. These are called as remote paths and can be updated in remote repositories section. When you clone an existing repository or do your first push of a new repository, the tracking between local and server repository is established. By default the server repository is denoted by ‘origin’ however it can be changed to whatever you like.

In the above image ‘master’ is local and ‘origin/master’ is remote (server).

Branching

One of the most important part of having a version control system is doing your changes in isolation. Making sure it works and passes integration and only then getting it in to a release of a product. For this, version control systems provide a mechanism which is called branching, via which you get a branch. A branch is is a copy of a section of your repository i.e. copy of commits.

In Git you are always working on a branch whether it is main (master) branch or feature branch. In Git you create a branch from another branch, the source is then called as parent branch.

A Git repository starts with a ‘master’ branch. When you start development you do not directly make changes on your master branch, that branch is suppose to be stable always, pointing to latest released. Instead you create a branch from your stable branch and you make your changes there.

You create a branch by right clicking on the parent and then say create branch. If for any reason you have started working on your source branch, but while committing you realize that you should have created a new branch then it is OK, you can create a branch with your current uncommitted changes.

Like with most version control systems the first thing you do is either create a repository or get an existing repository.

Create a repository

Create a git repository locally by executing ‘git init’ command or via GUI OR you can create git repository on server like (GitHub, BitBucket, GitLab, etc) and clone it locally.

Get an existing repository

From command line in the directory you wish to clone the repository type

git clone <git repo url.git>

Using GitExtensions click on Clone Repository and then use your git repository URL of the server and clone it locally.

How to differentiate what is local and what is server?

Most Git GUIs will show the branch name on the commit, when there is no prefix to the branch like ‘origin/’ you know that is your local repository. The prefix is show external path. These are called as remote paths and can be updated in remote repositories section. When you clone an existing repository or do your first push of a new repository the tracking between local and serer repository is established. By default the server repository is denoted by ‘origin’ however it can be changed to whatever you like.

In the above image ‘master’ is local and ‘origin/master’ is remote (server).

Branching

One of the most important part of having a version control system is doing your changes in isolation, making sure it works and passes integration and only then getting it in to a release of a product. For this version control systems provide a mechanism which is called branching, via which you get a branch. A branch is is a copy of a section of your repository i.e. copy of commits.

In git you are always working on a branch whether it is main (master) branch or feature branch. In git you create a branch from another branch, the source is then called as parent branch.

A git repository starts with a ‘master’ branch. When you start development you do not directly make changes on your master branch, that branch is suppose to be stable always, pointing to latest released. Instead you create a branch from your stable branch and you make your changes there.

You create a branch by right clicking on the parent and then say create branch. If for any reason you starting working on your source branch but while committing you realize that you should have created a new branch then it is OK you can create a branch with your current uncommitted changes.

Making changes

Once you have created your branch you start making changes to the files i.e. start implementing your feature or fixing the bug.

Commit

Make sure you are committing regularly, when you commit you are making changes to your local branch on your local repository. This is important once you are more than one person contributing to the development on the same branch.

Push

Then it is also important to keep pushing your changes to the server so that the other person can take your changes.

Fetch

When you are working you make sure that every day you have the latest code and then you work from there. With git being distributed version control system you not only need to know latest on your local repository but also on the server repository. For this git has something called fetch.

To know what is latest on the server repository you do git fetch, this shows you the current status of all branches on the server.

Pull

To get the latest from server for a branch on same branch on your local repository you need to pull the changes. Pull will first do ‘fetch’ and then apply the commits of the pulled branch on the branch tracked to your local branch. If the branch does not exist locally it will create the branch and establish tracking for future references.

From the above image we see our local ‘master’ branch is not in sync with server ‘origin/master’ branch. So we checkout master and then pull from origin i.e. server.

Pull rebase

Very often there more than one person is working on the same branch. Then it is necessary to keep taking other persons changes to ensure that you are making your changes on top of their changes.

Suppose in our example other person has made changes (css styling) on our feature and we need to have those to continue further implementation then we need to pull those changes on our local branch. Lets first see how it looks like before we do any local changes, so that means we only do fetch.

Here we see that the server version (‘origin/feature-awesome’) of our local branch (‘feature-awesome’) has an additional commit ‘Create awesome.css’. Now we need to get it, we can do it simply by pulling those changes as we do not have any commits or changes that are not on server. After we do a pull it looks like this,

Now assume that we had some local commits i.e. some commits that are only done on local repository on branch ‘feature-awesome’ then the original fetch would look like this,

Here we see that the server version of the branch has one additional commit but is missing one commit from our local branch. Here only pulling the changes will not work, this is where we do pull rebase that will allow use to first get all the changes on server and then apply local commits on top of it. Then it will look like this,

See our local commit is now on top of the branch again. It is the head now.

Rebase on another branch

It is about time where we think that the feature implementation is done and we want to get it tested or reviewed, then we want to ensure that we have all the changes of our main branch here it is ‘master’. If you see in the earlier image then we see that the master branch has one commit that our feature branch is missing.

Most version controls would give you an option to merge the master branch into your branch so that you will get all the missing changes but with git you have an additional option where it allows you to rebase a branch on top of another branch.

When you rebase your branch on another branch, git will

• Save the commits on your local branch to temporary area
• Get the commits from the other branch to your local branch
• Apply the commits previously saved in temporary area to your branch

The benefits of this over merging to me are,

• There is no additional commit on your branch
• It allows you to resolve conflicts on the required commit. With merging approach if there are any conflicts then you need to resolve it on that merge commit but with rebase you solve the conflicts on the commits that are saved to temporary area as the conflicts arise when applying them not before.

So when we rebase our ‘feature-awesome’ branch on ‘master’ branch it looks like this,

Remove commits

Suppose you have a commit that you do not want to have anymore, it was a temporary commit and no longer required then with git you are remove a particular commit, yes git allows to rewrite history.

Suppose in our example we want to remove ‘Configuring awesomeness’ the commit as it is no longer needed. We can do that by rebase’ing’ our branch on one commit before the commit (yes we can rebase not only on a branch but also a commit) that is not required but this time doing interactive rebase.

Then when rebasing choose interactive rebase.

Then click rebase. You will be presented with an editor or a window that will show you the commits that will be rebased.

From this window you can remove the commit that is no longer required, save and close that window to continue rebase.

After rebase is complete that commit will disappear (it is still on the server as we have not pushed the branch yet)

Squash commits

When you working with multiple people on one branch in order to communicate your changes to each other you commit often but before you send it out to review or test or merging in the main branch you do not need all those small separate commits. With git you can squash two or more commits into one commit and also re-write the commit message to make your intention clear.

As we did before to remove commits an interactive rebase, to squash commits (which is also a history re-write operation) we do an interactive rebase.

There are two ways to squash commits,

• Squash and reuse exiting commit message, operation s
• Squash but change the commit message, operation f

In the above window, lets say we want to squash all the commits in one commit and also change the commit message we prefix all but the first commit (as we need at least one commit for the changes) with ‘f’ or ‘fixup’ instead of ‘pick’ and for the first commit say ‘r’ or ‘reword’. Save the window and continue. It will show another window where you are see the first commit’s commit message and you can change it by new commit message like ‘Feature awesomeness complete’ and continue rebase. Now it will look like this,

Now we push our changes to the server so that review, builds and test can proceed. Only this time git will tell you that there are changes on server that are not locally because,

• Either someone else added new commit on the same branch then you need to first do pull-rebase.

OR

• There were no new changes on the server but as we re-wrote the history by rebaseing on different branch, removing commits, squashing commits, changing commit message, that now commits of the server pulled earlier do not match with the commit on the server. So now we do a ‘force push’ instead. Force push will re-write the branch on server. Just be cautious and check with others on your team about the force push to ensure you do not overwrite any commits in transit.

Pull request (GitHub, BitBucket) Merge request (GitLab)

Some git implementations like GitHub, BitBucket have a feature that is called pull request. A pull request is a placeholder of all the changes you have on server to be merged into a specific branch. It gives you an overview of changes and allows other members to have a look into those changes like a review and comment on them. It will tell you if the changes are merge-able or there are possible conflicts.

A pull request has

• Base — this is the branch where you want your changes to go.
• Compare — this is the branch with your changes i.e. branch that has changes that are to be merged

Merge

Once you have completed all the necessary checks like code implementation, review, testing you want to get your changes to the master branch and get them released.

If you have a pull request then you just do this by a click of the button ‘Merge pull request’ but if you do not follow the practice of pull requests then you merge it first locally on your machine and then push the changes to server.

To do manual merge, lets say we want to merge ‘feature-awesome’ into ‘master’ then we first checkout latest of master then merge feature-awesome into master and push the master branch to server.

They hide behind the phrase:

“steep learning curve.”

This is my attempt to find a way to make Git easier to learn and make one hands on with it quicker.

Git is a distributed version control system. It allows group of people to work on the same code (files), without stepping on each other’s toes.

What is a version control?

You are working on a product that is a solution to world class problem. You make this awesome app. You manage to make it work with 3 files. It is working fine you release it. It is just three files you can handle it.

Now you are working on a new feature that changes one of the 3 files. However in the meantime you have a critical issue to fix, and that changes the same file. So you juggle adding a new feature and fixing a critical issue. So what do you do?

Simple, it is just 3 files, then:

• make a copy of the files in another directory
• fix the bug
• re-release the application.

But now imagine you need to manage an application with hundreds of files or more. It become tedious and soon unmanageable to keep track of the changes. More people contributing to the changes it turns more problematic. That’s why we need version control systems, for collaboration and versioning.

Version control systems records changes to a file or set of files over time so that you can recall specific versions later. It keeps track of every modification to the file. If a mistake is made, you can compare with earlier versions or bring back older version while minimizing disruption to all team members.

About Git

As you learn Git, try to clear your mind of the things, you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool. Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar. Understanding those differences will help prevent you from becoming confused while using it.

Repository

The purpose of Git is to manage a project, or a set of files, as they change over time. Git stores this information in a data structure called a repository.

Storing snapshots (making it fast)

The major difference between Git and and other VCSs is in the way it thinks about its data. Other VCSs like SVN, TFS store deltas i.e. they store only the changes in next revisions.

In the above image observe that in the version 2 when File A was modified it will only store the changes done on File A in version 2.

Git on the other hand store the modified copy of the complete file when the file is changed, more like a snapshot of the file. This makes most Git operations quick like creating a branch, getting latest (as it does not have to drill further and further to get one file), etc.

In the above image observe that when File A is modified it will keep the complete modified file in Version 2.

Ease of undo-redo

Almost every operation you do is an add operation to a Git repository, this means with regular commits it is very difficult to get the system to do anything that is not undo-able. It makes it easy to experiment and it is easy to recover previous version. Also as almost every operation you do on a Git repository is local (done on the local copy of the repository) it makes it easier to not publish any changes until you are happy with it.

Repository and what you can do with it?

Repository is a place where history of your work is stored, all your commits (check-ins), branches, tags (labels).

How do you get a repository?

Create one

When you are starting with a new project and want to setup version control using Git, then you create your repository.

You do that by typing ‘git init’ on the command line inside a directory that becomes your repository.

Clone one

When you are joining in on an existing project which, already has a Git repository on a Git server somewhere (like GitHub, BitBucket, GitLab, etc.) you clone that repository locally (i.e. make a copy of it on your local machine).

You do that by getting a clone url of the repository (look at server url of the repository usually ending with .git) then type in the concerned directory,

git clone <git repository url ending with .git>

What happens when you have a Git repository locally?

Once you have cloned or created a repository locally you see you have a .git folder, this is where your repository is in a compressed format.

Git workflow

Normally when you are working with Git or for that matter any version control system, you work on a branch (a copy of your latest stable version).

Your path is as follows:

How Git does it?

Files in a Git repository can be in 3 states, committed, modified and staged.

• Committed means that the data is safely stored in your local database.
• Modified means that you have changed the file but have not committed it to your database yet.
• Staged means that you have marked a modified file in its current version to go into your next commit.

A local Git repository has following 3 states

1. Working directory

• Single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.
• You modify your files here.

2. Staging area (index)

• Generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the “index”, but it’s also common to refer to it as the staging area.
• Files selected to go in next commit snapshot.

3. Repository (.git directory)

• .git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.
• Files from staging area that are committed.

In normal day to day process you do not often stage files and keep it there for long, because you modify files, ensure to commit them regularly and continue working.

You push to the server only when you are happy with the changes or you need someone else (working on the same branch)to have your changes. Making commits often on your local repository is fine, because with Git you can later rearrange your commits and/or squash (merge) them. When you start with Git this can be helpful until you get a hang of the whole Git workflow.

Git GUIs

While working with Git it is important to:

• Keep track of the branch you are working on
• Keeping your current branch up to date.
• Knowing what is on the server’s copy of the branch and what is on the local copy of the branch.

Doing it seamlessly becomes a tough task.

Although almost all operations on a Git repository are reversible. Command line for Git operations, can become very confusing especially when there are multiple people on single Git repository and it is growing fast.

There are some GUIs that shows you the overview and provide simpler menu options for operations. Such as:

1. Git Extensions : Gives a nice overview of your repository, what is on server and what is locally, your current working branch, your changes, simple operations (commit, push, pull, rebase, etc.).
2. SourceTree
3. Git Kraken
4. GitHub for Windows

This is a simpler overview of how Git works and how one can use Git for collaboration and versioning.

Click here if you want to know more about Working with Git