内容简介:I have been using git for a while, and I took the time to learn about it in great detail. Equipped with an understanding of its internals and a comfortable familiarity with tools likeIn short, I use git branches very rarely, preferring to work on my local
I have been using git for a while, and I took the time to learn about it in great detail. Equipped with an understanding of its internals and a comfortable familiarity with tools like git rebase — and a personal, intrinsic desire to strive for minimal and lightweight solutions — I have organically developed a workflow which is, admittedly, somewhat unorthodox.
In short, I use git branches very rarely, preferring to work on my local master branch almost every time. When I want to work on multiple tasks in the same repository (i.e. often), I just… work on all of them on master. I waste no time creating a new branch, or switching to another branch to change contexts; I just start writing code and committing changes, all directly on master, intermixing different workstreams freely.This reduces my startup time to zero, both for starting new tasks and revisiting old work.
When I’m ready to present some or all of my changes to upstream, I grab git rebase and reorganize all of these into their respective features, bugfixes, and so on, forming a series of carefully organized, self-contained patchsets. When I receive feedback, I just start correcting the code right away, then fixup the old commits during the rebase. Often, I’ll bring the particular patchset I’m ready to present upstream to the front of my master branch at the same time, for convenient access with git send-email .
I generally set my local master branch to track the remote master branch,so
I can update my branch with git pull --rebase
.Because all of my
work-in-progress features are on the master branch, this allows me to quickly
address any merge conflicts with upstream for all
of my ongoing work at once.
Additionally, by keeping them all on the same branch, I can be assured that my
patches are mutually applicable and that there won’t be any surprise conflicts
in feature B after feature A is merged upstream.
If I’m working on my own projects (where I can push to upstream master), I’ll
still be working on master. If I end up with a few commits queued up and I need
to review some incoming patches, I’ll just apply them to master, rebase them
behind my WIP work, and then use git push origin HEAD~5:refs/heads/master
to
send them upstream, or something to that effect.Bonus: this instantly
rebases my WIP work on top of the new master branch.
This workflow saves me time in several ways:
- No time spent creating new branches for new features.
- No time spent switching between branches to address feedback.
- All of my features are guaranteed to be mutually applicable to master, saving me time addressing conflicts.
- Any conflicts with upstream are addressed in all of my workstreams at once, without switching between branches or allowing any branch to get stale.
I know that lightweight branches are one of git’s flagship features, but I don’t really use them. I know it’s weird, sue me.
Sometimes I do use branches, though, when I know that a workstream is going to be a lot of work - it involves lots of large-scale refactoring, or will take several weeks to complete. This isolates it from my normal workflow on small-to-medium patches, acknowledging that the large workstream is going to be more prone to conflicts. By addressing these separately, I don’t waste my time fixing up the error-prone branch all the time while I’m working on my smaller workstreams.
-
I will occasionally use
git add -p
or even justgit commit -p
to quickly separate any changes in my working directory into separate commits for their respective workstreams, to make my life easier later on. This is usually the case when, for example, I have to fix problem A before I can address problem B, and additional issues with problem A are revealed by my work on problem B. I just fix them right away,git commit -p
the changes separately, then file each commit into their respective patchsets later. -
“What?” Okay, so in git, you have local branches and remote branches. The default behavior is reasonably sane, so I would forgive you for not noticing. Your local branches can track remote branches, so that when you
git pull
it automatically updates any local tracking branches .git pull
is actually equivalent to doinggit fetch
and thengit merge origin/master
assuming that the current branch (your local master) is trackingorigin/master
.git pull --rebase
is the same thing, except it usesgit rebase
instead ofgit merge
to update your local branch. -
In fact, I have
pull.rebase = true
in my git config, which makes--rebase
the default behavior. -
“What?” Okay, so
git push
is shorthand forgit push origin master
, if you have a tracking branch set up for your local master branch toorigin/master
. But this itself is also shorthand, forgit push <remote> <local>:<remote>
, where<local>
is the local branch you want to push, and<remote>
is the remote branch you want to update. But, remember that branches are just references to commits. In git, there are other ways to reference commits.HEAD~5
, for example, gets the commit which is 5 commits earlier thanHEAD
, which is the commit you have checked out right now. Sogit push origin HEAD~5:refs/for/master
updates theorigin
’srefs/for/master
reference (i.e. the master branch) to the local commit atHEAD~5
, pushing any commits that upstream master doesn’t also have in the process.
Have a comment on one of my posts? Start a discussion in my public inbox by sending an email to ~sircmpwn/public-inbox@lists.sr.ht [ mailing list etiquette ]
Are you a free software maintainer who is struggling with stress, demanding users, overwork, or any other social problems in the course of your work? Please email me — I know how you feel, and I can lend a sympathetic ear and share some veteran advice.
Articles from blogs I follow around the net
This post gives an overview of the recent updates to the Writing an OS in Rust blog and to the used tools. I was quite busy with my master thesis this month, so I didn't have the time to create new content or major new features. However, there were qu…
via Writing an OS in Rust June 3, 2019Introduction to damage tracking
One year and a half ago, I implemented damage tracking for wlroots. It’s about time I write an article about it! I’ll explain damage tracking in the context of a Wayland compositor, but most of that should also apply to other things-that-render-stuff as we…
via Blog on emersion May 30, 2019Generated by openring
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Measure What Matters
John Doerr / Portfolio / 2018-4-24 / GBP 19.67
In the fall of 1999, John Doerr met with the founders of a start-up he’d just given $11.8 million, the biggest investment of his career. Larry Page and Sergey Brin had amazing technology, entrepreneur......一起来看看 《Measure What Matters》 这本书的介绍吧!
HTML 压缩/解压工具
在线压缩/解压 HTML 代码
html转js在线工具
html转js在线工具