DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 963,864 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
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)

Collapse
 
ashleemboyer profile image
Ashlee (she/her)

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

Collapse
 
ben profile image
Ben Halpern Author

What about branching practices?

Collapse
 
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.

Collapse
 
liyasthomas profile image
Liyas Thomas

he always push to master πŸ€“

Collapse
 
raymag profile image
Carlos Magno

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

Collapse
 
juristr profile image
Juri Strumpflohner • Edited on

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): ..
Collapse
 
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. πŸ˜„

Collapse
 
jsn1nj4 profile image
Elliot Derhay • Edited on

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.

Collapse
 
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 πŸ˜‚

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

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
Collapse
 
_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.

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

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

Collapse
 
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.

Collapse
 
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.

Collapse
 
edmistond profile image
edmistond

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.

Collapse
 
rhymes profile image
rhymes

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.

Collapse
 
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

Collapse
 
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.

Collapse
 
jessekphillips profile image
Jesse Phillips • Edited on

git gui
git fixup
gitk
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).

Join the One Year Club

You can earn this badge by being a registered member of the DEV Community for at least one year. Create an account and get started today.