GIT Guidelines and Help

Table of Contents
● Branch creation
● Branch update
● Branch delete
● Branch rename
● Branch rebase
● Branch resetgit status
● Undoing changes to a file
● Amending a commit
● Reverting a commit
● Resetting a commit
● Stashing changes
● Interactive rebase
● Squash commits together
● Pull Requests

Branch creation
For any code or documentation changes, you will have to create a new branch. Before creating the
new branch always get the latest version from remote using these commands:

Make sure you are on the development branch, if not run:

git checkout development

Update the development branch using:

git pull

This will automatically fetch the latest version and merge into your local one, unless you have any
conflicts in which case it will take you into a merge.

Now that you have the latest version you can go ahead and create your local branch:

git checkout -b tag/short-branch-name

Using the -b parameter you switch automatically to the newly created branch.
The used tags will be:

● bugfix
● feature
● refactor
● doc
● test

The branch name has to be all lowercase!

Branch update
To check the status of your local branch for uncommitted changes type:

git status

To add all the files in the commit type:

git add .

To add a specific file in the commit type:

git add <filename>

After you checked all the correct files are added you can commit:

git commit -m "Short description of what has been done"

Remember: All commits are local!

After you made all the commits and are ready to push type:

git push

Note: If you're branch does not exist yet on the remote you will have to type:

git push --set-upstream origin tag/your-branch-name

Important: If you need to check if your branch is up to date with the development branch type:
 git fetch origin
git log HEAD..origin/development --oneline

If you have any lines returned it means your branch is behind and you should rebase onto
development.
For details on how to rebase go to Go to Branch Rebase.

Branch delete
IMPORTANT: Only the repository administrator is allowed to Delete remote branches.

Delete the local branch:

git branch # Will display all the local branches you have
git branch -d tag/branch-name # Will delete the local branch

Note:

1. You cannot delete the branch you are currently on.

2. You can use -D (uppercase D) instead, to force deletion without checking merged status.

Delete the remote branch from the server:

git push origin :[name_of_your_branch]

Branch rename
To rename your local branch:

If you are on the branch you want to rename, do:

git branch -m [new-name]

If you are on a different branch use:

git branch -m [old-name] [new-name]

To rename the remote branch also, you need to:

1.Delete the [old-name] remote branch and the [new-name] local branch.
 git push origin :[old-name] [new-name]

2.Reset the upstream branch for the [new-name] local branch. Switch to the branch and then:

git push origin -u [new-name]

Branch rebase
Important: The rebase process will create by default a backup file, to remove this option type:

git config --global mergetool.keepBackup false

Important: Open Visual Studio and go to Team Explorer, click on Settings and under Git section
select Repository Settings. Here you have to set the Diff & Merge Tools to use Visual Studio.

Sometimes you will need to rebase your branch in case there were new commits to the
development branch.
This practice will save you from having conflicts when you try to merge the branches.

To rebase your local branch, make sure you are on your local branch that needs rebasing and type:

git fetch origin # This will get the latest version from remote
git rebase origin/development # This will start the rebase process

If there are any conflicts you will be prompted to fix those.

To fix the conflicts open the merge tool by typing:

git mergetool # You will be prompted to hit enter to continue

Visual Studio will open with both remote and local changes, fix all conflicts and click on Accept
Merge

If there are more files conflicting type:

git rebase --continue

When you are done fixing all the conflicts, and the branch you are currently on does not have
appended ( eg."Rebase 1/3") you can push the changes to the remote by forcing the push:
 git push -f # This will force the push

Branch reset
In some cases you might want to reset all your branch changes. To reset your branch type:

git reset --hard # This will wipe out all the modifications made to the branch

To clean any unstagged files:

git clean -df

Undoing changes to a file

To remove files from the commit:

git checkout -- . # For all files

git checkout -- <filename> # For specific file

This will revert the file back to what it looked like when you last committed (or initially cloned);

git reset HEAD <filename>

This will unstage the file and will keep the changes made to the file on your local branch. If you run
git status it will show you that the file is modified but once again unstaged.

Amending a commit
If you ever find that you accidentally left something out of your last commit, be it a file or an extra
change to a file that you just committed, it can easily be fixed. You have the ability to edit the most
recent commit, the commit the HEAD points to, by using the ammend option. All you have to do is
stage the extra changes like you would for a normal commit:

git add .

And then just commit with the --amend argument.

git commit --amend

It can also be used to simply edit the previous commit message. If you don't specify a commit
message with -m you will be prompted with the previous commit message as a default.

git commit --amend -m "Message"

After ammend the commit, you can push the changes to the remote by forcing the push:

git push -f # This will force the push

Note: Amending doesn't just alter the most recent commit, it replaces it entirely. To Git, it will look
like a brand new commit.

Reverting a commit
The git revert command undoes a commit, but instead of removing the commit from the project
history, it figures out how to undo the changes introduced by the commit and appends a new
commit with the resulting content. This prevents Git from losing history.

git revert <commit>

Note: This will generate a new commit that undoes all of the changes introduced in <commit>, then
apply it to the current branch.

Important: Reverting should be used when you want to remove an entire commit from your
project history. This can be useful, for example, if you are tracking down a bug and find that it was
introduced by a single commit. Instead of manually going in, fixing it, and committing a new
snapshot, you can use git revert to automatically do all of this for you.

Resetting a commit

git reset

Suppose you have added a file to your index, but later decide you do not want to add it to your
commit. You can remove the file from the index while keeping your changes with git reset. This
removes the file from the index while keeping it in the working directory. This commits all other
changes in the index.

Important: It should only be used to undo local changes — you should never reset commits that
have been shared with other developers.
 git reset <commit>

Used like this, it will move the current branch backward to <commit>, reset the staging area, but
leave the working directory alone. All changes made since <commit> will reside in the working
directory, which lets you re-commit the project history.

git reset --hard

Reset the staging area and the working directory to match the most recent commit. In addition to
unstaging changes, the --hard flag tells Git to overwrite all changes in the working directory, too.
Put another way: this obliterates all uncommitted changes, so make sure you really want to throw
away your local developments before using it.

For example, if you are on branch master with this series of commits:

- A - B - C (master)
HEAD points to C and the index matches C.

When you run:

git reset --soft B OR git reset --soft HEAD~1

master (and thus HEAD) now points to B, but the index still has the changes from C. If you you run
git status, you'll see that the same files are in the index as before. In fact, right after this
command, you could do git commit and you'd be redoing the same commit you just had.

When you run:

git reset --hard B OR git reset --hard HEAD~1

master and HEAD now points to B, and reset both the staging area and the working directory to
match. This means that the changes added in C, as well as any uncommitted changes you have, will
be removed, and the files in your working copy will match commit B. Since you can permanently
lose changes this way, you should always run git status before doing a hard reset to make sure
your working directory is clean or that you're okay with losing your uncommitted changes.

Suppose you destroy a commit as in the second example, but then discover you needed it after all.
There's still a way to get it back. Type git reflog and you'll see a list of (partial) commit shas that
you've moved around in. Find the commit you destroyed, and do this:

git reflog
 git checkout -b someNewBranchName shaYouDestroyed

You have now rescue that commit. Commits don't actually get destroyed in Git for some 90 days, so
you can usually go back and rescue one you didn't mean to get rid of.

Stashing changes
Stashing takes your modified tracked files and staged changes and saves it on a stack of unfinished
changes that you can reapply at any time. The command saves your local modifications away and
reverts the working directory to match the HEAD commit.

For saving changes in stash, do:

git stash save "message"

The modifications stashed away by this command can be listed with :

git stash list

For inspecting the modifications saved on a stash, you need to:

git stash show stash@{0}

Stashes may be referenced by specifying the stash index (e.g. stash@{0} is the most recently
created stash, stash@{1} is the one before it).

To remove a single stashed state from the stash list and apply it on top of your current work do one
of the following git commands:

git stash pop # Throws away the (topmost, by default) stash after applying it
git stash apply # Leaves it in the stash list for possible later reuse (or you can
then git stash drop it).

Interactive rebase

git rebase -i

git rebase re-applies commits, one by one, in order, from your current branch onto another.
Running git rebase with the -i flag begins an interactive rebasing session. Instead of blindly
moving all of the commits to the new base, interactive rebasing gives you the opportunity to
squash insignificant commits, delete obsolete ones, and make sure everything else is in order
before committing to the official project history.

For example, if you want to change the last three commit messages, or any of the commit
messages in that group, you supply as an argument to git rebase -i the parent of the last commit
you want to edit, which is HEAD~3.

git rebase -i HEAD~3

Running this command gives you a list of commits in your text editor that looks like this:

pick 3b04e50 Second commit: add test files

pick 37681c8 Third commit: change css files
pick d0f26e3 Fourth commit: update README formatting

# Rebase 7aa195b..d0f26e3 onto 7aa195b (3 commands)

#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

The interactive rebase gives you a script that it’s going to run. It will start at the commit you specify
on the command line (HEAD~3) and replay the changes introduced in each of these commits from
top to bottom. It lists the oldest at the top, rather than the newest, because that’s the first one it will
replay.

You need to edit the script so that it stops at the commit you want to edit. To do so, change the
word 'pick' to the word 'edit' for each of the commits you want the script to stop after. For example,
to modify only the third commit message, you change the file to look like this:

edit 3b04e50 Second commit: add new test files

pick 37681c8 Third commit: change css files
pick d0f26e3 Fourth commit: update README formatting
When you save and exit the editor, Git rewinds you back to the last commit in that list and drops
you on the command line instructions which tells you exactly what to do. Type:

git commit --amend

Change the commit message, and exit the editor. Then, run:

git rebase --continue

This command will apply the other two commits automatically, and then you're done. If you change
pick to edit on more lines, you can repeat these steps for each commit you change to edit. Each
time, Git will stop, let you amend the commit, and continue when you're finished.

Squash commits together

It is also possible to take a series of commits and squash them down into a single commit with the
interactive rebasing tool.

First you need to do an interactive rebase in which you pick how many commits you want to squash
and then the script puts helpful instructions in the rebase message. If, instead of 'pick' or 'edit', you
specify 'squash', Git applies both that change and the change directly before it and makes you
merge the commit messages together. So, if you want to make a single commit from these three
commits, you make the script look like this:

pick 3b04e50 Second commit: add test files

squash 37681c8 Third commit: change css files
squash d0f26e3 Fourth commit: update README formatting

Basically this tells Git to combine all three commits into the the first commit in the list. Once this is
done and saved, another editor pops up with the following:

# This is a combination of 3 commits.

# The first commit's message is:

Second commit: add test files

# This is the commit message #2:

Third commit: change css files

# This is the commit message #3:

Fourth commit: update README formatting

# Please enter the commit message for your changes. Lines starting
 # with '#' will be ignored, and an empty message aborts the commit.
#
# Date: Mon Jan 23 14:44:33 2017 +0200
#
# interactive rebase in progress; onto 7aa195b
# Last commands done (3 commands done):
# squash 37681c8 Third commit: change css files
# squash f701197 Fourth commit: updated README formatting
# No commands remaining.
# You are currently rebasing branch 'loredana/new-feature' on '7aa195b'.
#
# Changes to be committed:
# modified: first_file.txt

When you save that, you have a single commit that introduces the changes of all three previous
commits. You can choose what commit messages do you want by commenting the unnecessary
lines with #. Edit the message as you fit, then save and quit. After defining the commit message, the
rebase is complete and you should be able to see the squashed commit in your git log output.

Run the following command to force a push of the new, consolidated commit:

git push -f

Note: The squashed commit has a different ID than either of the original commits, which tells you
that it is indeed a brand new commit.

Pull requests
After you have tested your branch and everything is ok you can create a pull request by opening
the TFS Web Portal. There are two ways of opening it:

1. From Team Explorer click on Web Portal

2. In any browser type: http://mbbdev.connex.ro:8080/tfs select the project -> go to Code -> Pull
requests -> New pull request

If you see any Merge conflicts try fixing them and push again to the same branch.