Executive Summary

$ git push -d <remote_name> <branch_name>
$ git branch -d <branch_name>

Note that in most cases the remote name is origin. In such a case you'll have to use the command like so.

$ git push -d origin <branch_name>

Delete Local Branch

To delete the local branch use one of the following:

$ git branch -d branch_name
$ git branch -D branch_name

Note: The -d option is an alias for --delete, which only deletes the branch if it has already been fully merged in its upstream branch. You could also use -D, which is an alias for --delete --force, which deletes the branch "irrespective of its merged status." [Source: man git-branch]

Delete Remote Branch

As of Git v1.7.0, you can delete a remote branch using

$ git push <remote_name> --delete <branch_name>

which might be easier to remember than

$ git push <remote_name> :<branch_name>

which was added in Git v1.5.0 "to delete a remote branch or a tag."

Starting on Git v2.8.0 you can also use git push with the -d option as an alias for --delete.

Therefore, the version of Git you have installed will dictate whether you need to use the easier or harder syntax.

Delete Remote Branch

From Chapter 3 of Pro Git by Scott Chacon:

Deleting Remote Branches

Suppose you’re done with a remote branch — say, you and your collaborators are finished with a feature and have merged it into your remote’s master branch (or whatever branch your stable code-line is in). You can delete a remote branch using the rather obtuse syntax git push [remotename] :[branch]. If you want to delete your server-fix branch from the server, you run the following:

$ git push origin :serverfix
To git@github.com:schacon/simplegit.git
 - [deleted]         serverfix

Boom. No more branches on your server. You may want to dog-ear this page, because you’ll need that command, and you’ll likely forget the syntax. A way to remember this command is by recalling the git push [remotename] [localbranch]:[remotebranch] syntax that we went over a bit earlier. If you leave off the [localbranch] portion, then you’re basically saying, “Take nothing on my side and make it be [remotebranch].”

I issued git push origin: bugfix and it worked beautifully. Scott Chacon was right—I will want to dog ear that page (or virtually dog ear by answering this on Stack Overflow).

Then you should execute this on other machines

# Fetch changes from all remotes and locally delete 
# remote deleted branches/tags etc
# --prune will do the job :-;
git fetch --all --prune

to propagate changes.

Today we’re announcing that the new moderator agreement is live and the existing moderators are being asked to accept it. This has been a great collaboration to get from a draft in November 2019 to the final agreement in July 2020. It’s gone through several phases of review internally, including with the Community Leadership Team, the Community Management Team, our Legal department, and we have had the assistance of our Public Platform team to build in some tooling to support a sixty-day transition period between the old and new agreements.

In addition to that, this has been reviewed on the Moderator Team which led to over 35 answers and at least five additional questions to dig deeper into specific concerns, and help get the moderators and Stack Exchange, Inc. on the same page. We spent time coming to understand those concerns and discussing how to best address them and that’s represented in this new document. In the two months since that last review, text has been adjusted, some points have been removed, and others have been added to bring this document to where it is now.

For easier reference, I’m going to be calling the two agreements “V1” (the old agreement) and “V2” (the new agreement). You can review the difference between them by looking at the version pages for the agreement. The current page /legal/moderator-agreement on any site (here's Stack Overflow's) will now host the most-recent version of the agreement, currently V2. But specific versions can be viewed by adding the URL /legal/moderator-agreement/versions/[number]. So, right now you could replace [number] with 1 or 2 to see V1 and V2.

With 550+ moderators, I can be sure that some of the mods may not be as comfortable with the new agreement as with the old. This agreement has grown considerably to cover much more than it once did. Some of the new elements are site policies that didn’t exist at the time, such as the Code of Conduct, while others are privacy rules that didn’t exist, like GDPR. These changes were long overdue to keep the agreement current and clear.

While we still have a bucket for “other policies”, the policies that fall into this category will now be linked together through a Help Center article and, in the case where they’re MSE posts, a tag ([tag:mod-agreement-policy]). This is designed to keep the scope of this point limited while also giving us the flexibility to add small network-relevant policies that we need moderators to follow without having to update the mod agreement. Any policies that will be added to this list must be released to the moderators for review so that they are aware of them in advance.

In V2 we’ve added a point about accepting guidance from Community Team members and the Senior Leadership Team. While we do our best to make policy clear, there are times where it will require some interpretation. Because of their experience in developing and working with that policy, these staff members know or have the context to better explain the intent so that moderators can better interpret what that policy is expecting of them - and, thus, what users are expecting.

When users join our sites, they expect us to protect their privacy and the PII we collect about them is a big part of that. We grant moderators access to some of this information so that they can do their work, but we take it very seriously when this access is misused. That’s why the biggest part of V1 is still an important part of V2 - it’s designed to protect our users’ private information and prevent misuse by making our expectations for usage of PII clear.

This section has been adjusted slightly but, overall, it’s largely the same. For example, to allow collaboration between mods on the same site - as was pointed out during discussion with the mods, V1 (and an earlier draft of V2) was overly restrictive of who a moderator could disclose PII to:

I will not disclose this information to anyone,

This would prevent the mods from even talking about it in a private room with co-moderators or even mentioning it to staff in a CM escalation, so the agreement has been updated to state,

I will not disclose or share this information with anyone that is not a moderator or employee of Stack Exchange, Inc.

While we must retain the ability to remove moderators at any time for legal reasons, we have added specific statements that we will use one of the three moderator removal processes whenever possible and that all moderators have the option to appeal all terminations through the newly-updated reinstatement and appeal process.

Whenever possible, moderator removal will follow Stack Exchange, Inc.’s moderator removal processes. I will be informed via written communication of the specific reason that I have been terminated. I have the option to appeal termination through the moderator reinstatement and appeal process.

I predict that some of y’all will ask why we need to say “whenever possible” - and I understand that. Because we can’t predict all future events, there may come times when we need to remove a moderator or can not follow one of the three processes for some reason - for example, if we attempt to communicate about an issue with a mod and they refuse to take part. This is not intended to be an excuse to never use them but an admission that, however unlikely, we legally need to retain the full right to remove someone outside of these processes. Committing to make it clear why a moderator was removed regardless of how it happens is a big improvement from the existing agreement and, along with the appeal process, should help any mods removed without a process to feel they have a recourse.

The biggest change to this agreement is that we’ve added a section that makes the agreement two-way. The old agreement, and even early drafts of V2, made no guarantees for the moderators. This is something that we felt was important to add. In it, we explicitly grant them the protection of policies like the Press Policy, and codify that they have the freedom to speak out publicly about policies without reprisal (provided the CoC is followed) and that we will support the moderators whenever they have questions or need assistance.

As I noted, V2 is significantly longer than V1 so I’m not going into perfect detail here but please feel free to review it. We hope you feel, as we do, that this is a reasonable update to the original agreement.

For those of you who are interested in the behind-the scenes stuff, I thought I’d talk through how the versioning works. Starting today moderators have sixty days to accept V2 or decline it and request to step down. They can review the agreement by visiting /legal/moderator-agreement on any site, though they will need to visit it on the site/s they moderate to accept it. They will also need to accept it once per site they moderate but do not need to accept it on both main and meta any more.

During this period, existing moderators can continue to moderate under V1 before they’ve accepted the new agreement. This is designed to give them time to consider this decision and because we know that many people are busy with life in a very complicated world right now. They can also continue to moderate even if they’ve declined the new agreement; while we hope that everyone can accept the new agreement, we understand that there may be some who can not and we want to make sure we have time to make sure a site has sufficient coverage if one of its mods doesn’t accept.

If a moderator is newly-elected during the interim period or after, they will only have the new agreement to accept and it will act like accepting the old agreement - access to PII and many other mod tools will be withheld until the agreement is accepted. The reasoning here is that the new mods must have accepted an agreement to have access and we are not making the old agreement available for them, even during the interim. If a newly-elected moderator does not want to accept the new agreement, the CMs will reach out to them and the other moderators on their site.

The CMs will be checking in with the accept/decline status on a regular basis and will start working with mod teams during the interim period. Removing diamonds will be done manually, so it will happen gradually as we review the responses. Once the sixty days have passed, any moderator who has either declined the new agreement or hasn’t responded to the notifications to accept the new agreement but who still has their diamond will lose access to PII and some moderator tools. We will be very sensitive to moderator coverage on sites. We don’t want to leave sites with insufficient or no moderators to support them so if someone from a moderation team decides to decline the agreement, we will reach out to them and the rest of the team to determine if an election is necessary.

We do have the option to extend the deadline if it seems like the 60-day cutoff will leave sites unmoderated. If this happens, the extension will apply to all sites, not only the ones that need more time.

A huge amount of work has gone into this agreement and I’d like to thank all of the people who helped shepherd it through the process, both my coworkers and within the moderator community. Your expertise helped make this document what it is today and - particularly to the mods - I hope you feel like this agreement is an improvement over the old one.

If anyone has questions about the agreement itself or the rollout, please post them as an answer.