DEV Community

Ben Halpern
Ben Halpern

Posted on


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?

Top comments (42)

ashleemboyer profile image
Ashlee (she/her)

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

ben profile image
Ben Halpern

What about branching practices?

ashleemboyer profile image
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.

liyasthomas profile image
Liyas Thomas

he always push to master πŸ€“

raymag profile image
Carlos Magno

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

juristr profile image
Juri Strumpflohner • Edited

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 ( 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): ..
martyhimmel profile image
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. πŸ˜„

jsn1nj4 profile image
Elliot Derhay • Edited

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 \
$(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).


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.

s_aitchison profile image
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 πŸ˜‚

andrewbrown profile image
Andrew Brown πŸ‡¨πŸ‡¦ • Edited

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
_bigblind profile image
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.

skydevht profile image
Holy-Elie ScaΓ―de • Edited

if (no current task) goto New Task
Old Task: gco <branch-name
goto work
New Task: gcb <branch-name>
(... 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 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
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

joshuatz profile image
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.

jackharner profile image
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.

edmistond profile image

My typical day is staging, committing, pushing, pulling. All pretty straightforward. Sometimes a bit of rebasing before I push to remote if I want to clean up the history to make it a little more coherent.

It's the atypical days that are more interesting, in all senses of the word. :) I've had rebases from master go horribly, horribly wrong, to the point I had to delve into the reflog to undo the whole process and start over.

Despite being (relatively) comfortable with all of that, I still have to keep looking up the command to check out a remote branch into a new local branch just to make sure I'm not about to do something horrible to my repository.

rhymes profile image

I mostly pull from master, checkout a feature branch which could be brand new or ongoing, I push to its origin and rebase it from master if needed.

Before pushing I obviously have to check the diffs, then add things to the staging area and if everything is okay I commit with a message.

Seldom I revert or undo some changes or navigate through the logs.

I also prune local and remote branches regularly.

Finally at the end of the week I take a look at the logs to refresh my memory about what has happened.

This is my flow on DEV's code.

jesstemporal profile image
Jessica Temporal

add -p, commit, checkout (with -b sometimes), push and commit --amend mostly for all the typos I'm prone to making lol

thefern profile image
Fernando B πŸš€

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.

jessekphillips profile image
Jesse Phillips • Edited

git gui
git fixup
git rebase -i
git rebase -i

I actually spend a lot of time looking at other's history. Code review, tracking down the cause of a bug.

From that I do spend a lot of time organizing my changes so other's can review and we have good records of why things are changing (better records).