![]() This is useful information if there was a conflict, but otherwise it’s just noise which pollutes the history. It forces the creation of a merge commit.So how should I approach getting the changes my co-workers have made on master? I could git fetch origin and git merge origin/master, but that would cause two undesirable side effects: My two recent (unshared) commits are at the top of the history, and the rest is the history of master when I originally checked out this branch. My log looks something like this on the local branch. I’ve made 2 commits locally that aren’t shared on the origin remote, and while I’ve been working on my feature branch my co-workers have made 20 commits on origin/master that I don’t have on my branch (but I would like to). Say I have been doing work on a feature branch and I want to merge in the changes my teammates have made on the master branch. If you’re still confused, let’s look at an example. This is really important to get a grip on and can help you resolve conflicts much more quickly. In a rebase, you usually are working on a feature branch or locally unique version which you look at and think is “ours”, and which you want to port “theirs” into, but from git’s perspective in a rebase it’s actually the opposite. git rebase likely has an opposite idea than you do about which branch is “ours” vs. In a rebase, Branch A is considered “ours” ( git checkout -ours can be used in a conflict to get this version) because it’s where we started working from git’s perspective, and Branch B is considered “theirs” ( git checkout -theirs also exists) because from git’s perspective those are the “foreign” commits to port. For instance, you might rebase on top of master to catch your branch up to the current state of the world in your feature branch. That way, you can “catch up” to other branches by re-writing git history in your local git. Git rebase in its simplest form is a command which will “port” another branch (Branch A) into the branch where you are currently working (Branch B), by applying all of your unique commits from Branch B on top of Branch A and replacing Branch B with this revised version. What is it?įrom the man page: “git rebase: Forward-port local commits to the updated upstream head”. Rebasing, like most of git, should be learned and applied to be useful - not feared or misunderstood - so if you’ve been bitten by rebase in the past, or are simply curious about how it can be used, hopefully I can persuade you here of its utility. Feel free to share your own rebase experiences in the comments. ![]() Indeed, previously I worked on a team where the mere mention of a rebase to the wrong team member could evoke howls of anxiety and protest. We get superstitious sometimes, and in the face of the brain-crushing complexity of modern computing, who wouldn’t? One fear I’ve noticed is of git (in general) and in particular of git rebase. Developers like to pretend that we’re analytical and make decisions based purely on logic but the truth is that, like most people, we’re creatures of emotion and habit first and foremost. ![]()
0 Comments
Leave a Reply. |