Update the existing git tag in remote repository

Generally GIT tags are used to mark release points. Every time we make a release in our project, we tag it using the command:

git tag -a VER_7_5_0 -m "Version 7.5.0 tagged"

then push it to central repository to share with others.

 git push --tags

Often times this tag has to be altered to include/exclude a fix from the release, before make it to the customer.

Here are the steps to update the existing tag in remote repository:

Step 1: Update a tag in local repository using -f option.

            git tag -a -f VER_7_5_0 -m "Version 7.5.0 tagged"

Step 2: Remove a tag from remote repository.

            git push origin :refs/tags/VER_7_5_0

Step 3: Push the updated tag to remote repo.

            git push --tags

To view remote tags:

git ls-remote --tags origin

Caution: If someone already pulled your tags into their local repo, they will not get the updated one unless they delete the old one. If you are not sure about this, you better create a new tag instead of updating the existing one.

How to rename a GIT tag in the remote repo?

Some times we would have added a tag, pushed it to remote and then realized that we’d named it wrong. 
Ex. VER_7_2_0 instead of VER_7_1_2. 

Here is quick tip to rename a git tag in the remote repo. 

Step 1: Create a new tag on the same commit point of old tag and push it, 
git tag new_tag old_tag 
git push --tags 

Step 2: Delete the old tag from local repo. 
git tag -d old_tag 

Step 3: Delete the old tag from remote repo. 
git push origin :refs/tags/old_tag 

You can verify the changes made, by executing the below command. It shows all remote tags: 
git ls-remote --tags origin

Configuring Git Email Notifications via Post-receive hook

Here I'm going to explain how to configure Git to send email notifications when 'central' repo is updated on Linux and windows machines. 

LINUX:

Step 1: Copy (or symlink) the post-receive script, or download it here. The script must be in the ‘hooks’ directory like this:
$GIT_DIR/hooks/post-receive

Make sure it is named “post-receive” so that Git recognizes it.

Step 2: Make sure that the script is executable:

chmod a+x $GIT_DIR/hooks/post-receive

Step 3: Edit the first line of $GIT_DIR/description to be your repository name. This will be in the subject of the email.

Step 4: Edit $GIT_DIR/config with some email settings such as recipient / sender email and subject-line prefix. Here’s some basic settings (read the script for all possible settings).

[hooks]
mailinglist = "receiver1@receivers.com, receiver2@receivers.com"
envelopesender = sender@senders.com
emailprefix = "[GIT] "

Note: you can also set these by using git-config:

git-config hooks.mailinglist "receiver1@receivers.com, receiver2@receivers.com"
git-config hooks.envelopesender sender@senders.com
git-config hooks.emailprefix "[GIT] "

That’s it ! Try doing a git-push to your shared repository, and see if you get email notifications.

WINDOWS:

STEP 1: Same as Linux.

STEP 2: The post-receive script is using 'sendmail' for sending mails. But Git for Windows provides msmtp not sendmail. So we need to configure smtp server and use it in the script. Replace sendmail with msmtp in the post-receive script as follows

send_mail()
{
    if [ -n "$envelopesender" ]; then
        msmtp --host="$smtpserver" -t -f "$envelopesender"
    else
        msmtp --host="$smtpserver" -t
    fi
}

And finally, near the end of the file is a section that reads in the git config variable so add a new line to read server values:

smtpserver=$(git config sendemail.smtpserver)

STEP 3: Same as Linux.

STEP 4: It requires all configuration as mentioned in step 4 Linux. Apart from that it requires one more variable to configure "sendemail.smtpserver"

git-config sendemail.smtpserver 192.168.16.12

That's it for windows!.

The default behavior of 'git push'...

Whenever we decide to share our work, we do push our changes to a remote repository.

If you are working only in a single branch then you don't need to worry about this topic. But if you have many branches, you must aware the default behavior of 'git push'. This command actually pushes all branches (not only your current branch) to the corresponding remote branches.

But, mostly we want to push only the current branch to the remote repo. We can configure GIT to change the default behavior.

git config push.default upstream

It means git will update only the current branch to it's upstream, when you do git push.

Other valid options are:

nothing : Do not push anything.

matching : Push all matching branches (default).

upstream: Push the current branch to its upstream branch. (the branch git pull would pull from)

tracking : Deprecated, use upstream instead.

current : Push the current branch to the remote branch of the same name.

UPDATE:

Since git version 1.7.11, A new mode, "simple", which is a cross between "current" and "upstream", has been introduced. "git push" without any refspec will push the current branch to the remote branch with the same name, only when it is set to track the remote branch. This mode is the new default value when push.default is not configured.

GIT --everything-is-local

One of the advantage of GIT over CVS is, in GIT almost everything is local.

It means, you do not need to be connected with the server all the time, because 95% of git commands can be executed in the local repository.

Comparing different version of files, Getting the history of files, Committing the changes to the files - all are LOCAL and FAST in GIT.

There are very few commands, which are not local.  But they have reasons for that :-)

git pull/fetch - Pull/fetch changes from the server. (remote repo)

git push - Push the changes to the server.

git clone - Clone a remote repository.

git ls-remote - List references in a remote repo.

git remote show - Gives info about a remote repo.

git remote prune - Deletes all stale remote-tracking branches.

git remote update - Updates group of remote-tracking branches.

Using Winmerge as a diff tool in GIT

Step 1:

Install Winmerge.

Step 2:

Create a file named ‘winmerge.sh’ under your repository.

Step 3:

Write this into ‘winmerger.sh’ file.

#!/bin/sh

echo Launching WinMergeU.exe: $1 $2

"PathToWinMerge" -e -ub -dl "Base" -dr "Mine" "$1" "$2"

Path To Winmerge: Ex:  C:/Program Files/WinMerge/WinMergeU.exe

Step 4:

Update your .gitconfig file (will be under your user folder C:\Documents and Settings\YourName)

[diff]

            tool = winmerge

[difftool]

            prompt = false

[difftool "winmerge"]

            cmd = winmerge.sh $LOCAL $REMOTE

Step 5:

Using winmerge:

git difftool ReleativeFilePath/FileName

How to set GIT to ignore a few files - like properties or config files

From time to time there are files you don’t want git to track. There are a few methods of telling git what files to ignore.

Method One:

1.      Create a .gitignore file in your git repository home.

2.      Create rules inside the .gitignore file.

Examples:

# To ignore a ‘build’ folder

build/

# To ignore all ‘.class’ files

*.class

            We can use this method to ignore the folder/files that are specific to project (common to all users).
It can be pushed to central repository, so that all users can use the same .gitignore file.
Note: This method can not be used to ignore the files that are already tracked by GIT.

Method Two:

1. Create rules inside .git/info/exclude file.

Examples:

# To ignore a ‘.project’ and ‘.classpath’ files

.project

.classpath

This method can be used to ignore locally-generated files that you don’t expect other users to generate, like files created by your editor.

These rules can not be committed with the repository, so they are not shared with others.
Note: This method can not be used to ignore the files that are already tracked by GIT.

Method Three:

1.      Use --assume-unchanged.
                    git update-index --assume-unchanged <filename>

Example:

      # To ignore build.xml, run this command.

                        git update-index --assume-unchanged build.xml
Note: We can use this method to ignore the files that are already tracked. To track the file again, 
execute "git update-index --no-assume-unchanged <filename>". These commands do not affect remote repository.

Types of GIT Branches..

1. Remote Branch

         The branch which exists in the remote repository. This will be updated whenever you do git push.

2. Local Branch

         The branch which exists in your local repository. This is where you make code changes. This branch will be updated whenever you do git commit, git merge and git pull.

3. Remote Tracking Branch

          The copy of remote branch, exists in the local repository. The intermediate branch between your local branch and the remote branch. This branch will be updated, whenever you do git fetch, git pull and git push.

How to fix GIT error: You have not concluded your merge (MERGE_HEAD exists)

GIT Error message:

You have not concluded your merge (MERGE_HEAD exists).
Please, commit your changes before you can merge.

Cause: Your previous merge was failed to merge automatically and went to conflict state. And you tried to pull again before resolving the conflict.

Solution: Undo the merge and perform the merge again properly.

Steps:

1) Undo the merge and pull again.

To undo a merge:

git merge --abort [Since git version 1.7.4]

git reset --merge [prior git versions]

2) Resolve the conflict.

3) Don't forget to add and commit the merge.

4) git pull now should work fine.

Please let me know, if it's still not working. Thanks.

Link to my SO post: http://stackoverflow.com/a/11647899/1365319