markdown guide
 

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

 
 

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

 
 
 

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): ..
 

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.

 

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

 

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
 

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.

 

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 😂

 

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

 

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.

 

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.

 
git checkout -b feature/blabla # alias gco -b
git add . # alias  ga .
git commit -m "message" # alias gc -m
git push -u origin feature/blabla # alias gp

and someone merges my branch to master. I'm doing:

git checkout master alias gcom
git fetch --all --prune # alias gfap
git branch --merged | grep -v "\*" | xargs -n 1 git branch -d # alias gdmb
 

Most of the time just committing and pushing. Sometimes stash if I started doing something and somebody ask me to fix a bug and what I did was not enough for a commit. Now, with vscode and its good integration with git you don't even have to run the commands but I still do itbecause I don't wanna forget them

 

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.

 

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

 

Personally, I think Git (and other VC software) should only be used for enterprise software and some open-source projects (the ones that are genuinely going to be multi-authored, not merely “posted” on Github).

I see so many posts about using Git for personal blogs (usually with static site generators), simple scripts and dot files, and even for personal writing for books.

It’s serious overkill.

I don’t understand why we have to spell out each commit. It’s a waste of my time in 99% of those latter cases.

Even when doing web development, it’s incredibly time-consuming. Plus the interruption to the thought process.

Yes, that once in a blue moon situation might be helpful to have a “rewind”, but even so, I don’t think I’ve ever rewound to a commit 50+ layers back by looking at the log. Usually, you just want a decent undo.

If you’ve ever used Apple’s Time Machine, that’s literally what I envision as the best way to code. Every Cmd/Ctrl-S is just an automatic “version” that is not only used by the system as a capture/commit, but the diffs are auto-recorded by the system as the commit message.

I mean, seriously, these days, except for cutting edge system builds, what are we writing? Uh, HTML, PHP, JavaScript, CSS, blah, blah, blah.

Why do we need to write a commit message that says “Fix right float for small screens”? Or “Add new blog post”, or “Refactor .amazing-class”, or the worst and dumbest of all, “First commit”...???

Again, if it’s an enterprise software or you are working on rocket ship software for Elon Musk, or you really think that the (eventual) six contributors to your newly posted open-source software are really gonna go back and re-read 500 previous commit messages, then by all means, git commit your life away.

But we have gone nuts with it.

It’s tired, old, clunky software that makes us tell it everything. It was designed to help with complex software development (I think the development of the Linux kernel).

Software should instead do all this for us.

I imagine that all saves are commits and that we could just dial back (like Apple Time Machine) and quickly see highlights on a modern GUI of the computer’s best guess as to what was changed (“+2 lines to .amazing-class”, or “-4 lines from

”, or “add new function ‘saveMessage()’”, or “modify function ‘saveMesage()’”).

I envision that the side by side views as you scroll would only show clips of lines that changed from file to file. And that colors across the top edge of each file would indicate things like volume of lines changed (so you could even see at a distance or on a minimap-like thing which changes were more monumental).

For replacing multi-file commits, the system wouldn’t need such pompous declarations as we do now. Are we stupid? We know that fixes involve multiple files often. Can’t the system determine that too?

For “release versions”, I think something as simple as a root project-name.txt document in a version-tracked directory is sufficient for 50%+ of “projects”. It holds meta data about your project. The moment you change the line in it from “version: 0.01” to “version: 0.02”, the system marks all included files at that moment as the release of 0.02. You can roll forward or backward to any release you want. If you want to name your releases, a line in that file that says “release-name: Hancock” is sufficient and then you can start a trend of making all your releases tied to famous jazz musicians (ahem!).

For simple branching, seriously, create a new directory. Call it whatever. Copy all your files. The system can see you just wrote (copied) 2,400 files in a directory that (duh!) exactly match the ones in the root project directory. Even if you don’t update the project-name.txt metadata, the system knows it’s a new “branch” and will treat and track it as such. You can work on it or the root or 20 other directories. Why do we have to tell Git what branch we want to “checkout”? Just open and edit whatever files you want. Run multiple “servers” on every “branch” in your project simultaneously on different browser tabs. Compare and contrast. Fun for the whole family.

If you want to “merge” a “branch” back into “master”, you just move the files back into root. That’s right! You just overwrite the “master” file. The system sees what you’re doing. It’s not stupid. It knows from whence that file was born (from “master”) and where it is now going. You can “undo” by rolling back. No big deal at all. Don’t want to “delete your branch”? Just copy the files instead of moving them. Or copy first, and then delete the folder/branch.

Don’t tell me that a project with 20 branches will clog up a hard drive. If your project is that big, you probably should be using Git or something similar. 90% of projects are less than a few MBs. What century are we in? Even with images, let’s burn up SSD space rather than waste our precious time on earth trying to figure out where HEAD is pointed and typing out commit messages.

What about sharing? Just copy and send to someone else. They get the same “undo” and “commit messages” and “branches”. Send via FTP, thumb drive, or some (yet to be developed) central repo system. If they create “branches”, they could quite literally email you their changed files along with some email text as to what they changed and that would be your “pull request”. You copy them into the “branch” directory they created, test it out, and then “merge” as above.

Syncing to a central repo would be automatic and ongoing in the background. For all participants. As soon as they are online. Why we mess with fetch and clone and all that makes me think we are just monkeys doing the bidding of some unseen puppet master who’s chief concern is to keep us typing rote commands so we can become complacent servants of a shadow government. But I digress.

Admittedly, all of this doesn’t cover all use cases of Git. But it also eliminates about 80% of the PITA micromanagement that Git places on small developers and teams. I don’t have (yet) solutions for all use cases. This is for the situations described in the first paragraph and for small to medium-sized small team projects.

Bottom line: our computers are not working nearly hard enough for us.

 

start the day by doing checkout of develop branch and pulling any changes. Next I'll checkout 'mine' branch and merge develop onto it before getting to work. Commits take place when I complete a unit of work or need to pull changes from somebody else. I've been using broken commits lately and amending them with follow up to fix the issue. After work is complete then I move back to develop and pull before merging my work onto develop and pushing it up to remote.

Note: I tend to trust IntelliJ with my adding and merging.

 

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.

 

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

 

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.

 

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!

 

In the evenings I like to relax by using git clone on a fresh Flatiron coursework repo.

 

I stick to the mantra of commit small, often. If anything goes wrong, I can easily revert specific changes!

Besides that, I embrace Git Flow and the basic commands including rebase!

 

I do this too. Whenever I get to a small “milestone” I push my changes in case I need to go back 👌🏼

 

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 the master branch on my personal projects.

 

git status
git add
git commit -am
git checkout -b new-feature
git push
git pull from the master branfh if I merge my own pull request on GitHub
git merge if therr are conflicts on my merge 😀

 

If my colleagues has pushed some changes:

git stash
git pull --rebase
git stash apply

😅😁

 

Following the git flow and I have git cheat sheet in case I need help, so I avoid having to google the same questions over and over... Which can be time-consuming...

 

ohshitgit is a browser keyword and shell function to open that page, plus I have a git alias for "fuck-this-noise" which nukes and re-clones the current repo...

 
 

It’s cool seeing how all the developers are using git.

 
 

GitHub Flow for branching.
Jenkins builds most stuff (migrating everything now) and handles deploys.
Peer review PRs or I step in and specifically code review "architected" things.

 

add commit push mainly with creating branches.

Also most of the times have to use rebase, fetch and stash.

 

Branch, add, commit, push, pr/merge & delete remote, delete local, repeat.

 

oh-my-zsh aliases make it easy for me: gcb, gaa, gcmsg, gp

 
 

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.

 
 

The basic, add commit push, and the rare checkout. A lot of merge. Very less revert.

Classic DEV Post from Jan 25

What Bootcamp did you attend and would you recommend it?

What Bootcamp did you attend and would you recommend it?

Ben Halpern profile image
A Canadian software developer who thinks he’s funny.