Category: Git

How to Commit in GIT

Commit code (make sure to add files first which need to be committed)

git commit -m <message>

Commit code to previous commit

git commit --amend
E.g.
git commit -m 'sample commit'
git add forgotten-file
git commit --amend

Undo Add

git reset

Undo Commit

Undo git commit (changes get unstaged i.e. after modification, we need to re-add, re-commit)
git reset HEAD~
Undo git commit (changes remain staged i.e. after modification, we need to re-commit only) -- useful when we need to change only commit message
git reset --soft HEAD~
Above commands are like moving commit pointer to 1 back position. In case, we want to undo multiple commits, we can use like below
git reset HEAD~3 -> * Undoes 3 commits (changes get unstaged)
git reset --soft HEAD~3 -> * Undoes 3 commits (changes remain staged)

* The Content stated above is for informational purpose only. Expert Software Team is not responsible if any part of content found meaningless in any manner or condition.

What is Stash in GIT

Clear stash list

git stash clear

Show all stashes

git stash list

Drop a stash

Removes latest stash

git stash drop

Removes given stash name

git stash drop <name-of-stash-to-drop>

* The Content stated above is for informational purpose only. Expert Software Team is not responsible if any part of content found meaningless in any manner or condition.

How to do Undo things done mistakenly in GIT

Remove file added to staging for commit

Undo git add command
git checkout -- <filename>

Discard Changes to added file to staging

git checkout <filename>; i.e. checkout repository's version

Undo last commit

git reset --soft HEAD^
*This command would undo commit, but would keep changes so that we can re-modify and re-commit

Undoing GIT Merge (Not pushed yet)

With git log check which commit is one prior the merge. Then you can reset it using:

1. git log --oneline -n 2
2. git reset --hard <commit_sha_previous_to_merged_one>
OR
git reset --hard HEAD~1

* The Content stated above is for informational purpose only. Expert Software Team is not responsible if any part of content found meaningless in any manner or condition.

How to know the status of files Addition and Deletion in GIT

Status

git status -s

* The Content stated above is for informational purpose only. Expert Software Team is not responsible if any part of content found meaningless in any manner or condition.

How to Delete files from staging area

Delete files

from staging area, local machine, and remote repository

git rm <file-name>

commit now to make changes reflected in local, staging and remote-repository

* The Content stated above is for informational purpose only. Expert Software Team is not responsible if any part of content found meaningless in any manner or condition.

How to Add files to staging area

Add files to staging area

git add <file1> <file2> .... and so on

* The Content stated above is for informational purpose only. Expert Software Team is not responsible if any part of content found meaningless in any manner or condition.

What is GIT ignore

After every update to gitignore, follow below steps (this is useless; if you want just to ignore from git; but still keep in git)

===================================================================================================

First, commit all your changes (required)

# remove first everything

git rm -rf --cached .

# add everything again respecting gitignore file

git add .

git ignore but keep file (USEFUL)

===========================

— you can update local git repository by running following command. In this case a file is being tracked in the origin repo. You can modify it in your local repo and git will never mark it as changed

git update-index --assume-unchanged <file>

* The Content stated above is for informational purpose only. Expert Software Team is not responsible if any part of content found meaningless in any manner or condition.

What is GIT process

We would create two main branches for lifetime:

master branch would always have production-ready kind of code for automation framework i.e. It should have only that code pushed which can be used by any team and is tested already by us. It should have latest test suites as well. Any push needs to be followed by tag like a release (e.g. 1.0 – post-ad implemented). Remember to update README.md file in this always for any push.

develop branch originated from master branch only for first time. Later it would always contain latest delivered automation framework/suites/features change for next release to master branch i.e. When source code in develop branch reaches a stable point and is ready to be release, all changes would be merged to master branch (here we said above about tagging with a release number and message). Please NOTE we only merge code to master branch from develop only. Develop branch would also be used for nightly builds in case we followed this path in future.

We would additionally create four branches (as support branches):

features branches:

  • Must originate from develop branch
  • Must merge into develop branch only
  • Must have naming like feature-* (e.g. feature-buy-now, feature-post-ad, feature-login, feature-admin-login, feature-admin-ad-approval etc). Should NOT have any name having any of these 5 words (master, develop, hotfix, release, task)
  • Never delete any feature branch without team agreement. Team agreement would depend on various factors (e.g. feature is completely deprecated and no-longer would come into product.). Considering this case as an example, we may delete feature branch but nothing merged into develop/master branches. In real, we would not delete this branch. Ideally, we would initiate a new branch originated from this feature as deprecated, and automation code/suites would be deprecated and would be merged to develop/master branch.

Creating a feature branch

When we would automate any new feature, we would create a branch from develop branch using below command:

$ git checkout -b feature-post-ad develop
Switched to a new branch "feature-post-ad"
Merging finished feature to develop branch

Once any feature is finished and is tested, we would merge it into the develop branch which could be later added to master branch as an upcoming release:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff feature-post-ad (NOTE: FOR SURE, use --no-ff flag. This flag would perform merge to create a new commit object definitely. We can anyhow perform merge as a fast-forward but we are going to avoid this so that we don't lose any information about historical existence of a feature branch. If we don't use --no-ff, it would be very hard to see from the Git history about which-all commit objects together have implemented a feature. To get that, we would have to manually read all log messages. And, in case, we would like to revert a whole feature, it would become like a real pain. So, please for sure, use --no-ff flag (unless you are more-than-assured that we don't need it)
Updating XXXXX
$ git push origin develop

Deleting a feature branch (Don’t preform this unless team has agreed upon it)

Once automation is complete for any feature and changes have been pushed to develop branch for an upcoming release, we could be in a state for no-longer-required this particular feature branch and can have a decision to delete this. To delete this feature-branch, perform below steps:

$ git checkout develop (NOTE: you should NOT be in that branch; which you are going to delete)
$ git branch -d feature-post-ad
Deleted branch feature-post-ad

tasks branches:

  • Must originate from feature branch
  • Must merge into feature branch only
  • Must have naming like task-* (e.g. task-qe-574, task-ikm-99 etc). Should NOT have any name having any of these 5 words (master, develop, hotfix, release, feature)
  • These branches would always be local to user. In real, there is no need to push these branches to git. In case, some task is critically important, we can push that too in git. So, these branches need to be merged to their respective feature-branch with tag to task-branch-name and unit-tested. Once unit-testing is successful, after merging, in case, user wants, can be deleted from local.

Creating a task branch

When we would automate any new feature/task(or subtask), we would create a branch from feature branch using below command:

$ git checkout -b task-qe-574 feature-post-ad
Switched to a new branch "task-qe-574"
Merging finished task to feature branch

Once any task is finished and is tested, we would merge it into the feature branch which could be later added to develop/master branch as an upcoming release:

$ git checkout feature-post-ad
Switched to branch 'feature-post-ad'
$ git merge --no-ff task-qe-574 (NOTE: FOR SURE, use --no-ff flag. This flag would perform merge to create a new commit object definitely. We can anyhow perform merge as a fast-forward but we are going to avoid this so that we don't lose any information about historical existence of a feature branch. If we don't use --no-ff, it would be very hard to see from the Git history about which-all commit objects together have implemented a feature. To get that, we would have to manually read all log messages. And, in case, we would like to revert a whole feature, it would become like a real pain. So, please for sure, use --no-ff flag (unless you are more-than-assured that we don't need it)
Updating XXXXX
$ git tag -a v1.0 -m "task qe-574 is completed and merged to its feature. task description: BuyNow - Adding an already verified number in accounts created after applying tag must fail"
$ git push origin feature-post-ad

Deleting a task branch

Once automation is complete for any task and changes have been pushed to its feature branch for an upcoming release, we could be in a state for no-longer-required this particular task branch and can delete this. To delete this task-branch, perform below steps:

$ git checkout feature-post-ad (NOTE: you should NOT be in that branch; which you are going to delete)
$ git branch -d task-qe-574
Deleted branch task-qe-574

releases branches: (only required, in case, all code is already merged to develop branch, now before pushing it requires minor changes i.e. an important small defect-fix meta-data changes. E.g. version number, build date, author name, documentation update. This would NOT be required if we don’t have any minor changes to make in code before pushing to master)

  • Must originate from develop branch
  • Must merge into develop or master branch only
  • Must have naming like release-* (e.g. release-1.0, release-1.1, release-2.0.1 etc). Should NOT have any name having any of these 5 words (master, develop, hotfix, feature, task)
  • Never delete any feature branch without team agreement. Team agreement would depend on various factors (e.g. feature is completely deprecated and no-longer would come into product.). Considering this case as an example, we may delete feature branch but nothing merged into develop/master branches. In real, we would not delete this branch. Ideally, we would initiate a new branch originated from this feature as deprecated, and automation code/suites would be deprecated and would be merged to develop/master branch.
  • Ideally, we should not require any of this. Still, in case we need to update some author, version, dates or small-defects-fixes, create this branch from develop branch and once finalized, it would be merged to master. Now, develop branch would pull latest code from master branch. During this branch life, nothing should be merged to develop branch like any new release implementation.

Creating a release branch

A new branch to be created as a branch off to develop branch. (Example scenario is like: Current master branch version is 1.1; a new release needs to pushed now. Assume develop branch is ready to be released with all changes. Now, we are having only decision to make this as version 1.2 or 2.0. So, now we would create a new release branch with a name reflecting that:

$ git checkout -b release-2.0 develop
Switched to release-2.0 branch
$ ./change_file_versions.sh 2.0 (NOTE: this is just a dummy name for a script which would make some changes to file to change their version number)
$ git commit -a -m "Version 2.0 Committed"

Life of this branch

Now, this branch should live by the time, 2.0 is NOT in actual merged to master branch.

So, all bug-fixes, anything with code, would be added to this branch only and not in any feature/develop branch.

NOTE: we are no more going to use any other branch by the time this is released. There should NOT be any major changes included in this branch.

In case, we need to make major changes, delete this branch. Go with feature-branch to make all major changes and repeat cycle for final develop branch and now, in case required, go with release branch again.

Finishing a release branch

When release branch is complete, follow below steps:

-- Switch to master branch
$ git checkout master
-- Merge release branch to master as no-fast-forward
$ git merge --no-ff release-2.0
-- Tag release as 2.0
$ git tag -a 2.0
-- Switch to develop branch
$ git checkout develop
-- Merge new released changes to develop branch as no-fast-forward
$ git merge --no-ff release-2.0
At above command, we can run into any merge conflicts; as we could probably have changes to same files e.g. changed version number of all files. Resolve merge conflicts and commit (remember we are at this time in develop branch)
-- Delete release branch; once merge conflicts are resolved and develop branch is exactly having code as master branch
$ git branch -d release-2.0

hotfix branches: These are EXACTLY same steps as release-branches. Just origination point and final points are changed in these. Below steps to keep in mind for hotfix branches:

  • Must originate from master branch
  • Must merge into master branch only
  • Must merge now master changes to develop branch
  • Must have naming like release-* (e.g. hotfix-1.0, hotfix-1.1, hotfix-2.0.1 etc). Should NOT have any name having any of these 5 words (master, develop, release, feature, task)

* The Content stated above is for informational purpose only. Expert Software Team is not responsible if any part of content found meaningless in any manner or condition.