{{tag>git howto}}
====== Init remote repo with existing code ======
search_me: git howto

  - Get a remote repo (bitbucket/github):  https://thuydang@bitbucket.org/thuydang/vfossorg_pj.git
  - cd \src\root
  - git init
  - git add . 
  - git commit -m 'initial commit comment'
  - git remote add origin https://thuydang@bitbucket.org/thuydang/vfossorg_pj.git
  - git push -u origin master

===== Push all branches =====

    git push --all origin -u

<code>
[dang@dai142 ima-controller]$   git push --all origin -u
X11 forwarding request failed on channel 0
Counting objects: 826, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (486/486), done.
Writing objects: 100% (826/826), 334.97 KiB | 0 bytes/s, done.
Total 826 (delta 221), reused 0 (delta 0)
remote: => Syncing Gitorious... [OK]
To git@git.dai-labor.de:odl_dmm/ima-controller.git
 * [new branch]      master -> master
 * [new branch]      mobility_rc_1 -> mobility_rc_1
Branch master set up to track remote branch master from origin.
Branch mobility_rc_1 set up to track remote branch mobility_rc_1 from origin.
</code>
====== Working with git ======
In general try
    git command --help
    
===== Selectively merge files from one branch into another branch =====
To selectively merge files from one branch into another branch, 
run

    git merge --no-ff --no-commit branchX

where: branchX is the branch you want to merge from into the current branch

The --no-commit option will stage the files that have been merged by Git without actually committing them. This will give you the opportunity to modify the merged files however you want to and then commit them yourself.

Depending on how you want to merge files, there are four cases:

1) You want a true merge. In this case, you accept the merged files the way Git merged them automatically and then commit them.

2) There are some files you don't want to merge. For example, you want to retain the version in the current branch and ignore the version in the branch you are merging from.

To select the version in the current branch, run:

git checkout HEAD file1

This will retrieve the version of file1 in the current branch and overwrite the file automerged by Git.

3) If you want the version in branchX (and not a true merge), run:

git checkout branchX file1

This will retrieve the version of file1 in branchX and overwrite the file auto-merged by Git.

4) The last case is if you want to select only specific merges in file1. In this case, you can edit the modified file1 directly, update it to whatever you'd want the version of file1 to become, and then commit.

If Git cannot merge a file automatically, it will report it as "unmerged" file and produce a copy where you will need to resolve the conflicts manually.

To explain further with an example, let's say you want to merge branchX into the current branch:

git merge --no-ff --no-commit branchX

You then run the git status command to view the status of modified files.

For example:

git status

# On branch master
# Changes to be committed:
#
#       modified:   file1
#       modified:   file2
#       modified:   file3
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#       both modified:      file4
#

Where file1, file2, and file3 are the files git have successfully auto-merged.

What this means is that changes in the master and branchX for all those three files have been combined together without any conflicts.

You can inspect how the merge was done by running the git diff --cached file. For example:

git diff --cached file1
git diff --cached file2
git diff --cached file3

If you find some merge undesirable, you can edit the file directly, save, and then commit.

If you don't want to merge file1 and want to retain the version in the current branch, run:

git checkout HEAD file1

If you don't want to merge file2 and only want the version in branchX, run

git checkout branchX file2

If you want file3 to be merged automatically, don't do anything. Git has already merged it at this point.

file4 above is a failed merge by Git. This means there are changes in both branches that occur on the same line. This is where you will need to resolve the conflicts manually. You can discard the merged done by editing the file directly or running the checkout command for the version in the branch you want file4 to become.

Finally, don't forget to commit.

git commit


===== How to update GitHub forked repository =====
<code>
n your local clone of your forked repository, you can add the original GitHub repository as a "remote". ("Remotes" are like nicknames for the URLs of repositories - origin is one, for example.) Then you can fetch all the branches from that upstream repository, and rebase your work to continue working on the upstream version. In terms of commands that might look like:

# Add the remote, call it "upstream":

git remote add upstream https://github.com/whoever/whatever.git

# Fetch all the branches of that remote into remote-tracking branches,
# such as upstream/master:

git fetch upstream

# Make sure that you're on your master branch:

git checkout master

# Rewrite your master branch so that any commits of yours that
# aren't already in upstream/master are replayed on top of that
# other branch:

git rebase upstream/master

If you don't want to rewrite the history of your master branch, (for example because other people may have cloned it) then you should replace the last command with git merge upstream/master. However, for making further pull requests that are as clean as possible, it's probably better to rebase.

Update: If you've rebased your branch onto upstream/master you may need to force the push in order to push it to your own forked repository on GitHub. You'd do that with:

git push -f origin master

You only need to use the -f the first time after you've rebased.
</code>

===== Delete Remote Branches =====
Step 1: delete local branch
    git branch -d <branchname>
    # force
    git branch -D <branchname>

Step 2: delete remote branch AND tracking branch:
    git push origin --delete branch_name
    
Step Extra: delete tracking branch origin/X:
    git branch --delete --remotes origin/X
    git branch -dr origin/X # Shorter    
    
You can verify that the remote-tracking branch origin/X was also deleted by running the following:

    # View just remote-tracking branches
    git branch --remotes
    git branch -r

    # View both strictly local as well as remote-tracking branches
    git branch --all
    git branch -a
===== gitignore =====
Create file '.gitignore'.

<code>
dir/
dir/file
!.gitignore
</code>

===== move/delete files =====
use 'git rm' 'git mv' or 'rm' 'mv' but always run
<code>
git commit -a -m "housekeeping"
</code>

===== Untrack already commited files =====
    
This command will cause git to untrack your directory and all files under it without actually deleting them:

    git rm -r --cached <your directory>

The -r option causes the removal of all files under your directory.

The --cached option causes the files to only be removed from git's index, not your working copy. By default git rm <file> would delete <file>.

===== Revert =====

    git checkout -- filename
    git checkout v1.2.3 -- filename         # tag v1.2.3
    git checkout stable -- filename         # stable branch
    git checkout origin/master -- filename  # upstream master
    git checkout HEAD -- filename           # the version from the most recent commit
    git checkout HEAD^ -- filename          # the version before the most recent commit
===== Committer =====

Committer: Thuy Dang <td@localhost.localdomain>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:

    git config --global user.name "Your Name"
    git config --global user.email you@example.com

After doing this, you may fix the identity used for this commit with:

    git commit --amend --reset-author

===== origin =====
==== Show remote repos ====
    git remote --verbose

==== Migrate to other git repo ====
  * create other repo.
  * init an empty repo by "git push remote_repo master"
  * then following:

<code>
# In this example, we use an external account named extuser and
# a GitHub account named ghuser to transfer repo.git

git clone --bare https://githost.org/extuser/repo.git# Make a bare clone of the external repo to a local directory

cd repo.git
$ git push --mirror https://github.com/ghuser/repo.git# Push mirror to new GitHub repo

cd ..
$ rm -rf repo.git# Remove temporary local repo
</code>
===== git add =====
Note that empty directories are ignored.

    git add -A stages All
    git add . stages new and modified, without deleted
    git add -u stages modified and deleted, without new

===== Branching, tagging =====
source: http://learn.github.com/p/branching.html

==== View available branches ====
    git branch
    git branch -a
    
==== Create a new branch ==== 
We can use ‘git branch (branchname)’ which will create a branch at the point we’re currently at.

    git branch experiment
 
   
==== Switch to that branch ====
So that the work we do is saved to it instead of the ‘master’ branch, we run the ‘git checkout’ command’

<code>
git checkout experiment
Switched to branch "experiment"

git branch
 *experiment
  master
</code>

==== Push branch to server ====

    git push origin experiment

==== Merge branch ====
Merge a brach with current branch (master).

<code>
git merge experiment
Auto-merging lib/simplegit.rb
Merge made by recursive.
 lib/simplegit.rb |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
</code>

Merge multiple times.

For example, let’s say we switched back to the ‘experiment’ branch, made a few changes, then at some point merged it back into ‘master’ again, making our history look something like this.

==== Delete branch ==== 
When you are done with a branch, say in this case the ‘experiment’ branch, we can simply delete it with ‘git branch -d’

    git branch -d experiment
    
If the branch has not been merged in at some point, in which case deleting the branch would lose changes, Git will not allow you to do it. If you want to lose the changes, simply use the ‘-D’ flag instead - that will force the deletion.

===== Update/pull remote:branch to local:branch =====

source StackOverflow.

===== History =====
==== Rebase to merge / remove history ====
History of commit may contain sensitive data. remove them.

Show all commit:
    git log -v
    commit 1
    commit n
    
Interactively choose what to do with the commit:
    git rebase -i commit_1~8   <---- ~8 numbers of history
    
Then choose action on each commit, e.g., drop, squash

Push this branch overwriting remote:
    git push --force
    git push -f <remote, e.g., orign> <branch>
==== New Git ====
    

    git clone git://example.com/myproject
    cd myproject


Next, look at the local branches in your repository:

    git branch
    * master

But there are other branches hiding in your repository! You can see these using the -a flag:

    git branch -a
    * master
    remotes/origin/HEAD
    remotes/origin/master
    remotes/origin/v1.0-stable
    remotes/origin/experimental

If you just want to take a quick peek at an upstream branch, you can check it out directly:

    git checkout origin/experimental

But if you want to work on that branch, you'll need to create a local tracking branch:

    git checkout -b experimental origin/experimental

and you will see

    Branch experimental set up to track remote branch experimental from origin. Switched to a new branch 'experimental'

That last line throw some people "New branch" - huh? What it really means is a new local branch that gets the branch from the index and creates it locally for you. The previous line is actually more informative as it tells you that the branch is being set up to track the remote branch, which usually means the origin/branch_name branch

Now, if you look at your local branches, this is what you'll see:

    git branch
    * experimental
    master

You can actually track more than one remote repository using git remote.
<code>
$ git remote add win32 git://example.com/users/joe/myproject-win32-port
$ git branch -a
* master
  remotes/origin/HEAD
  remotes/origin/master
  remotes/origin/v1.0-stable
  remotes/origin/experimental
  remotes/win32/master
  remotes/win32/new-widgets
</code>

At this point, things are getting pretty crazy, so run gitk to see what's going on:

    gitk --all &


=== Checkout tag to a new branch ===
    git tag (-l)
    git checkout -b td_up_tagxx tagxx
==== Old git ====

<code>
You have set the upstream of that branch

(see:

    "How do you make an existing git branch track a remote branch?" and
    "Git: Why do I need to do --set-upstream all the time?"
    )

git branch -f --track my_local_branch origin/my_remote_branch
# OR:
$ git branch --set-upstream my_local_branch origin/my_remote_branch

That means your branch is already configured with:

branch.my_local_branch.remote origin
branch.my_local_branch.merge my_remote_branch

Git already has all the necessary informations.
In that case:

# if you weren't already on my_local_branch branch:
git checkout my_local_branch 
# then:
git pull

is enough.

If you hadn't establish that upstream branch relationship when it came to push your 'my_local_branch', then a simple git push -u origin my_local_branch:my_remote_branch would have been enough to push and set the upstream branch.
After that, for the subsequent pulls/pushes, git pull or git push would, again, have been enough.

</code>
===== Sources =====
  * http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging