Git Notes

This is a post summarizing some common functionalities of Github that I run into often.

  1. create a new repository
  2. squash vs pick (git rebase -i commitxxx)
  3. rebase vs merge
  4. git ignore
  5. git amend
  6. git stash
  7. renaming a remote
  8. branches

In general, I highly recommand this website

https://www.atlassian.com/git/tutorials/

Create a new repository

Approach 1 (start from no git repository)

create a repository online first, and then get the url. Follow a series of commands like “git init, … set remote origin ….” [the series of commands should be displayed online.

then git add everything and push to origin

Approach 2 (start from an existing git repository)

create a repository online first, and then simply set the remote url “git remote set-url origin xxx”

then git add everything and push to origin

Squash versus Pick

My specific use case was that I accidentally added a very big file that I don’t want to upload to the remote repository in commit x. Now, in commit x+1, I try to remove the file. However, the way commits are uploaded, it will still try to upload by performing commit x first.

http://stackoverflow.com/questions/5189560/squash-my-last-x-commits-together-using-git

quote “”

Use git rebase -i  and replace “pick” on the second and subsequent commits with “squash” or “fixup”, as described in the manual.

In this example,  is commit X+1 i.e. parent of the oldest commit you want to squash.

To do this, you first enter the interactive mode as detailed in the following link (-i is the key to interactive)

http://git-scm.com/docs/git-rebase#_interactive_mode

The key is here

If you want to fold two or more commits into one, replace the command “pick” for the second and subsequent commits with “squash” or “fixup”.

rebase vs merge

There is a debate between what should we use when merging updates from a different branch. Merging allows non-destructive

https://www.atlassian.com/git/tutorials/merging-vs-rebasing

merge is a simpler command, but it can result in a messy project history.

rebase gives a cleaner project history, but can be a bit harder to master. It is  also a bad idea to do git rebase on a public branch, as it will diverge the branch history. (Hence, the Golden Rule of git Rebase)

git ignore

https://www.atlassian.com/git/tutorials/inspecting-a-repository/git-status

Setting up a good git ignore file is very important because it can prevent problems of uploading unintended files. For example, .pdf files in latex repositories,

To do this,

simply create a .gitignore file in the root directory of the git repository, and put the pattern in there,

*.pdf in  there, then if you try to do

git add xx.pdf,

you will see

“The following paths are ignored by one of your .gitignore files:

xx.pdf

Use -f if you really want to add them.”

You can find good documentation and a sample git ignore file here

https://help.github.com/articles/ignoring-files/

A typical gitignore file for Latex repository for example is shown here,

*.aux

*.blg

*.bbl

*.*~

*.log

*.pdf

Git Amend

Another technique for rewriting the history of the repository. This one specifically targets modifying the last commit. It is effectually replacing the last commit with the new commit.

This is useful if you realized immediately that you made a mistake in the last commit, added a big file or something. Amend will just cancel out the last commit.

A more comprehensive documentation can be found here

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

git statsh

Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.

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

git remote rename xxx yyy

https://help.github.com/articles/renaming-a-remote/

git branch 

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

-r

To see what branches are available in the remote

To edit a branch locally, you need to track a

http://stackoverflow.com/questions/9537392/git-fetch-remote-branch

git merge branch

git merges branch with the current branch.

UseCase1: This is often useful when there is a “master” branch and “dev” branch. When you want to integrate the latest changes in “master” into “dev”, you would first “git checkout dev” to go into “dev” branch, and then do “git merge master” to merge master into dev.

UseCase2: When you want to apply a hot fix into master branch. You can first create the branch “hotfix” and apply the change to it. Then switch back to master branch, and then do “git merge hotfix” to merge hotfix into master. The full example is shown here

(Notice that the <- error means “after” not “before” in the tutorial above).

https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

git pull

git pull is actually a combination of two commands, “git fetch” and “git merge FETCH_HEAD”.

FETCH_HEAD is the tip of the remote fetch specified.

As a result, when you do “git pull origin master” in “dev” branch, you automatically merged the updates from master into the current branch.

Advertisements
This entry was posted in Tools, Uncategorized and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s