Git SCM Tutorial

How To Use the GitLab

Conclusion

• How To Configure Your User Profile
• How To Manage Users and Groups
• Initialize a Project
• Manage Projects with GitLab

Git SCM Turotial

Git เป็นเครื่องมือที่ได้รับความนิยม ซึ่งมีเครื่องมือหลายอย่างมาช่วยในการทำงาน เช่น Github.com, Gitlab เป็นต้น

ขั้นตอนการเรียนรู้

• เข้าไปที่ http://gitref.org/ เพื่อพิมพ์ตาม และสังเกตแต่ละคำสั่งว่าทำงานอย่างไร

git init

initializes a directory as a Git repository

$ cd konnichiwa
$ ls
 README   hello.rb

This is a project where we are writing examples of the "Hello World" program in every language. So far, we just have Ruby, but hey, it's a start. To start version controlling this with Git, we can simply run git init.

$ git init
 Initialized empty Git repository in /opt/konnichiwa/.git/

Now you can see that there is a .git subdirectory in your project. This is your Git repository where all the data of your project snapshots are stored.

$ ls -a
 .        ..       .git     README   hello.rb

Congratulations, you now have a skeleton Git repository and can start snapshotting your project.

In a nutshell, you use git init to make an existing directory of content into a new Git repository. You can do this in any directory at any time, completely locally.

git clone

copy a git repository so you can add to it

If you need to collaborate with someone on a project, or if you want to get a copy of a project so you can look at or use the code, you will clone it. You simply run the git clone [url] command with the URL of the project you want to copy.

$ git clone git://github.com/schacon/simplegit.git
 Initialized empty Git repository in /private/tmp/simplegit/.git/
 remote: Counting objects: 100, done.
 remote: Compressing objects: 100% (86/86), done.
 remote: Total 100 (delta 35), reused 0 (delta 0)
 Receiving objects: 100% (100/100), 9.51 KiB, done.
 Resolving deltas: 100% (35/35), done.
 $ cd simplegit/
 $ ls
 README   Rakefile lib

This will copy the entire history of that project so you have it locally and it will give you a working directory of the main branch of that project so you can look at the code or start editing it. If you change into the new directory, you can see the .git subdirectory - that is where all the project data is.

$ ls -a
 .        ..       .git     README   Rakefile lib
 $ cd .git
 $ ls
 HEAD        description info        packed-refs
 branches    hooks       logs        refs
 config      index       objects

By default, Git will create a directory that is the same name as the project in the URL you give it - basically whatever is after the last slash of the URL. If you want something different, you can just put it at the end of the command, after the URL.

In a nutshell, you use git clone to get a local copy of a Git repository so you can look at it or start modifying it.

Basic Snapshotting

In a nutshell, you will use git add to start tracking new files and also to stage changes to already tracked files, then git status and git diff to see what has been modified and staged and finally git commit to record your snapshot into your history. This will be the basic workflow that you use most of the time.

git add

Going back to our Hello World example, once we've initiated the project, we would now start adding our files to it and we would do that with git add. We can use git status to see what the state of our project is.

$ git status -s  
 ?? README
 ?? hello.rb

So right now we have two untracked files. We can now add them.

$ git add README hello.rb

Now if we run git status again, we'll see that they've been added.

$ git status -s
 A  README
 A  hello.rb

It is also common to recursively add all files in a new project by specifying the current working directory like this: git add .. Since Git will recursively add all files under a directory you give it, if you give it the current working directory, it will simply start tracking every file there. In this case, a git add . would have done the same thing as a git add README hello.rb , or for that matter so would git add *, but that's only because we don't have subdirectories which the * would not recurse into.

OK, so now if we edit one of these files and run git status again, we will see something odd.

$ vim README
$ git status -s
 AM README
 A  hello.rb

The 'AM' status means that the file has been modified on disk since we last added it. This means that if we commit our snapshot right now, we will be recording the version of the file when we last ran git add, not the version that is on our disk. Git does not assume that what the file looks like on disk is necessarily what you want to snapshot - you have to tell Git with the git add command.

In a nutshell, you run git add on a file when you want to include whatever changes you've made to it in your next commit snapshot. Anything you've changed that is not added will not be included - this means you can craft your snapshots with a bit more precision than most other SCM systems.

For a very interesting example of using this flexibility to stage only parts of modified files at a time, see the '-p' option to git add in the Pro Git book.

git status

view the status of your files in the working directory and staging area

As you saw in the git add section, in order to see what the status of your staging area is compared to the code in your working directory, you can run the git status command. Using the -s option will give you short output. Without that flag, the git status command will give you more context and hints. Here is the same status output with and without the -s. The short output looks like this:

$ git status -s
 AM README
 A  hello.rb

Where the same status with the long output looks like this:

$ git status
 # On branch master
 #
 # Initial commit
 #
 # Changes to be committed:
 #   (use "git rm --cached <file>..." to unstage)
 #
 # new file:   README
 # new file:   hello.rb
 #
 # Changed but not updated:
 #   (use "git add <file>..." to update what will be committed)
 #   (use "git checkout -- <file>..." to discard changes in working directory)
 #
 # modified:   README
 #

You can easily see how much more compact the short output is, but the long output has useful tips and hints as to what commands you may want to use next.

Git will also tell you about files that were deleted since your last commit or files that were modified or staged since your last commit.

$ git status -s
 M  README
 D hello.rb

You can see there are two columns in the short status output. The first column is for the staging area, the second is for the working directory. So for example, if you have the README file staged and then you modify it again without running git add a second time, you'll see this:

$ git status -s
 MM README
 D hello.rb

In a nutshell, you run git status to see if anything has been modified and/or staged since your last commit so you can decide if you want to commit a new snapshot and what will be recorded in it.

git diff shows diff of what is staged and what is modified but unstaged

There are two main uses of the git diff command. One use we will describe here, the other we will describe later in the "Inspection and Comparison" section. The way we're going to use it here is to describe the changes that are staged or modified on disk but unstaged. git diff show diff of unstaged changes

Without any extra arguments, a simple git diff will display in unified diff format (a patch) what code or content you've changed in your project since the last commit that are not yet staged for the next commit snapshot.

$ vim hello.rb
$ git status -s
 M hello.rb
$ git diff
 diff --git a/hello.rb b/hello.rb
 index d62ac43..8d15d50 100644
 --- a/hello.rb
 +++ b/hello.rb
 @@ -1,7 +1,7 @@
 class HelloWorld
  def self.hello
 -    puts "hello world"
 +    puts "hola mundo"
  end
 end

So where git status will show you what files have changed and/or been staged since your last commit, git diff will show you what those changes actually are, line by line. It's generally a good follow-up command to git status git diff --cached show diff of staged changes

The git diff --cached command will show you what contents have been staged. That is, this will show you the changes that will currently go into the next commit snapshot. So, if you were to stage the change to hello.rb in the example above, git diff by itself won't show you any output because it will only show you what is not yet staged.

$ git status -s
 M hello.rb
$ git add hello.rb 
$ git status -s
 M  hello.rb
$ git diff
$ 

If you want to see the staged changes, you can run git diff --cached instead.

$ git status -s
 M  hello.rb
$ git diff
$ 
$ git diff --cached
 diff --git a/hello.rb b/hello.rb
 index d62ac43..8d15d50 100644
 --- a/hello.rb
 +++ b/hello.rb
 @@ -1,7 +1,7 @@
 class HelloWorld
  def self.hello
 -    puts "hello world"
 +    puts "hola mundo"
  end
 end

git diff HEAD show diff of all staged or unstaged changes

If you want to see both staged and unstaged changes together, you can run git diff HEAD - this basically means you want to see the difference between your working directory and the last commit, ignoring the staging area. If we make another change to our hello.rb file then we'll have some changes staged and some changes unstaged. Here are what all three diff commands will show you:

$ vim hello.rb 
$ git diff
 diff --git a/hello.rb b/hello.rb
 index 4f40006..2ae9ba4 100644
 --- a/hello.rb
 +++ b/hello.rb
 @@ -1,7 +1,7 @@
 class HelloWorld
 +  # says hello
 def self.hello
    puts "hola mundo"
   end
 end
$ git diff --cached
 diff --git a/hello.rb b/hello.rb
 index 2aabb6e..4f40006 100644
 --- a/hello.rb
 +++ b/hello.rb
 @@ -1,7 +1,7 @@
 class HelloWorld
 def self.hello
 -    puts "hello world"
 +    puts "hola mundo"
  end
 end
$ git diff HEAD
 diff --git a/hello.rb b/hello.rb
 index 2aabb6e..2ae9ba4 100644
 --- a/hello.rb
 +++ b/hello.rb
 @@ -1,7 +1,8 @@
 class HelloWorld
 +  # says hello
 def self.hello
 -    puts "hello world"
 +    puts "hola mundo"
  end
 end

git diff --stat show summary of changes instead of a full diff

If we don't want the full diff output, but we want more than the git status output, we can use the --stat option, which will give us a summary of changes instead. Here is the same example as above, but using the --stat option instead.

$ git status -s
 MM hello.rb
$ git diff --stat
 hello.rb |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
$ git diff --cached --stat
 hello.rb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
$ git diff HEAD --stat
 hello.rb |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

You can also provide a file path at the end of any of these options to limit the diff output to a specific file or subdirectory.

In a nutshell, you run git diff to see details of the git status command - how files have been modified or staged on a line by line basis.

git commit

records a snapshot of the staging area

Now that you have staged the content you want to snapshot with the git add command, you run git commit to actually record the snapshot. Git records your name and email address with every commit you make, so the first step is to tell Git what these are.

$ git config --global user.name 'Your Name'
$ git config --global user.email you@somedomain.com

Let's stage and commit all the changes to our hello.rb file. In this first example, we'll use the -m option to provide the commit message on the command line.

$ git add hello.rb 
$ git status -s
 M  hello.rb
$ git commit -m 'my hola mundo changes'
 [master 68aa034] my hola mundo changes
 1 files changed, 2 insertions(+), 1 deletions(-)

Now we have recorded the snapshot. If we run git status again, we will see that we have a "clean working directory", which means that we have not made any changes since our last commit - there is no un-snapshotted work in our checkout.

$ git status
 # On branch master
 nothing to commit (working directory clean)

If you leave off the -m option, Git will try to open a text editor for you to write your commit message. In vim, which it will default to if it can find nothing else in your settings, the screen might look something like this:

 # Please enter the commit message for your changes. Lines starting
 # with '#' will be ignored, and an empty message aborts the commit.
 # On branch master
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 # modified:   hello.rb
 #
 ~
 ~
 ".git/COMMIT_EDITMSG" 9L, 257C

At this point you add your actual commit message at the top of the document. Any lines starting with '#' will be ignored - Git will put the output of the git status command in there for you as a reminder of what you have modified and staged.

In general, it's very important to write a good commit message. For open source projects, it's generally a rule to write your message more or less in this format:

Short (50 chars or less) summary of changes

More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); some git tools can get confused if you run the two together.

Further paragraphs come after blank lines.

 - Bullet points are okay, too
 - Typically a hyphen or asterisk is used for the bullet, preceded by a
  single space, with blank lines in between, but conventions vary
  here
 # Please enter the commit message for your changes. Lines starting
 # with '#' will be ignored, and an empty message aborts the commit.
 # On branch master
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 # modified:   hello.rb
 #
 ~
 ~
 ~
 ".git/COMMIT_EDITMSG" 25L, 884C written

The commit message is very important. Since much of the power of Git is this flexibility in carefully crafting commits locally and then sharing them later, it is very powerful to be able to write three or four commits of logically separate changes so that your work may be more easily peer reviewed. Since there is a separation between committing and pushing those changes, do take the time to make it easier for the people you are working with to see what you've done by putting each logically separate change in a separate commit with a nice commit message so it is easier for them to see what you are doing and why.

git commit -a automatically stage all tracked, modified files before the commit

If you think the git add stage of the workflow is too cumbersome, Git allows you to skip that part with the -a option. This basically tells Git to run git add on any file that is "tracked" - that is, any file that was in your last commit and has been modified. This allows you to do a more Subversion style workflow if you want, simply editing files and then running git commit -a when you want to snapshot everything that has been changed. You still need to run git add to start tracking new files, though, just like Subversion.

$ vim hello.rb
$ git status -s
 M  hello.rb
$ git commit -m 'changes to hello file'
 # On branch master
 # Changed but not updated:
 #   (use "git add <file>..." to update what will be committed)
 #   (use "git checkout -- <file>..." to discard changes in working directory)
 #
 # modified:   hello.rb
 #
 no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -am 'changes to hello file'
 [master 78b2670] changes to hello file
 1 files changed, 2 insertions(+), 1 deletions(-)

Notice how if you don't stage any changes and then run git commit, Git will simply give you the output of the git status command, reminding you that nothing is staged. The important part of that message has been highlighted, saying that nothing is added to be committed. If you use -a, it will add and commit everything at once.

This now lets you complete the entire snapshotting workflow - you make changes to your files, then use git add to stage files you want to change, git status and git diff to see what you've changed, and then finally git commit to actually record the snapshot forever.

In a nutshell, you run git commit to record the snapshot of your staged content. This snapshot can then be compared, shared and reverted to if you need to.

git reset

undo changes and commits

git reset is probably the most confusing command written by humans, but it can be very useful once you get the hang of it. There are three specific invocations of it that are generally helpful. git reset HEAD unstage files from index and reset pointer to HEAD

First, you can use it to unstage something that has been accidentally staged. Let's say that you have modified two files and want to record them into two different commits. You should stage and commit one, then stage and commit the other. If you accidentally stage both of them, how do you un-stage one? You do it with git reset HEAD -- file. Technically you don't have to add the -- - it is used to tell Git when you have stopped listing options and are now listing file paths, but it's probably good to get into the habit of using it to separate options from paths even if you don't need to.

Let's see what it looks like to unstage something. Here we have two files that have been modified since our last commit. We will stage both, then unstage one of them.

$ git status -s
M README
M hello.rb
$ git add .
$ git status -s
M  README
M  hello.rb
$ git reset HEAD -- hello.rb 
Unstaged changes after reset:
M hello.rb
$ git status -s
M  README
M hello.rb

Now you can run a git commit which will just record the changes to the README file, not the now unstaged hello.rb.

In case you're curious, what it's actually doing here is it is resetting the checksum of the entry for that file in the "index" to be what it was in the last commit. Since git add checksums a file and adds it to the "index", git reset HEAD overwrites that with what it was before, thereby effectively unstaging it.

If you want to be able to just run git unstage, you can easily setup an alias in Git. Just run git config --global alias.unstage "reset HEAD". Once you have run that, you can then just run git unstage [file] instead.

If you forget the command to unstage something, Git is helpful in reminding you in the output of the normal git status command. For example, if you run git status without the -s when you have staged files, it will tell you how to unstage them:

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   README
#   modified:   hello.rb
#

When you run git reset without specifying a flag it defaults to --mixed. The other options are --soft and --hard. git reset --soft moves HEAD to specified commit reference, index and staging are untouched

The first thing git reset does is undo the last commit and put the files back onto the stage. If you include the --soft flag this is where it stops. For example, if you run git reset --soft HEAD~ (the parent of the HEAD) the last commit will be undone and the files touched will be back on the stage again.

$ git status -s
M  hello.rb
$ git commit -am 'hello with a flower'
[master 5857ac1] hello with a flower
1 files changed, 3 insertions(+), 1 deletions(-)
$ git status
# On branch master
nothing to commit (working directory clean)
$ git reset --soft HEAD~
$ git status -s
M  hello.rb

This is basically doing the same thing as git commit --amend, allowing you to do more work before you roll in the file changes into the same commit. git reset --hard unstage files AND undo any changes in the working directory since last commit

The third option is to go --hard. This command discards your staged changes and the changes in your working directory. In other words: it resets your staging area and working directory to the state they were in at the given commit. This is the most dangerous option and is not working directory safe. Any changes not committed will be lost.

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# modified:   README
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified:   README
#
$ git reset --hard HEAD
HEAD is now at 5857ac1 hello with a flower
$ git status
# On branch master
nothing to commit (working directory clean)

In the above example, while we had both changes ready to commit and ready to stage, a git reset --hard wiped them out. The working tree and staging area are reset to the tip of the current branch or HEAD.

You can replace HEAD with a commit SHA-1 or another parent reference to reset to that specific point.

In a nutshell, you run git reset HEAD to undo the last commit, unstage files that you previously ran git add on and wish to not include in the next commit snapshot

git rm

remove files from the staging area

git rm will remove entries from the staging area. This is a bit different from git reset HEAD which "unstages" files. To "unstage" means it reverts the staging area to what was there before we started modifying things. git rm on the other hand just kicks the file off the stage entirely, so that it's not included in the next commit snapshot, thereby effectively deleting it.

By default, a git rm file will remove the file from the staging area entirely and also off your disk (the working directory). To leave the file in the working directory, you can use git rm --cached.

git mv git rm --cached orig; mv orig new; git add new

Unlike most other version control systems, Git does not track file renames. Instead, it just tracks the snapshots and then figures out what files were likely renamed by comparing snapshots. If a file was removed from one snapshot and another file was added to the next one and the contents are similar, Git figures it was most likely a rename. So, although the git mv command exists, it is superfluous - all it does is a git rm --cached, moves the file on disk, then runs a git add on the new file. You don't really need to use it, but if it's easier, feel free.

In its normal form the command is used to delete files. But it's often easier to just remove the files off your disk and then run git commit -a, which will also automatically remove them from your index.

In a nutshell, you run git rm to remove files from being tracked in Git. It will also remove them from your working directory.

git stash

save changes made in the current index and working directory for later

You're in the middle of some changes but something comes up that you need to jump over to, like a so-urgent-right-now bugfix, but don't want to commit or lose your current edits. git stash is there for you.

git stash add current changes to the stack

Stashing takes the current state of the working directory and index, puts it on a stack for later, and gives you back a clean working directory. It will then leave you at the state of the last commit.

If you have untracked files, git stash will not include them. You can either stage those files with git add (you don't have to commit) before stashing, or, if you have a recent Git version (1.7.7 or above), you can use git stash -u to also stash also unversioned files.

$ git status -s
M hello.rb
$ git stash
Saved working directory and index state WIP on master: 5857ac1 hello with a flower
HEAD is now at 5857ac1 hello with a flower
$ git status
# On branch master
nothing to commit (working directory clean)
git stash list view stashes currently on the stack

It's helpful to know what you've got stowed on the stash and this is where git stash list comes in. Running this command will display a queue of current stash items.

$ git stash list
stash@{0}: WIP on master: 5857ac1 hello with a flower
The last item added onto the stash will be referenced by stash@{0} and increment those already there by one. 
$ vim hello.rb
$ git commit -am 'it stops raining'
[master ee2d2c6] it stops raining
1 files changed, 1 insertions(+), 1 deletions(-)
$ vim hello.rb
$ git stash
Saved working directory and index state WIP on master: ee2d2c6 it stops raining
HEAD is now at ee2d2c6 it stops raining
$ git stash list
stash@{0}: WIP on master: ee2d2c6 it stops raining
stash@{1}: WIP on master: 5857ac1 hello with a flower

git stash apply grab the item from the stash list and apply to current working directory

When you're ready to continue from where you left off, run the git stash apply command to bring back the saved changes onto the working directory.

$ git stash apply
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified:   hello.rb
#
no changes added to commit (use "git add" and/or "git commit -a")

By default it will reapply the last added stash item to the working directory. This will be the item referenced by stash@{0}. You can grab another stash item instead if you reference it in the arguments list. For example, git stash apply stash@{1} will apply the item referenced by stash@{1}.

If you also want to remove the item from the stack at the same time, use git stash pop instead. git stash drop remove an item from the stash list

When you're done with the stashed item and/or want to remove it from the list, run the git stash drop command. By default this will remove the last added stash item. You can also remove a specific item if you include it as an argument.

In this example, our stash list has at least two items, but we want to get rid of the item added before last, which is referenced by stash@{1}.

$ git stash drop stash@{1}
Dropped stash@{1} (0b1478540189f30fef9804684673907c65865d8f)

If you want to remove of all the stored items, just run the git stash clear command. But only do this if you're sure you're done with the stash. In a nutshell, run git stash to quickly save some changes that you're not ready to commit or save, but want to come back to while you work on something else.

git branch

list, create and manage working contexts

git checkout

switch to a new branch context

The git branch command is a general branch management tool for Git and can do several different things. We'll cover the basic ones that you'll use most - listing branches, creating branches and deleting branches. We will also cover basic git checkout here which switches you between your branches.

git branch list your available branches

Without arguments, git branch will list out the local branches that you have. The branch that you are currently working on will have a star next to it and if you have coloring turned on, will show the current branch in green.

$ git branch
* master

This means that we have a 'master' branch and we are currently on it. When you run git init it will automatically create a 'master' branch for you by default, however there is nothing special about the name - you don't actually have to have a 'master' branch but since it's the default that is created, most projects do.

git branch (branchname) create a new branch

So let's start by creating a new branch and switching to it. You can do that by running git branch (branchname).

$ git branch testing
$ git branch
* master
 testing

Now we can see that we have a new branch. When you create a branch this way it creates the branch at your last commit so if you record some commits at this point and then switch to 'testing', it will revert your working directory context back to when you created the branch in the first place - you can think of it like a bookmark for where you currently are. Let's see this in action - we use git checkout (branch) to switch the branch we're currently on.

$ ls
README   hello.rb
$ echo 'test content' > test.txt
$ echo 'more content' > more.txt
$ git add *.txt
$ git commit -m 'added two files'
[master 8bd6d8b] added two files
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 more.txt
create mode 100644 test.txt
$ ls
README   hello.rb more.txt test.txt
$ git checkout testing
Switched to branch 'testing'
$ ls
README   hello.rb

So now we can see that when we switch to the 'testing' branch, our new files were removed. We could switch back to the 'master' branch and see them re-appear.

$ ls
README   hello.rb
$ git checkout master
Switched to branch 'master'
$ ls
README   hello.rb more.txt test.txt

git branch -v see the last commit on each branch

If we want to see last commits on each branch we can run git branch -v to see them.

$ git branch -v
* master      54b417d fix javascript issue
 development 74c111d modify component.json file
 testing     62a557a update test scripts

git checkout -b (branchname) create and immediately switch to a branch

In most cases you will be wanting to switch to the branch immediately, so you can do work in it and then merging into a branch that only contains stable work (such as 'master') at a later point when the work in your new context branch is stable. You can do this pretty easily with git branch newbranch; git checkout newbranch, but Git gives you a shortcut for this: git checkout -b newbranch.

$ git branch
* master
$ ls
README   hello.rb more.txt test.txt
$ git checkout -b removals
Switched to a new branch 'removals'
$ git rm more.txt 
rm 'more.txt'
$ git rm test.txt 
rm 'test.txt'
$ ls
README   hello.rb
$ git commit -am 'removed useless files'
[removals 8f7c949] removed useless files
2 files changed, 0 insertions(+), 2 deletions(-)
delete mode 100644 more.txt
delete mode 100644 test.txt
$ git checkout master
Switched to branch 'master'
$ ls
README   hello.rb more.txt test.txt

You can see there how we created a branch, removed some of our files while in the context of that branch, then switched back to our main branch and we see the files return. Branching safely isolates work that we do into contexts we can switch between.

If you start on work it is very useful to always start it in a branch (because it's fast and easy to do) and then merge it in and delete the branch when you're done. That way if what you're working on doesn't work out you can easily discard it and if you're forced to switch back to a more stable context your work in progress is easy to put aside and then come back to.

git branch -d (branchname) delete a branch

If we want to delete a branch (such as the 'testing' branch in the previous example, since there is no unique work on it), we can run git branch -d (branch) to remove it.

$ git branch
* master
 testing
$ git branch -d testing
Deleted branch testing (was 78b2670).
$ git branch
* master

git push (remote-name) :(branchname) delete a remote branch

When you're done with a remote branch, whether it's been merged into the remote master or you want to abandon it and sweep it under the rug, you'll issue a git push command with a specially placed colon symbol to remove that branch.

$ git push origin :tidy-cutlery
To git@github.com:octocat/Spoon-Knife.git
- [deleted]         tidy-cutlery

In the above example you've deleted the "tidy-cutlery" branch of the "origin" remote. A way to remember this is to think of the git push remote-name local-branch:remote-branch syntax. This states that you want to push your local branch to match that of the remote. When you remove the local-branch portion you're now matching nothing to the remote, effectively telling the remote branch to become nothing.

Alternatively, you can run git push remote-name --delete branchname which is a wrapper for the colon refspec (a source:destination pair) of deleting a remote branch.

In a nutshell you use git branch to list your current branches, create new branches and delete unnecessary or already merged branches.

git merge

merge a branch context into your current one

Once you have work isolated in a branch, you will eventually want to incorporate it into your main branch. You can merge any branch into your current branch with the git merge command. Let's take as a simple example the 'removals' branch from above. If we create a branch and remove files in it and commit our removals to that branch, it is isolated from our main ('master', in this case) branch. To include those deletions in your 'master' branch, you can just merge in the 'removals' branch.

$ git branch
* master
 removals
$ ls
README   hello.rb more.txt test.txt
$ git merge removals
Updating 8bd6d8b..8f7c949
Fast-forward
more.txt |    1 -
test.txt |    1 -
2 files changed, 0 insertions(+), 2 deletions(-)
delete mode 100644 more.txt
delete mode 100644 test.txt
$ ls
README   hello.rb

more complex merges

Of course, this doesn't just work for simple file additions and deletions. Git will merge file modifications as well - in fact, it's very good at it. For example, let's see what happens when we edit a file in one branch and in another branch we rename it and then edit it and then merge these branches together. Chaos, you say? Let's see.

$ git branch
* master
$ cat hello.rb 
class HelloWorld
 def self.hello
   puts "Hello World"
 end
end
HelloWorld.hello

So first we're going to create a new branch named 'change_class' and switch to it so your class renaming changes are isolated. We're going to change each instance of 'HelloWorld' to 'HiWorld'.

$ git checkout -b change_class
Switched to a new branch 'change_class'
$ vim hello.rb 
$ head -1 hello.rb 
class HiWorld
$ git commit -am 'changed the class name'
[change_class 3467b0a] changed the class name
1 files changed, 2 insertions(+), 4 deletions(-)

So now we've committed the class renaming changes to the 'change_class' branch. To switch back to the 'master' branch the class name will revert to what it was before we switched branches. Here we can change something different (in this case the printed output) and at the same time rename the file from hello.rb to ruby.rb.

$ git checkout master
Switched to branch 'master'
$ git mv hello.rb ruby.rb
$ vim ruby.rb 
$ git diff
diff --git a/ruby.rb b/ruby.rb
index 2aabb6e..bf64b17 100644
--- a/ruby.rb
+++ b/ruby.rb
@@ -1,7 +1,7 @@
class HelloWorld
  def self.hello
-    puts "Hello World"
+    puts "Hello World from Ruby"
  end
end
$ git commit -am 'added from ruby'
[master b7ae93b] added from ruby
1 files changed, 1 insertions(+), 1 deletions(-)
rename hello.rb => ruby.rb (65%)

Now those changes are recorded in the 'master' branch. Notice that the class name is back to 'HelloWorld', not 'HiWorld'. To incorporate the 'HiWorld' change we can just merge in the 'change_class' branch. However, the name of the file has changed since we branched, what will Git do?

$ git branch
 change_class
* master
$ git merge change_class
Renaming hello.rb => ruby.rb
Auto-merging ruby.rb
Merge made by recursive.
ruby.rb |    6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
$ cat ruby.rb
class HiWorld
 def self.hello
   puts "Hello World from Ruby"
 end
end
HiWorld.hello

Well, it will just figure it out. Notice that there are no merge conflicts and the file that had been renamed now has the 'HiWorld' class name change that was done in the other branch. Pretty cool.

merge conflicts

So, Git merges are magical, we never ever have to deal with merge conflicts again, right? Not quite. In situations where the same block of code is edited in different branches there is no way for a computer to figure it out, so it's up to us. Let's see another example of changing the same line in two branches.

$ git branch
* master
$ git checkout -b fix_readme
Switched to a new branch 'fix_readme'
$ vim README 
$ git commit -am 'fixed readme title'
[fix_readme 3ac015d] fixed readme title
1 files changed, 1 insertions(+), 1 deletions(-)

Now we have committed a change to one line in our README file in a branch. Now let's change the same line in a different way back on our 'master' branch.

$ git checkout master
Switched to branch 'master'
$ vim README 
$ git commit -am 'fixed readme title differently'
[master 3cbb6aa] fixed readme title differently
1 files changed, 1 insertions(+), 1 deletions(-)

Now is the fun part - we will merge the first branch into our master branch, causing a merge conflict.

$ git merge fix_readme
Auto-merging README
CONFLICT (content): Merge conflict in README
Automatic merge failed; fix conflicts and then commit the result.
$ cat README 
<<<<<<< HEAD
Many Hello World Examples
=======
Hello World Lang Examples
>>>>>>> fix_readme
This project has examples of hello world in
nearly every programming language.

You can see that Git inserts standard merge conflict markers, much like Subversion, into files when it gets a merge conflict. Now it's up to us to resolve them. We will do it manually here, but check out git mergetool if you want Git to fire up a graphical mergetool (like kdiff3, emerge, p4merge, etc) instead.

$ vim README   # here I'm fixing the conflict
$ git diff
diff --cc README
index 9103e27,69cad1a..0000000
--- a/README
+++ b/README
@@@ -1,4 -1,4 +1,4 @@@
- Many Hello World Examples
-Hello World Lang Examples
++Many Hello World Lang Examples
    This project has examples of hello world in

A cool tip in doing merge conflict resolution in Git is that if you run git diff, it will show you both sides of the conflict and how you've resolved it as shown here. Now it's time to mark the file as resolved. In Git we do that with git add - to tell Git the file has been resolved you have to stage it.

$ git status -s
UU README
$ git add README 
$ git status -s
M  README
$ git commit 
[master 8d585ea] Merge branch 'fix_readme'

And now we've successfully resolved our merge conflict and committed the result.

In a nutshell you use git merge to combine another branch context into your current branch. It automatically figures out how to best combine the different snapshots into a new snapshot with the unique work of both.

git log

show commit history of a branch

สรุปการทำงานคำสั่งของ GitSCM

การสร้างโครงการ

• init
• clone

การทำงานพื้นฐานโดยสรุป

• add
• status
• diff
• commit
• reset
• rm, mv
• stash

การแตกสาขา Brach และการรวม Merge

• branch
• checkout
• merge
• log
• tag

การแบ่งปันและปรับปรุงโครงการ

• fetch, pull
• push
• remote

การตรวจตราและเปรียบเทียบ

• log
• diff