Resolving Git conflicts

When looking at git conflict markers it can sometimes be confusing which half of the conflicting section belongs to which branch:

<<<<<<< HEAD
foo
=======
bar
>>>>>>> cb1abc6bd98cfc84317f81a95a7662815417802d

• the top half is the branch you a merging into
• the bottom half is from the commit that you are trying to merge in

What this means in practice if you are doing something like git pull (which is equivalent to a git fetch followed by a git merge) is:

• the top half shows your local changes
• the bottom half shows the remote changes, which you are trying to merge in

On the other hand, if you are doing something like git rebase origin/master, you are effectively trying to merge your local changes "into" the upstream changes (by replaying them on top); that means:

• the top half shows the upstream changes
• the bottom half shows your local changes, which you are trying to merge in

Resources:

https://git-scm.com/docs/git-rebase

How to remove a wrong commit from the pull request

 $ git checkout pull_request_branch

 $ git rebase -i HEAD~n //n is the number of commits you would like to see during rebase or you could specify the number of commits you have made to the pull request.

3. Replace pick with drop for commits that you want to discard from the PR

Once you are done with the rebase, push forcefully to the remote branch

$git push origin pull_request_branch -f

You are good!

What tense should I use in git commit message?

So far I was mostly using the past tense since it looks natural to me but the git best practices suggest us to use imperative sentence.

Example: 

My old git message:
Added IDF commands into CMake editor

New git message:
Add IDF commands into CMake editor

Follow this thread for more discussion on this:
https://stackoverflow.com/questions/3580013/should-i-use-past-or-present-tense-in-git-commit-messages

When to amend/squash commits and how to maintain a clean PR

I always like to improve the development process with the git and a strong believer in the clean code.

Something which I always insist during my PR review is - maintain the clean git history by avoiding the unnecessary indivual commits. 

Broadly, we can follow these 2 rules:

1. amend/squash commits if they don't add semantic value to the PR
2. Always rebase the PR before you push to the server

Below article exactly reflects my thought on this.

https://github.com/mockito/mockito/wiki/Using-git-to-prepare-your-PR-to-have-a-clean-history

Other nice articles on this:

https://www.atlassian.com/git/tutorials/rewriting-history

https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

Git tag operations

First, let me check my branch and the origin

item-ax40113:es6features kkolipaka$ git branch

* master

item-ax40113:es6features kkolipaka$ git remote -v

origin https://github.com/kolipakakondal/es6features.git (fetch)
origin https://github.com/kolipakakondal/es6features.git (push)

Let me view my existing git tags on this branch

$ git tag

1.0.1

1.0.2

1.0.2.201807

1.0.2.20180730

Create a new git called "1.0.3"

$ git tag 1.0.3

$ git tag

1.0.1

1.0.2

1.0.2.201807

1.0.2.20180730

1.0.3

Create a new git tag with the message

$ git tag 1.0.4 -m "1.0.4 GA release"

$ git show 1.0.4

tag 1.0.4

Tagger: Kondal Kolipaka <kondal.kolipaka@gmail.com>

Date:   Mon Sep 17 15:56:31 2018 +0800

1.0.4 GA release

commit 24302d15e49d24ee208ca7eb725f34dbf37cd0ef

Author: Kondal Kolipaka <kondal.kolipaka@gmail.com>

Date:   Mon Jul 30 18:20:46 2018 +0800

    adding comment for test

Push git tag to the remote server repository

$ git push origin 1.0.4

Counting objects: 5, done.

Delta compression using up to 8 threads.

Compressing objects: 100% (5/5), done.

Writing objects: 100% (5/5), 1.43 KiB | 0 bytes/s, done.

Total 5 (delta 2), reused 0 (delta 0)

remote: Resolving deltas: 100% (2/2), completed with 2 local objects.

To https://github.com/kolipakakondal/es6features.git

 * [new tag]         1.0.4 -> 1.0.4

Let me rename git tag from "1.0.4" to "1.0.4.GA"

$ git tag

1.0.1

1.0.2

1.0.2.201807

1.0.2.20180730

1.0.3

1.0.4

$ git tag 1.0.4.GA 1.0.4

$ git tag

1.0.1

1.0.2

1.0.2.201807

1.0.2.20180730

1.0.3

1.0.4

1.0.4.GA

Let me push the newly git to the remote repo

Before that, let me delete my git tag first from the local repo

$ git tag -d 1.0.4

Deleted tag '1.0.4' (was c3a04e7)

item-ax40113:es6features kkolipaka$ git tag

1.0.1

1.0.2

1.0.2.201807

1.0.2.20180730

1.0.3

1.0.4.GA

Let me also delete my old git tag "1.0.4" from the remote repo

$ git push origin :1.0.4

To https://github.com/kolipakakondal/es6features.git

 - [deleted]         1.0.4

Now, let me push my renamed git tag "1.0.4.GA" to the remote server

item-ax40113:es6features kkolipaka$ git push origin 1.0.4.GA

Counting objects: 5, done.

Delta compression using up to 8 threads.

Compressing objects: 100% (5/5), done.

Writing objects: 100% (5/5), 1.43 KiB | 0 bytes/s, done.

Total 5 (delta 2), reused 0 (delta 0)

remote: Resolving deltas: 100% (2/2), completed with 2 local objects.

To https://github.com/kolipakakondal/es6features.git

 * [new tag]         1.0.4.GA -> 1.0.4.GA

Here is my current release commits for 1.0.4 GA, git tag "1.0.4.GA" is created on the latest commit which is "24302"

$ git log --pretty=oneline

24302d15e49d24ee208ca7eb725f34dbf37cd0ef adding comment for test

f9446b4a8dc7112eb64f60981a3700ae49cf483b some more changes

58694540ee96369dd34898288ac1bfb1f0ac203e some more changes

b1743684346a42cc3b0820b2e1241bfc3f794a1a changes

ba039a51a49ae67cbb3fb9c3c2f8d49335588eca Update .mergify.yml

c458c898ec1efcd2d1c03b762b8d2437dc5ce644 Enable mergify.io

3632a41f38bc7ee7ad409666397301f80815ff58 ES6 sample app for Appcelerator titanium

Fix#1 added

$ git add es6features/LICENSE.txt

$ git commit -m "Fix1 on 1.0.4 GA release"

[master be67c9f] Fix1 on 1.0.4 GA release

 1 file changed, 2 insertions(+), 1 deletion(-)

Fix#2 added

$ git add es6features/LICENSE.txt

$ git commit -m "Fix2 on 1.0.4 GA release"

[master a609582] Fix2 on 1.0.4 GA release

 1 file changed, 2 insertions(+), 1 deletion(-)

2 new commits added after 1.0.4 GA release

item-ax40113:es6features kkolipaka$ git log --pretty=oneline

a60958216f0e64c2d9374978e0064585e6bca7b2 Fix2 on 1.0.4 GA release

be67c9f4d7780686eb7469ab681bc7f0ee3ca4ca Fix1 on 1.0.4 GA release

24302d15e49d24ee208ca7eb725f34dbf37cd0ef adding comment for test

f9446b4a8dc7112eb64f60981a3700ae49cf483b some more changes

58694540ee96369dd34898288ac1bfb1f0ac203e some more changes

b1743684346a42cc3b0820b2e1241bfc3f794a1a changes

ba039a51a49ae67cbb3fb9c3c2f8d49335588eca Update .mergify.yml

c458c898ec1efcd2d1c03b762b8d2437dc5ce644 Enable mergify.io

3632a41f38bc7ee7ad409666397301f80815ff58 ES6 sample app for Appcelerator titanium

Now we want to make a release 1.0.5 with only Fix#1 - In this case, we need to create a tag with the Fix1 commit hash id.

$ git tag -a 1.0.5.GA be67c9f4d7780686eb7469ab681bc7f0ee3ca4ca -m "1.0.5 GA release with the Fix#1" 

$ git tag

1.0.1

1.0.2

1.0.2.201807

1.0.2.20180730

1.0.3

1.0.4.GA

1.0.5.GA

GIT: Pushing a remote branch with a different local branch name

Usually, when you are pushing like git push origin master, your remote branch name and local branch is same i.e, master

But if you're having a different branch name locally for your remote branch 'master

$ git push origin localbranchName:remotebranchName

example: git push origin testlocal:master

Git force merge

Here is my scenario - I've development and release branches. And I want to merge my changes from development to release branch and if any conflicts during merge and I want to overwrite with the development branch changes.

$ git checkout release  => switch from development to release branch
$ git merge -X theirs development  => merge changes from development to release branch


Understand more about it here - https://stackoverflow.com/questions/40517129/git-merge-with-force-overwrite

Best Practice: Don't combine Refactoring commit with the actual fix changes

For a better code reviewability, don't combine refactoring changes and fix changes into a single commit.

If it's a very small refactoring change, it's completely fine, we can combine together. Otherwise, it's going to be difficult for the reviewer to read the code and understand it. The Reviewer has to change the context from refactoring to an actual fix and vice versa, and in the process, we tend to ignore the actual fix code and that leads a problem again!


Let me point to a first resource which I found when googled it about this subject.
http://jakegoulding.com/blog/2012/11/04/refactor-and-make-changes-in-different-commits/

Recovering staged lost files during git reset --hard

$ git fsck --cache --unreachable $(git for-each-ref --format="%(objectname)")   $(egrep commit all | cut -d ' ' -f 3)

Checking object directories: 100% (256/256), done.

Checking objects: 100% (542/542), done.

unreachable blob 6900c6418b5df26f6471b7d4853822d99fcf2534

unreachable blob 945019391229d1304b47c7d1dc112ff45bbca360

unreachable blob 0ed3acde384de116f4b194bfd226055074a9f52d

unreachable blob c0234fc886423ff40a96b4c3e7ba67a4deb944c0

unreachable blob c9754aed2e981cdf678159ab41f7bfea89c93cbd

unreachable blob 8168f4a5a91997641211ce0d30b01e8bf8920792

unreachable blob 8c9cc9beddbc89a0ef46a1631265f79551a78e8a

unreachable blob 758e9c59bc04d38bd676c3c98e6d092b698defa4

Your file should be one of those unreachable blob from the above list. To verify that, do git show for every blob and see.

$ git show 6900c6418b5df26f6471b7d4853822d99fcf2534

Resources:

http://stackoverflow.com/questions/7374069/undo-git-reset-hard-with-uncommitted-files-in-the-staging-area

Merging multiple commits into a single commit which are already pushed into a central repository

If you're merging local commits:

http://exploreeclipse.blogspot.sg/2012/11/git-squash-all-commits-into-single.html

If the code is already pushed into a central repository and having multiple commits for a single fix/feature, now you wanted to merge couple commits into a single commit to make the git history clear.

Step 1: Identify how many last commits you wanted to merge ?

$ git reflog

4585fc6 HEAD@{0}: commit: fixig build scripts

c10447a HEAD@{1}: commit: fixing build issues

baa56c0 HEAD@{2}: commit: Using forked repo for testing

f744eec HEAD@{3}: commit: Missing tag

c30816d HEAD@{4}: commit: Missing tag

ea302be HEAD@{5}: commit: Removing bin folder

6560cb9 HEAD@{6}: commit: Build files and studio plugins folder structure

4540830 HEAD@{7}: clone: from https://github.com/kolipakakondal/studio_app.git

From above, I wanted to merge from HEAD@{0} to HEAD@{6} - That basically last 7 commits

Step 2: Rebase interactively

$ git rebase -i origin/master~7 master

Step 3:  Push the changes forcefully to a central repo

$ git push origin +master

Git: Reverting multiple bad commits which are already pushed to a central repository

Here is the case:

I pushed multiple bad commits into a central repository and now I wanted to roll back all of them.

Step1 : check git log and identify your last good commit or till where you wanted to roll back.

$ git log --oneline

5ff2aee commit1 - bad commit

8516637 commit2- bad commit

64db1b7 commit3 - bad commit

6897d4b commit4 - bad commit

6974cb5 commit5 - this is my last good commit

79e63c6 commit6

6cd2939 commit7

d39ae18 commit8

Step2: Do reset hard till your last good commit.

$ git reset --hard 6974cb5

Step3: verify git log

$ git log --oneline

6974cb5 commit5 - this is my last good commit

79e63c6 commit6

6cd2939 commit7

d39ae18 commit8

Step 4: Do force push to central repo

$ git push origin <master repo> -f

How to merge the changes from your development branch to master/release branch

$ git checkout development

$ git merge -s ours release  //merge release into development and discard any changes on release branch

$ git checkout release

 $git merge development

Note: Very important point here is, we are completely discarding the changes which are made in release branch. Here we will just bring all the changes from development branch to release branch without having conflicts. If any conflicts during the merge it will take development changes and ignore the release changes if any.

This merge strategy can be used ONLY when you are sure that release branch does not have any additional git commits compared to development branch. 

If release branch is having specific commits and which are not there in development branch, then it's better to go always with the default merge strategy.

$ git checkout release
$ git merge development

Resolve any conflicts if any and commit it.

Undo a git rebase

Step 1: Identify the head commit of the branch till where you wanted to undo it.

$ git reflog

5621e87 HEAD@{0}: checkout: moving from TISTUD-7562 to development

7747926 HEAD@{1}: rebase -i (finish): returning to refs/heads/TISTUD-7562

7747926 HEAD@{2}: rebase -i (squash): TISTUD-7562:For limited plan billing is not opened via wizard

2101ed5 HEAD@{3}: rebase -i (start): checkout 5621e87fac883fca1783bb2f1b6f811422bdf289

0975830 HEAD@{4}: rebase: aborting

0975830 HEAD@{5}: reset: moving to HEAD@{1}

2101ed5 HEAD@{6}: rebase -i (start): checkout 5621e87fac883fca1783bb2f1b6f811422bdf289

0975830 HEAD@{7}: commit: TISTUD-7562:Avoiding multiple validations during the package launch actions from package explorer and app explorer.

2101ed5 HEAD@{8}: rebase finished: returning to refs/heads/TISTUD-7562

2101ed5 HEAD@{9}: rebase: TISTUD-7562:For limited plan billing is not opened via wizard

Here, I wanted to undo till HEAD@{7}

Step 2: Reset to required commit

$ git reset --hard HEAD@{7}

This will bring back all the changes which you are having at HEAD@{7} commit.

Chaning git remote tracking repository or url

Here is the example.

$ git remote -v
origin  https://github.com/kolipakakondal/titanium_studio.git (fetch)
origin  https://github.com/kolipakakondal/titanium_studio.git (push)
upstream        https://github.com/appcelerator/titanium_studio_360.git (fetch)
upstream        https://github.com/appcelerator/titanium_studio_360.git (push)

Currently my 'upstream' branch is pointing to a wrong remote url, and I wanted to change it.

$ git remote set-url upstream https://github.com/appcelerator/titanium_studio.git
$ git remote -vorigin  https://github.com/kolipakakondal/titanium_studio.git (fetch)
origin  https://github.com/kolipakakondal/titanium_studio.git (push)
upstream        https://github.com/appcelerator/titanium_studio.git (fetch)
upstream        https://github.com/appcelerator/titanium_studio.git (push)

How to rebase your pull request

But, why ?

Your pull request(PR) might be pretty old and in mean time many people would have changed the same code. So you can't simply merge your PR into master branch because of the conflicts.

Step 1:
Fetch the latest code from remote master branch.
> git fetch upstream

here upstream is pointing to a remote repository.

Step 2:
If you have multiple commits, it's better to squash them. But it's an optional step.
>git merge-base <yourforkedbranch> <mainremotebranch>
Example: git merge-base TISTUD-9000 release

This will give the hash-id.
>git rebase --interactive <hash-id>

It will list down the commits, If you have more than one, you can replace 'pick' by 'squash' for commits expect first one.
Example:
pick 4455 
squash 5555
squash 85858

Step 3:
Run rebase command
>git rebase upstream/master

For sure, this will fail because of the conflicts. I mean, that's the main reason why we wanted to go for rebase here.

And once you resolve the conflicts continue with the rebase --continue.

Step 4: 
Update the pull request forcefully
>git push -f

or
> git push origin <yourbranch> -f

This is the crystal clear resource which will talk about this.

https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request

Git:Checkout to newly added remote branch

For example, If new branch is added to the repository and now you wanted to setup that in your local system.

$ git fetch

This will look up the origin and update the local repository with the new data.

For example, newly added branch is 'master'. It will show something like this.
master->origin/master

$ git branch -r

Above command tell you what are all the remote branches available.

$git checkout -b master origin/master

This will create a new branch 'master' and will have a synch with remote branch /origin/master'

KKOLIPAKA-MBP:$ git fetch

From https://github.com/kolipakakondal/titanium_studio

 * [new branch]      master -> origin/master

KKOLIPAKA-MBP:$ git branch -r

  origin/HEAD -> origin/development

  origin/development

  origin/master

  upstream/release

KKOLIPAKA-MBP:$ git checkout -b master origin/master

Checking out files: 100% (453/453), done.

Branch master set up to track remote branch master from origin.

Switched to a new branch 'master'

Git: Updating a forked repository from the original repository

Let's take a scenario:

This is the remote repository: https://github.com/apache/mystudio.git

Your forked repository from the above:  https://github.com/kolipakakondal/mystudio.git

'development' is the branch name both in remote and forked repository.

1. Add remote repository to forked repository

>git remote add upstream https://github.com/apache/mystudio.git

2.  Fetch from remote repository .i.e upstream

> git fetch upstream

3. Rest your branch(ex: development) to the remote branch(ex: development)

> git reset --hard upstream/development

4. Pushed changes which we got it form remote repo to remote forked repo.

> git push origin  development --force

Pulling your co-worker forked remote branch

> git remote add coworker https://github.com/coworker/studiorepo.git
> git fetch coworker
> git checkout --track coworker/foo

This will setup a local branch foo, tracking the remote branch coworker/foo. So when your coworker has made some changes, you can easily pull them.


> git pull

> git checkout foo

This will pull the latest changes. This is especially required when you wanted to pull the code and review it directly without really disturbing own repo. This will avoid setting up one more repository as well.

Conventions for naming git branches for your development

Some practices which I follow for naming git branches.

If you are working on sprint/agile development, you might have planned certain activities for each sprint.

let's say, every sprint development is for 1 month,so for every sprint we can maintain different branches as mentioned below.

Example: In Development mode
Sprint 1  =>  Branch name: dev-1.0.1

here, dev-<Major version>.<Minor version>.<Sprint version>

While handing over your work to QA team, we can promote this branch to QA branch.

Example: In QA mode
dev-1.0.1 will become qa-1.0.1

If you are providing builds one top of dev branches.
Example: For sprint 1 on dev branch
com.kk.product_dev-1.0.1.0.jar

Here, <pluginname>_<<branch name>.<build number>>.jar

on QA builds generation,
com.kk.product_qa-1.0.1.0.jar

If many people are working on sprint on various features, then we can create a different branch for each feature(ex: dev-1.0.1_explorer), once the feature is stabilized then we can merge this with the main sprint branch i.e dev-1.0.1

git pull failed with file too long issue

Run below command to avoid the issue.

$ git config core.longpaths true