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 .

  1. git commit -m 'initial commit comment'
  2. git remote add origin https://thuydang@bitbucket.org/thuydang/vfossorg_pj.git
  3. git push -u origin master
  Edit

  Push all branches

  git push –all origin -u

[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.

In general try

  git command --help
  

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

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

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.

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

Create file '.gitignore'.

dir/
dir/file
!.gitignore

use 'git rm' 'git mv' or 'rm' 'mv' but always run

git commit -a -m "housekeeping"

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>.

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: 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

  git remote --verbose

• create other repo.
• init an empty repo by “git push remote_repo master”
• then following:

# 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

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

source: http://learn.github.com/p/branching.html

  git branch
  git branch -a
  

We can use ‘git branch (branchname)’ which will create a branch at the point we’re currently at.

git branch experiment
 
   

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

git checkout experiment
Switched to branch "experiment"

git branch
 *experiment
  master

git push origin experiment

Merge a brach with current branch (master).

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

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.

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.

source StackOverflow.

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>

  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.

$ 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

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

gitk --all &

  git tag (-l)
  git checkout -b td_up_tagxx tagxx

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.

• http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging