-
1. Getting Started
- 1.1 About Version Control
- 1.2 A Short History of Git
- 1.3 What is Git?
- 1.4 The Command Line
- 1.5 Installing Git
- 1.6 First-Time Git Setup
- 1.7 Getting Help
- 1.8 Summary
-
2. Git Basics
- 2.1 Getting a Git Repository
- 2.2 Recording Changes to the Repository
- 2.3 Viewing the Commit History
- 2.4 Undoing Things
- 2.5 Working with Remotes
- 2.6 Tagging
- 2.7 Git Aliases
- 2.8 Summary
-
3. Git Branching
- 3.1 Branches in a Nutshell
- 3.2 Basic Branching and Merging
- 3.3 Branch Management
- 3.4 Branching Workflows
- 3.5 Remote Branches
- 3.6 Rebasing
- 3.7 Summary
-
4. Git on the Server
- 4.1 The Protocols
- 4.2 Getting Git on a Server
- 4.3 Generating Your SSH Public Key
- 4.4 Setting Up the Server
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Third Party Hosted Options
- 4.10 Summary
-
5. Distributed Git
- 5.1 Distributed Workflows
- 5.2 Contributing to a Project
- 5.3 Maintaining a Project
- 5.4 Summary
-
6. GitHub
-
7. Git Tools
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Debugging with Git
- 7.11 Submodules
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Summary
-
8. Customizing Git
- 8.1 Git Configuration
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Summary
-
9. Git and Other Systems
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Summary
-
10. Git Internals
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Packfiles
- 10.5 The Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Environment Variables
- 10.9 Summary
-
A1. Appendix A: Git in Other Environments
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Visual Studio Code
- A1.4 Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git in Sublime Text
- A1.6 Git in Bash
- A1.7 Git in Zsh
- A1.8 Git in PowerShell
- A1.9 Summary
-
A2. Appendix B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Appendix C: Git Commands
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
3.3 Git Branching - Branch Management
Branch Management
Now that you’ve created, merged, and deleted some branches, let’s look at some branch-management tools that will come in handy when you begin using branches all the time.
The git branch
command does more than just create and delete branches.
If you run it with no arguments, you get a simple listing of your current branches:
$ git branch
iss53
* master
testing
Notice the *
character that prefixes the master
branch: it indicates the branch that you currently have checked out (i.e., the branch that HEAD
points to).
This means that if you commit at this point, the master
branch will be moved forward with your new work.
To see the last commit on each branch, you can run git branch -v
:
$ git branch -v
iss53 93b412c Fix javascript issue
* master 7a98805 Merge branch 'iss53'
testing 782fd34 Add scott to the author list in the readme
The useful --merged
and --no-merged
options can filter this list to branches that you have or have not yet merged into the branch you’re currently on.
To see which branches are already merged into the branch you’re on, you can run git branch --merged
:
$ git branch --merged
iss53
* master
Because you already merged in iss53
earlier, you see it in your list.
Branches on this list without the *
in front of them are generally fine to delete with git branch -d
; you’ve already incorporated their work into another branch, so you’re not going to lose anything.
To see all the branches that contain work you haven’t yet merged in, you can run git branch --no-merged
:
$ git branch --no-merged
testing
This shows your other branch.
Because it contains work that isn’t merged in yet, trying to delete it with git branch -d
will fail:
$ git branch -d testing
error: The branch 'testing' is not fully merged.
If you are sure you want to delete it, run 'git branch -D testing'.
If you really do want to delete the branch and lose that work, you can force it with -D
, as the helpful message points out.
Tip
|
The options described above, You can always provide an additional argument to ask about the merge state with respect to some other branch without checking that other branch out first, as in, what is not merged into the
|
Changing a branch name
Caution
|
Do not rename branches that are still in use by other collaborators. Do not rename a branch like master/main/mainline without having read the section "Changing the master branch name". |
Suppose you have a branch that is called bad-branch-name
and you want to change it to corrected-branch-name
, while keeping all history.
You also want to change the branch name on the remote (GitHub, GitLab, other server).
How do you do this?
Rename the branch locally with the git branch --move
command:
$ git branch --move bad-branch-name corrected-branch-name
This replaces your bad-branch-name
with corrected-branch-name
, but this change is only local for now.
To let others see the corrected branch on the remote, push it:
$ git push --set-upstream origin corrected-branch-name
Now we’ll take a brief look at where we are now:
$ git branch --all
* corrected-branch-name
main
remotes/origin/bad-branch-name
remotes/origin/corrected-branch-name
remotes/origin/main
Notice that you’re on the branch corrected-branch-name
and it’s available on the remote.
However, the branch with the bad name is also still present there but you can delete it by executing the following command:
$ git push origin --delete bad-branch-name
Now the bad branch name is fully replaced with the corrected branch name.
Changing the master branch name
Warning
|
Changing the name of a branch like master/main/mainline/default will break the integrations, services, helper utilities and build/release scripts that your repository uses. Before you do this, make sure you consult with your collaborators. Also, make sure you do a thorough search through your repo and update any references to the old branch name in your code and scripts. |
Rename your local master
branch into main
with the following command:
$ git branch --move master main
There’s no local master
branch anymore, because it’s renamed to the main
branch.
To let others see the new main
branch, you need to push it to the remote.
This makes the renamed branch available on the remote.
$ git push --set-upstream origin main
Now we end up with the following state:
git branch --all
* main
remotes/origin/HEAD -> origin/master
remotes/origin/main
remotes/origin/master
Your local master
branch is gone, as it’s replaced with the main
branch.
The main
branch is present on the remote.
However, the old master
branch is still present on the remote.
Other collaborators will continue to use the master
branch as the base of their work, until you make some further changes.
Now you have a few more tasks in front of you to complete the transition:
-
Any projects that depend on this one will need to update their code and/or configuration.
-
Update any test-runner configuration files.
-
Adjust build and release scripts.
-
Redirect settings on your repo host for things like the repo’s default branch, merge rules, and other things that match branch names.
-
Update references to the old branch in documentation.
-
Close or merge any pull requests that target the old branch.
After you’ve done all these tasks, and are certain the main
branch performs just as the master
branch, you can delete the master
branch:
$ git push origin --delete master