from Git Checkout | Atlassian Git Tutorial
Git Checkout
This page is an examination of the git checkout command. It will cover usage examples and edge cases. In Git terms, a "checkout" is the act of switching between different versions of a target entity. The git checkout command operates upon three distinct entities: files, commits, and branches. In addition to the definition of "checkout" the phrase "checking out" is commonly used to imply the act of executing the git checkout command. In the Undoing Changes topic, we saw how git checkout can be used to view old commits. The focus for the majority of this document will be checkout operations on branches.
Checking out branches is similar to checking out old commits and files in that the working directory is updated to match the selected branch/revision; however, new changes are saved in the project history—that is, it’s not a read-only operation.
Checking out branches
The git checkout command lets you navigate between the branches created by git branch. Checking out a branch updates the files in the working directory to match the version stored in that branch, and it tells Git to record all new commits on that branch. Think of it as a way to select which line of development you’re working on.
Having a dedicated branch for each new feature is a dramatic shift from a traditional SVN workflow. It makes it ridiculously easy to try new experiments without the fear of destroying existing functionality, and it makes it possible to work on many unrelated features at the same time. In addition, branches also facilitate several collaborative workflows.
The git checkout command may occasionally be confused with git clone. The difference between the two commands is that clone works to fetch code from a remote repository, alternatively checkout works to switch between versions of code already on the local system.
==> except as we will see later, in the second article, we can use checkout to get "remote_local"
Usage: Existing branches
Assuming the repo you're working in contains pre-existing branches, you can switch between these branches using git checkout. To find out what branches are available and what the current branch name is, execute git branch.
$＞ git branch
main
another_branch
feature_inprogress_branch
$＞ git checkout feature_inprogress_branchThe above example demonstrates how to view a list of available branches by executing the git branch command, and switch to a specified branch, in this case, the feature_inprogress_branch.
New Branches
Git checkout works hand-in-hand with git branch. The git branch command can be used to create a new branch. When you want to start a new feature, you create a new branch off main using git branch new_branch. Once created you can then use git checkout new_branch to switch to that branch. Additionally, The git checkout command accepts a -b argument that acts as a convenience method which will create the new branch and immediately switch to it. You can work on multiple features in a single repository by switching between them with git checkout.
git checkout -b ＜new-branch＞The above example simultaneously creates and checks out . The -b option is a convenience flag that tells Git to run git branch before running git checkout.
===> by the above command, the <new-branch> is strictly a local one based off current branch, even if you copy the remote branches' name
git checkout -b ＜new-branch＞ ＜existing-branch＞By default git checkout -b will base the new-branch off the current HEAD. An optional additional branch parameter can be passed to git checkout. In the above example, ＜existing-branch＞ is passed which then bases new-branch off of existing-branch instead of the current HEAD.
the <existing-branch> can be a remote one, this is the most concise way to work on a remote version.
Switching Branches
Switching branches is a straightforward operation. Executing the following will point HEAD to the tip of .
git checkout ＜branchname＞Git tracks a history of checkout operations in the reflog. You can execute git reflog to view the history.
Git Checkout a Remote Branch
(more on this by the second article)
When collaborating with a team it is common to utilize remote repositories. These repositories may be hosted and shared or they may be another colleague's local copy. Each remote repository will contain its own set of branches. In order to checkout a remote branch you have to first fetch the contents of the branch.
git fetch --allIn modern versions of Git, you can then checkout the remote branch like a local branch.
git checkout ＜remotebranch＞Older versions of Git require the creation of a new branch based on the remote.
git checkout -b ＜remotebranch＞ origin/＜remotebranch＞Additionally you can checkout a new local branch and reset it to the remote branches last commit.
git checkout -b ＜branchname＞
git reset --hard origin/＜branchname＞Detached HEADS
Now that we’ve seen the three main uses of git checkout on branches, it's important to discuss the “detached HEAD” state. Remember that the HEAD is Git’s way of referring to the current snapshot. Internally, the git checkout command simply updates the HEAD to point to either the specified branch or commit. When it points to a branch, Git doesn't complain, but when you check out a commit, it switches into a “detached HEAD” state.
This is a warning telling you that everything you’re doing is “detached” from the rest of your project’s development. If you were to start developing a feature while in a detached HEAD state, there would be no branch allowing you to get back to it. When you inevitably check out another branch (e.g., to merge your feature in), there would be no way to reference your feature:
The point is, your development should always take place on a branch—never on a detached HEAD. This makes sure you always have a reference to your new commits. However, if you’re just looking at an old commit, it doesn’t really matter if you’re in a detached HEAD state or not.
Summary
This page focused on usage of the git checkout command when changing branches. In summation, git checkout, when used on branches, alters the target of the HEAD ref. It can be used to create branches, switch branches, and checkout remote branches. The git checkout command is an essential tool for standard Git operation. It is a counterpart to git merge. The git checkout and git merge commands are critical tools to enabling git workflows.
Ready to try branching?
Try this interactive tutorial.
What is Git Checkout Remote Branch? How It Works, When to Use It, Examples, Tutorials & More
STACKIFYNOVEMBER 19, 2021DEVELOPER TIPS, TRICKS & RESOURCES
Git is one of the most useful tools for developers and development teams. And Git checkout remote branch makes it easier to collaborate and review. Let’s learn about it today.
As developers, we work with Git often. In fact, at Stackify by Netreo, we have a Git page where you can see quite a few repositories. Like many developers and groups, we migrated our version control to a Git-based system a few years back. So working with Git is a big part of our ongoing work.
It’s pretty important that developers understand how to work with Git, Git repositories (like controlling the size of your reports — an issue we talk about here) and code in Git. One thing you’ll be doing at least periodically is checking out a remote branch, so we put together this brief tutorial to cover the ins and outs of working with remote branches in Git.
Git Checkout Remote Branch Definition
Git checkout remote branch is a way for a programmer to access the work of a colleague or collaborator for the purpose of review and collaboration. There is no actual command called “git checkout remote branch.” It’s just a way of referring to the action of checking out a remote branch.
Git is a way for software developers to track different modifications of their code. It keeps all the various versions in a unique database. Git allows multiple developers to work on the same code simultaneously. Sometimes, a programmer will need to access a coworker’s independent work, or “branch.” The git checkout remote branch action makes this possible.
Why Use Git Checkout Remote Branch?
In Git, a branch is a separate line of development. The Git branch command creates new branches.
When a programmer fixes a bug or adds a new feature, he or she creates a new branch to make the changes. The new Git branch ensures changes don’t threaten existing, working code.
Sometimes programmers need to access a branch that’s not stored locally but don’t want to create a new local branch or version. When you actually want to work on the remote version, you need to use the Git checkout remote branch method.
How Does It Work?
Git checkout remote branch lets us switch and work on a remote branch, just like switching to a local one. For the latest versions of Git, you can simply use:
git fetch
git checkout branchxyz
In this case, the remote branch is called “branchxyz.”
Examples
Below are a couple examples of checking out remote branches with Git.
In this one, we’re simply checking out a remote branch called xyz:
git fetch
git checkout xyz
That’s fine as long as we don’t have a local branch that’s also called “xyz.” ==> if you accidentally created a useless branch by git checkout -b, ==> use git branch -d to delete that one. In that event, we’d confuse Git with the “git checkout xyz” command. We need to specify that we’re referring to the remote branch like this:
git fetch origin
git checkout –track origin/xyz
If we’ve got multiple remotes, we need to use:
Git checkout -b xyz <remote name>/xyz
!! for --track vs. -b <local> <remote> see: Difference between git checkout --track origin/branch and git checkout -b branch origin/branch - Stack Overflow
https://stackoverflow.com/questions/10002239/difference-between-git-checkout-track-origin-branch-and-git-checkout-b-branch
The two commands have the same effect (thanks to Robert Siemer’s answer for pointing it out).
The practical difference comes when using a local branch named differently:
git checkout -b mybranch origin/abranchwill createmybranchand trackorigin/abranchgit checkout --track origin/abranchwill only create 'abranch', not a branch with a different name.(That is, as commented by Sebastian Graf, if the local branch did not exist already.
If it did, you would needgit checkout -B abranch origin/abranch)==> eventually it's --track that will handle the merging of local and remote version
Benefits
Git is an incredibly powerful tool for programmers to collaborate on coding projects. Imagine having 10 programmers all working on the same piece of code then merging those changes without any version tracking system.
With git checkout remote branch, multiple developers can work on a single piece of software, each making their own changes in a protected way, without adding unstable code to working software.
Git checkout remote branch makes it easy to review and collaborate with others in a failsafe way.
Git Checkout Remote Branch Best Practices
Since the Git checkout remote branch methods listed above are a subset of Git, best practices are the same. Here are surefire ways to succeed in working with Git checkout remote branch:
- Commit often. When we commit often, we keep our commits small and share our work more frequently. That makes it easier to avoid large merge conflicts.
- Don’t commit to unfinished work. Break your feature’s code into small but working chunks. Once you finish a chunk, test it, then commit it. This work method prevents the potential conflicts created by merging large bodies of code all at once. At the same time, it ensures we don’t commit small snippets of non-working code.
- Before you commit, test. Don’t commit something until you’ve tested it. Shared code that isn’t tested can create a lot of headaches and lost time for an entire team.
- Commit related changes. Make your commits small, and confine them to directly related changes. When we fix two separate bugs, they should take the form of two different commits.
- Write clear commit messages. Include a single-sentence summary of your changes. After that, explain the motivation for the change and how it’s different from the previous version.
- Use branches. Branches are an excellent tool to avoid confusion and keep different lines of development separate.
- Agree on your workflow. Your team should agree on a workflow before the project starts. Whether that’s based on topic-branches, git-flow, long-running branches or some other workflow will depend on the project.
630
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
