Skip to main content

Quick Trip: Rename Current branch in Git

I love to use Powershell and post-git module for day to day work with git.
Sometimes, I have to rename my branches and I have this quick way to do to it.

I love to write shortcuts in PowerShell's Profile to save time. Add this function in Powershell Profile.ps1:


function RenameLocalBranch {
param (
$NewName
)
$currentBranch= git rev-parse --abbrev-ref HEAD

git branch -m $NewName
git push origin :$currentBranch $NewName
git push origin -u $NewName
}



save the profile.ps1 and open a new

go to repo path

call the function and give it a new branch name, it should update local and remote branch for you.

here is the successful output:


C:\Repos\proj [name1 ≡]> RenameLocalBranch name2
Total 0 (delta 0), reused 0 (delta 0)
To https://xxxxxxxxx.visualstudio.com/_git/xxxxxxxxxx
- [deleted] name1
* [new branch] name2 -> name2
Everything up-to-date
Branch 'name2' set up to track remote branch 'name2' from 'origin'.
C:\Repos\proj [name2 ≡]>


Prerequisite:

  • Posh git
  • git for windows
  • project in ADO
  • valid repo
Labels:

Comments

Post a Comment

Popular posts from this blog

What is release, and what is a deployment?

T o understand the concepts and the technical implementation in many tools, you need to know how tool vendors define the difference between a release and a deployment. A  release  is a package or container containing a versioned set of artifacts specified in a release pipeline in your CI/CD process. It also includes a snapshot of all the information required to carry out all the tasks and activities in a release pipeline, such as: The stages or environments. The tasks for each one. The values of task parameters and variables. The release policies such as triggers, approvers, and release queuing options. On the other hand,  Deployment  is the action of running the tasks for one stage, which results in a tested and deployed application and other activities specified for that stage. Starting a release starts each deployment based on the settings and policies defined in the original release pipeline. There can be multiple deployments of each release, even for one stage. ...
Post a Comment
Read more

Delivery cadence and three types of triggers

Both the release and stages make use of triggers. There are three types of triggers we recognize. Continuous deployment trigger You can set up this trigger on your release pipeline. Once you do that, your release pipeline will trigger every time a build completes, and a new release will be created. Scheduled triggers This speaks for itself, but it allows you to set up a time-based manner to start a new release—for example, every night at 3:00 AM or 12:00 PM. You can have one or multiple schedules per day, but it will always run at this specific time. Manual trigger With a manual trigger, a person or system triggers the release based on a specific event. When it's a person, it probably uses some UI to start a new release. When it's an automated process, some events will likely occur. You can trigger the release from another system using the automation engine   Navigation Traditional IT deployment cycle What is Continuous Delivery? What is release, and what is a deployment? Azure...
Post a Comment
Read more

Considerations for deployment to stages

When you have a clear view of the different stages you'll deploy, you need to think about when you want to deploy to these stages.  Continuous Delivery is about deploying multiple times a day and can deploy on-demand. When we define our cadence, questions that we should ask ourselves are: Do we want to deploy our application? Do we want to deploy multiple times a day? Can we deploy to a stage? Is it used? A typical scenario we often see is continuous deployment during the development stage. Every new change ends up there once it's completed and builds. Deploying to the next phase doesn't always occur multiple times but only at night. When designing your release strategy, choose your triggers carefully and consider the required release cadence. Some things we need to take into consideration are: What is your target environment? Does one team use it, or do multiple teams use it? If a single team uses it, you can deploy it frequently. Otherwise, it would be best if you were a ...
Post a Comment
Read more