A day in the life for you and 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?

Comments

[Ashlee (she/her)]

I stick to the basics and really only add, commit, and push!

[Ben Halpern]

What about branching practices?

[Ashlee (she/her)]

Ah! I’ve always used feature branches off of master that are small and try to keep them open for only a few days.

[Liyas Thomas]

he always push to master 🤓

[Carlos Magno]

Me too, that's 99.9% what I do when I use git

[Juri Strumpflohner]

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

• creating feature branches
• committing A LOT on those branches (using --fixup commits to later autosquash)
• rebasing the branch with the latest master multiple times a day (depending on how much is going on on master meanwhile)
• preparing my feature branch for PR via interactive rebase + autosquash
• fast-forwarding it to master once reviewed and ready (to have a linear git history)

Also, using conventional git commit messages for better readability, like

feat(core): ....

build: upgrade version of...

fix(auth): ..

[Martin Himmel]

When starting a change/set of changes:

git checkout master
git checkout -b some_feature

Then, it's typically a cycle of:

git add ./
git commit -m "Did some stuff"
git push

Once it's ready to merge, I create a PR on GitHub to merge with master.

After the merge:

git checkout master
git pull
git branch -d some_feature

Repeat until the end of time. 😄

[Elliot Derhay]

This is really only a summary. There are obviously other things occasionally.

$ git add <filename>
$ git commit
$ git push [remote]

And sometimes:

$ git checkout master
$ git merge release/x.y -m "Release x.y \
\
Changes:\
$(git changelog master..release/x.y)" --no-edit
$ git branch -d release/x.y
$ git push production

Some notes:

• changelog is an alias for grabbing all commit messages in a range, minus any that come from branches that were merged (the opposite of excluding merge messages).
• I haven't had time to figure out making this changelog functionality automatic when merging into master. Past attempts have failed unfortunately (although I'd be open to suggestions; I'm on Windows).

P.S.

I'll try to remember to share this alias if anyone wants it. I'll have to come back over lunch Monday and add it though.

[Andrew Brown 🇨🇦]

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.

gp    > git pull
gh    > git push
gcm > git checkout master
gcb  > git checkout -b
git push --tags

[Frederik 👨‍💻➡️🌐 Creemers]

In the morning I do a quick git statusto 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.

[Suzanne Aitchison]

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 😂

[Jack Harner 🚀]

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.

[Holy-Elie Scaïde]

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

[Joshua Tzucker]

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:

• Branching
  • Keeps things clean and there is "no cost"
  • Trying to do this more as opposed to stashing
• Using tags
• Better commit messages

A neat "trick" I recently learned is how to merge branches without switching to them. Not really needed often, but feels cool to use:

git fetch . {localBranchA}:{localBranchToMergeAInto}

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.