2020年11月9日 星期一

How to find the nearest parent of a Git branch?

 

git parent

You can just run the command

git parent

to find the parent of the branch, if you add the @Joe Chrysler's answer as a git alias. It will simplify the usage.

Open gitconfig file located at "~/.gitconfig" by using any text editor. ( For linux). And for Windows the ".gitconfig" path is generally located at c:\users\your-user\.gitconfig

vim  ~/.gitconfig

Add the following alias command in the file: 

[alias]
            parent = "!git show-branch | grep '*' | grep -v \"$(git rev-parse --abbrev-ref HEAD)\" | head -n1 | sed 's/.*\\[\\(.*\\)\\].*/\\1/' | sed 's/[\\^~].*//' #"

Save and exit the editor.

Run the command git parent

That's it!


from : https://stackoverflow.com/questions/3161204/how-to-find-the-nearest-parent-of-a-git-branch


FINALLY VERSION:

git show-branch -a \

| grep '\*' \

| grep -v `git rev-parse --abbrev-ref HEAD` \

| head -n1 \

| sed 's/.*\[\(.*\)\].*/\1/' \

| sed 's/[\^~].*//'


parent = "!git show-branch -a | grep '\\*' | grep -v `git rev-parse --abbrev-ref HEAD` | head -n1 | sed 's/.*\\[\\(.*\\)\\].*/\\1/' | sed 's/[\\^~].*//'"


from : https://archive.hankchizljaw.com/notes/24/

2020年9月28日 星期一

Git how to rollback a rebase

 You can use the reflog to find the first action before the rebase started and then reset --hard back to it. e.g.

$ git reflog

b710729 HEAD@{0}: rebase: some commit
5ad7c1c HEAD@{1}: rebase: another commit
deafcbf HEAD@{2}: checkout: moving from master to my-branch
...

$ git reset HEAD@{2} --hard


from : https://stackoverflow.com/questions/41049711/git-how-to-rollback-a-rebase/41049867

2020年8月18日 星期二

How do I rename both a Git local and remote branch name?

Enter image description here


There are a few ways to accomplish that:

  1. Change your local branch and then push your changes
  2. Push the branch to remote with the new name while keeping the original name locally

Renaming local and remote

# Rename the local branch to the new name
git branch -m <old_name> <new_name>

# Delete the old branch on remote - where <remote> is, for example, origin
git push <remote> --delete <old_name>

# Or shorter way to delete remote branch [:]
git push <remote> :<old_name>

# Push the new branch to remote
git push <remote> <new_name>

# Reset the upstream branch for the new_name local branch
git push <remote> -u <new_name>

Enter image description here


Renaming Only remote branch

Credit: ptim

# In this option, we will push the branch to the remote with the new name
# While keeping the local name as is
git push <remote> <remote>/<old_name>:refs/heads/<new_name> :<old_name>

Important note:

When you use the git branch -m (move), Git is also updating your tracking branch with the new name.

git remote rename legacy legacy

git remote rename is trying to update your remote section in your configuration file. It will rename the remote with the given name to the new name, but in your case, it did not find any, so the renaming failed.

But it will not do what you think; it will rename your local configuration remote name and not the remote branch. 


from : https://stackoverflow.com/questions/30590083/how-do-i-rename-both-a-git-local-and-remote-branch-name

2020年5月11日 星期一

Undoing a git rebase

Actually, rebase saves your starting point to ORIG_HEAD so this is usually as simple as:
git reset --hard ORIG_HEAD
However, the resetrebase and merge all save your original HEAD pointer into ORIG_HEAD so, if you've done any of those commands since the rebase you're trying to undo then you'll have to use the reflog.

from : https://stackoverflow.com/questions/134882/undoing-a-git-rebase

2020年4月26日 星期日

Git: 四種將分支與主線同步的方法

四種將分支與主線同步的方法

  • git pull origin master
  • git fetch origin master; git merge origin/master
  • git fetch origin master; git rebase origin/master
  • git fetch origin master; git cherry-pick origin/master
先來做名詞解釋和看一些範例。

名詞解釋

  • master:本地分支名。
  • origin master:origin 表示遠端,master 表示分支名,接在 origin 之後表示是遠端分支名。
  • origin/master:遠端分支在本地的拷貝,因此稱為本地分支。

範例

  • git fetch origin master:取得遠端分支 master 的資料。
  • git merge origin/master:合併本地分支 origin/master 的程式碼。
  • git push origin master:將本地提交紀錄推至遠端分支 master。

說明

方法一:git pull

  • Step 1:切換到新分支。
  • Step 2:從遠端更新程式碼,並將 master 合併至新的分支。HEAD 指向新分支的程式碼。
$ git checkout <new_branch>
$ git pull origin master
加入參數 --rebase,這樣就會以 rebase 的方式合併(同註一)。
  • Step 1:切換到新分支。
  • Step 2:在分支 <new_branch> 合併從遠端更新完畢後的 master 的程式碼,並以 rebase 的方式合併。HEAD 指向 master 的程式碼。
$ git checkout <new_branch>
$ git pull origin master --rebase

方法二:git fetch + git merge

  • Step 1:取得遠端資料並更新本地 master 程式碼。
  • Step 2:將 master 的程式碼合併至新分支中。HEAD 指向新分支的程式碼。
$ git fetch origin master
$ git checkout master
$ git merge origin/master

$ git checkout <new_branch>
$ git merge master
以下是更簡單的作法,不更新本地 master 分支,直接與本地分支 origin/master 合併。
$ git fetch origin master
$ git merge origin/master

方法三:git fetch + git rebase

  • Step 1:取得遠端資料並更新本地程式碼。
  • Step 2:切換到新分支,新分支以 master 為新的基準點,將分支所修改的程式碼紀錄接在後面。HEAD 指向新分支的程式碼。
$ git fetch origin master
$ git checkout master
$ git merge origin/master

$ git checkout <new_branch>
$ git rebase master
也可以這樣寫,不切換到新分支,直接指定新的基準點。
  • Step 1:取得遠端資料並更新本地 master 程式碼。
  • Step 2:以 master 為新的參考基準點,將分支 <new_branch> 的修改接在新的基準點後。
$ git fetch origin master
$ git checkout master
$ git merge origin/master

$ git rebase master <new_branch>
以下是更簡單的作法,不更新本地 master 分支,直接以 origin/master 為新的基準點,將新分支所修改的程式碼紀錄接在後面。
$ git fetch origin master
$ git rebase origin/master
註一
方法三的意義等同於 git pull origin master --rebase

方法四:git cherry-pick

  • Step 1:從遠端取得更新,接著切換到新分支。
  • Step 2:使用 cherry-pick 將目前 origin/master 所在位置與新分支差異的提交紀錄揀選(合併)至新分支,並需要建立一個提交紀錄來儲存這些變更。
$ git fetch origin master
$ git checkout <new_branch>
$ git cherry-pick origin/master
但不建議使用這個方法,因為在 graph 中並不會顯示合併,而是將 master 的某些提交紀錄「揀選」到新分支形成分岔。並且,之後若要合併回主線,仍須再解一次衝突。解完 conflict 後若無差異,則會回到使用 cherry-pick 合併後的狀況(註 2)。由於找不到類似的資料,因此在這裡提問。
註 2
之後要合併回主線仍需使用前三種方法,例如:使用 git pull origin master,這樣就會形成一個小耳朵,表示回到主線了。

from : https://cythilya.github.io/2018/06/19/git-merge-branch-into-master/

2020年4月24日 星期五

Should I rebase with dev branch before making a pull request?

Our current workflow:
create a feature branch from dev. after developing the feature and having pushed the branch do a the following:
git checkout dev
git pull --rebase (on dev)
git checkout my-feature-branch
git rebase dev

from : https://stackoverflow.com/questions/51404094/should-i-rebase-with-dev-branch-before-making-a-pull-request

2020年4月7日 星期二

SSH agent forwarding 的應用

SSH agent forwarding 可以讓本地的 SSH Key 在遠端 Server 上進行轉送,也就是當你需要在選端 Server 上使用 SSH Key 時,就不需要將你的 key pair 手動複製到 server 上,是個暨方便又安全的作法。
舉例來說,首先 SSH 登入進 Server1,接著在 Server1 上登入 Server2 時,就會自動使用你本地的 SSH Key:
Local ---(SSH)---> Server1 ---(SSH)---> Server2
那要怎麼使用:
首先需要將要 forwarding 的 private key 加到清單裡面:
ssh-add
ssh-add -L
可以檢查這個清單。接著:
方法一:每次要 Local 連上 Server 時,加上 -A 參數:
ssh -A user@{you server1 ip}
方法二:修改 ~/.ssh/config 設定,加上 ForwardAgent yes,這樣就不需要每次連都加上 -A 參數。例如
Host server1
  HostName 106.187.36.122
  ForwardAgent yes
實務上有什麼應用呢? 這裡舉兩個常用的例子:

Bastion Host

在 AWS 的架構課中,每次講 VPC 就會提到 Bastion host 的概念,也就是整組內部網路只開放一台 server 可以從外部做 SSH 連線,如果需要 SSH 連線其他機器,都必須透過這一台 Bastion host 轉過去。這樣做的目的當然是為了安全性,我們可以特別加強這一台 Bastion host 的安全,例如鎖外部 IP 或是裝 SELinux 等等,這一台的用途就專門只做 SSH 連線,畢竟越簡單越容易防護,更細節的 OS 防護原則可以參考 OS Hardening Principles
既然 SSH 連線都必須透過這台 Bastion host,那麼 SSH agent forwarding 這招就很好用了,就不需要、也不應該把 private key 放到 Bastion host 上面。

Git Deployment

如果你有用 Git 版本控制系統的話,你的應用程式佈署也很可能需要在 Server 上把 Source Code 從 repository 拉下來,這時候就會需要 SSH 的權限。
以前小時候不懂事,總是在 Server 上生出一組部署專用的 SSH key pair,然後在 Github 上設定這組 key 可以讀取 repository。後來發現這完全是多餘又增加安全風險。既然有權限佈署,那麼也就表示你應該就有權限可以讀取 source code,那就用你自己的 SSH key 就好啦,就不需要在 server 上擺一組 SSH key pair 了。
如果是用 Ruby 的 capistrano 做部署的話,只要設定一下就可以了:

set :ssh_options, {
  forward_agent: true
}

這樣在佈署程序中就會用到你自己的 SSH key 去 Github 拉 source code 了。

參考資料


from : https://ihower.tw/blog/archives/7837

2020年1月1日 星期三

git rebase --onto

简单地说,git rebase --onto选择一系列提交并在作为参数给出的提交中重新定义它们。
阅读git rebase的手册页,搜索“到”。这些例子非常好:
example of --onto option is to rebase part of a branch. If we have the following situation:

                                   H---I---J topicB
                                  /
                         E---F---G  topicA
                        /
           A---B---C---D  master

   then the command

       git rebase --onto master topicA topicB

   would result in:

                        H'--I'--J'  topicB
                       /
                       | E---F---G  topicA
                       |/
           A---B---C---D  master
在这种情况下,您告诉git将topicA上的提交重新绑定到topicB之上的master

from : https://www.it-swarm.net/zh/git/%E6%88%91%E6%97%A0%E6%B3%95%E7%90%86%E8%A7%A3git-rebase-onto%E7%9A%84%E8%A1%8C%E4%B8%BA/1052063464/