![]() ![]() Note: while I’m developing it’s likely that my fellow developers will have shipped some of their own changes to remote master. Git commit -m 'This is a new commit, yay!' Next, I’ll check out a new branch so I can write and commit code to this branch – keeping my work separated from the master branch git checkout -b my_cool_featureĪs I’m developing my feature, I’ll make a few commits… git add. When I start development I always make sure the code on my local machine is synced to the latest commit from remote master # With my local master branch checked out If you’d like a visual representation of what each of these commands does, check out my video. On the development team I work with, we’ve successfully adopted the workflow I’m about to show you and it works well for us. It can also be dangerous if you’re working on a shared branch with other developers because of how Git rewrites commits when rebasing however, in the workflow example below, I’ll show you how to mitigate this risk. This point is a bit nuanced, but here is an article that does a good job of explaining why. Rebase doesn’t play super well with open-source projects and pull requests since it can be hard to trace, especially small changes that are introduced to a codebase. Rebasing caveatsĪt this point, I think I better mention some caveats. What you get with this approach is a nice clean tree with all your commits laid out nicely in a row, like a timeline. Behind the scenes, git is actually blowing away the feature branch commits and duplicating them as new commits on top of the master branch (remember, under the hood, commit objects are immutable and immovable). What rebase will do is take all of the commits on your feature branch and move them on top of the master commits. Instead of doing a git merge, I’ll do a git rebase. Now let’s take a look at how rebase would handle this same situation.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |