Git is a technology which can be endlessly explained, but sometime demonstrations are best.
What does a typical day look like for you and your relationship with git
?
Git is a technology which can be endlessly explained, but sometime demonstrations are best.
What does a typical day look like for you and your relationship with git
?
For further actions, you may consider blocking this person and/or reporting abuse
Dev on Remote -
Spandan Sehgal -
Alysa -
Jima Victor -
Oldest comments (41)
I use git constantly. Doing Open Source work a lot and actually having an interest in learning git deeply motivates me to spend a lot of time screwing around with it!
I stick to the basics and really only add, commit, and push!
What about branching practices?
Ah! Iβve always used feature branches off of master that are small and try to keep them open for only a few days.
he always push to master π€
Me too, that's 99.9% what I do when I use git
Add. Commit. Push. Exhale.
I use VS Code git gui for branching, adding, committing, merge conflicts. I use git command line for rebasing, resetting, looking at logs, reflogs and pushing.
I'm using Tower on Mac, and the git extension of VSCode, my best days of using
git
is when I'm only pushing into themaster
branch on my personal projects.Mostly the basics, as others are saying. Add, commit, push, merge. Occasionally I'll have a legitimate reason to use
cherry-pick
, which always feels fun to use for some reason.Even when it is just myself working on something, I try to avoid commands that "rewrite history", so I don't get in the habit of using them.
Things I've been trying to do more of lately:
A neat "trick" I recently learned is how to merge branches without switching to them. Not really needed often, but feels cool to use:
Essentially you're saying fetch
.
(as an alias for local), get the head / latest commit of {localBranchA}, and then fast-forward {localBranchToMergeAInto} to point to it. See this for details.Branch, add, commit, push, pr/merge & delete remote, delete local, repeat.
We use Bitbucket at work and I normally find myself creating branches there instead of directly in git... Then the usual.. lots of commits and then push to origin
Fairly often find the need for a rebase, occasionally a cherry pick, and when everything goes terribly wrong, a bisect to find where it all went pear shaped π
Pretty much only add, commit, push, & merge like everyone else has said. I've starting implenting some CI/CD type stuff into my projects so that has me working with Branches a lot more.
Biggest thing I'm really focusing on is writing more useful commit messages. Too many have just been "stuff" "more stuff" and "idk" which isn't a super huge problem when I'm working on stuff myself, but it definitely won't fly when actually working with a team.
Hey, I know it's behind a paywall but I'm still gonna mention it. I published a git course a while back on Egghead (egghead.io/courses/productive-git-...). The goal of the course was not to be just another "I'm a git magician" type of course, but rather to show a few IMHO simple git commands that can dramatically improve your dev experience. In fact the course describes pretty much what I'm using on a daily basis and what proved to work (at least in my case).
It's a mixture of
--fixup
commits to later autosquash)master
meanwhile)master
once reviewed and ready (to have a linear git history)Also, using conventional git commit messages for better readability, like
add commit push mainly with creating branches.
Also most of the times have to use rebase, fetch and stash.
start:
if (no current task) goto
New Task
Old Task:
gco <branch-name
goto
work
New Task:
gcb <branch-name>
work:
(... bunch of typing here...)
Quick check:
gst
Add All:
gaa
Then commit:
gc
if (not finished or no urge to backup everything online) goto
work
push:
Push using the local branch name:
ggpush
if (no conflicts) goto
finish
Resolve conflict with master:
gm master
(I used neovim and fugitive to resolve the actual conflict)
go to
push
finish:
back to master:
gco master
Pull all changes:
gl
if (not end of day) goto
start
oh-my-zsh with the git plugin for the aliases
10 years ago I had to resort to using more exotic commands such as
rebase -i
. The more confused your team is the more you need know git to get things unstuck.I recently started using stash in addition to the all the basics. Other than that is pretty straightforward. You really get a good feeling of your workflow when collaborating. If you just use master to do everything you will just use the very bare bones of git.
Got a handful of aliases for my workflow, like, co, gs, gcm, gfu, gfo, gmu, gmo, etc just to avoid typing same things over and over lol.
In the morning I do a quick
git status
to see what the state of my repo is. Usually, I have a feature I'm working on, for which I have a branch. Sometimes I'm in the middle of some big task which I should have divided into smaller ones and committed ages ago, and the status command helps me rebuild the mental model of what changes I've made. So I make some more changes, add them and commit.I try to remind myself to regularly merge "master" back into my feature branch. Resolving conflicts is easier when they're small.
I push my branch and make a PR fairly early, so that CircleCI runs all the tests for me. As an added benefit for remote work, build results trigger a message in our team's slack, so a push+build gives a visible sense of my progress to the rest of the team.
Then I request 1 or 2 team mates to review my code. I apply the review comments I agree with, and start discussions on the ones I disagree with. When all reviewers give it a thumbs up, the last reviewer merges it into master. Then the branch on Github is deleted, and I delete my local feature branch. I go back to master and pull, before creating a new feature branch for the next thing I work on.