This will open an editor with these contents: pick 239d4c3 Improve user logic $ git rebase -i HEAD~3 # Interactively rebase the last 3 commits You want it to be added to the “Improve user logic” commit, so do this:
Reordering commits with interactive rebasing You can also omit this if you want to change the description of the commit. The -no-edit command means you don’t want to change the commit message. Instead, try to get into the habit of checking which files are actually changed (with git status), and then adding files to your commits explicitly: git add It can also easily lead to errors, because you might easily accidentally include changes you weren’t aware of, and forget to include new files that aren’t currently tracked.
This creates a commit that automatically includes all existing changes for currently tracked files (it won’t add changes from files that aren’t yet tracked).īy doing this you miss a chance to consider how your work could be logically grouped into multiple commits. Try to avoid using git commit -all (or git commit -a). This will help the history in master stay chronological, rather than branching too often. If you can, you should also run git pull -rebase upstream master just before your feature is merged into master. This keeps everything in a clear logical order. This will grab any new commits from the master branch, and then add all the commits in your feature branch on top of them. (where upstream is the name of the remote pointing to your central repository, and master is your parent branch). You can avoid this by frequently running: git pull -rebase upstream master This may mean that merging your work when you’ve finished might become very tricky. the master branch of the main repository), you want to avoid your branch getting out of sync with the latest work in the parent branch.Īs time goes by, your forked branch where you’re working can become significantly out of sync with the latest master branch. If you work on feature branches, like we do, that are based off a parent branch (e.g. These are some tricks I use for tidying up the Git commit history on my feature branches as I work, so they tell a neat story. But it’s very important to only ever git push -force to overwrite new work on a feature branch that you wholly control. So in our case, we use the below tips only to tidy up our Git commits in our feature branches before merging our work into the central repository.Īfter we’ve rewritten history on one of our feature branches, we may then need to run git push -force to force the remote version of the feature branch to use our rewritten version of history. These feature branches are therefore wholly owned by the person working on that feature. In our workflow, we do all new work on feature branches on our own forks of the central repository. For example, if your commits are still only local to your computer, or if they are in a feature branch owned by you that hasn’t yet been merged with the central repository. Therefore, you should only do this while you have complete ownership over the history being rewritten.
#Git create branch from specific commit update#
If you haven’t yet merged your work, it would be best to update the original commit where you did the original work with the fix, to tell a simple and clear story.īear in mind that this means rewriting history, which is very problematic if the history is shared. We might create a new class in one commit but then 4 commits later realise we need to change the name of the class, or fix a typo.
However, when we’re doing the work it is rarely so neat. Who controls the present controls the past. Who controls the past controls the future. Your Git commit history should be clear and descriptive – it should read like a logical set of steps that explain how the project got to its current state, where each commit defined one single, small but complete enhancement. I’ll elaborate more on each, and why they’re helpful, below. Amend previous commits with git commit -amend -no-edit.Frequently run git pull -rebase upstream master.These are the techniques I’ll discuss below: One of the things we’re currently working on in the web and design team is a page about writing Git commit messages for our team practices website (I hope to write more about the practices website itself in the coming days).Īs part of that discussion, we jotted down some quick tips for managing commit history in your personal feature branches, to tell a neat story with your commit messages.
0 kommentar(er)
