Time for #DevDiscuss
Tonight's topic is git tips and workflow.
Let's start with some jumpoff questions:
- What tips do you have for good git flow?
- What are your team's best practices?
- Why is git such an ongoing mystery for so many developers?
My number one tip: donāt feel guilty about using a GUI. Seriously, if that works for you, do your thing. You may occasionally need to break into the CLI, but you donāt need to feel bad about not being a l337 g1t CL1 hax0r. #DevDiscuss
Time for #DevDiscuss
Tonight's topic is git tips and workflow.
Let's start with some jumpoff questions:
- What tips do you have for good git flow?
- What are your team's best practices?
- Why is git such an ongoing mystery for so many developers?
Any git workflow is going to have its strengths and weaknesses. But for me, a trunk-based development approach with short-lived branches and PRs hits the sweet spot. #DevDiscusshttps://t.co/Ne5RQxQvjs
Time for #DevDiscuss
Tonight's topic is git tips and workflow.
Let's start with some jumpoff questions:
- What tips do you have for good git flow?
- What are your team's best practices?
- Why is git such an ongoing mystery for so many developers?
Time for #DevDiscuss
Tonight's topic is git tips and workflow.
Let's start with some jumpoff questions:
- What tips do you have for good git flow?
- What are your team's best practices?
- Why is git such an ongoing mystery for so many developers?
One recommendation I have from my personal experience: even if your project doesnāt require a git flow you should put one in place. Having one and not needing it is much better than needing one and not having it. #DevDiscuss
Time for #DevDiscuss
Tonight's topic is git tips and workflow.
Let's start with some jumpoff questions:
- What tips do you have for good git flow?
- What are your team's best practices?
- Why is git such an ongoing mystery for so many developers?
Why trunk-based development? I've found it greatly reduced merge conflicts, helps uncover integration bugs earlier, and forces some good practices: working in small batches, discreet changesets, tests, CI, etc... #DevDiscuss
Also, if you can, use the command line tools over a GUI. You will gain a far better understanding. GUIs abstract out the complexity but they make it seem much more mysterious than it needs to be. #DevDiscuss
Time for #DevDiscuss
Tonight's topic is git tips and workflow.
Let's start with some jumpoff questions:
- What tips do you have for good git flow?
- What are your team's best practices?
- Why is git such an ongoing mystery for so many developers?
Mainly just use git as a dedicated backup tool. Only really git by myself, so I generally just work on master (although I have started working on a develop branch) and commit every time I'm done working for the day (I KNOW)
Teach me to be better #devdiscuss, you're my only hope
Time for #DevDiscuss
Tonight's topic is git tips and workflow.
Let's start with some jumpoff questions:
- What tips do you have for good git flow?
- What are your team's best practices?
- Why is git such an ongoing mystery for so many developers?
git is a powerful low-level tool that allows us to develop in all sorts of different styles and still put things together in the end. But it's as complex as the problem it solves.
The DEV git tag is a splendid resource for ongoing learning https://t.co/gx6hbZc7Hc#DevDiscuss
Yeah I started with SourceTree as a GUI and it helped a lot. Once I got solid footing I went to command line, makes it easier for more complex tasks like fixups and rebases #devdiscuss
In reply to
@MetroNorthRider, @daveaglick, @ThePracticalDev
Focus on understanding:
git init
git add
git commit
git push
git pull
first. Use them for a while, then worry about branching and undoing things later.
#DevDiscuss
Main rule is to always keep the master stable. My team also uses individual branches for each task, it helps us to keep things under control. #DevDiscuss
Was just talking about this earlier at @DevOpsDaysPDX, but the thing that made me comfortable with Git was learning how to fix mistakes. Learn about āgit resetā and āgit reflog.ā #DevDiscuss
Time for #DevDiscuss
Tonight's topic is git tips and workflow.
Let's start with some jumpoff questions:
- What tips do you have for good git flow?
- What are your team's best practices?
- Why is git such an ongoing mystery for so many developers?
Git is one of those things you could read 100 books on, but you just have to jump in and fuck stuff up a bit in order to REALLY learn it #DevDiscuss
That being said, these are my fave resources for un-fucking stuff I fucked in git:
https://t.co/rE1oQOpkEehttps://t.co/9ZbY181Jqf
Time for #DevDiscuss
Tonight's topic is git tips and workflow.
Let's start with some jumpoff questions:
- What tips do you have for good git flow?
- What are your team's best practices?
- Why is git such an ongoing mystery for so many developers?
Here are some of my favorite tips when using git:
1) Take your time to write descriptive commit messages
2) Use 'git blame' to lookup when lines of code changed, not to lookup who to blame
3) After you add files, use 'git diff --staged' to see what you're committing
#devdiscuss
Pull Requests are your friend. Interactive code reviews mean not just discussion but iterative updates to the proposed change. A PR starts as a suggestion and forms into an opinion.
#DevDiscuss
Avoid long-running branches. Merging smaller changes to master more frequently means fewer opportunities for gnarly merge conflicts to pop up. #DevDiscuss
The biggest hurdle to git is not having a basic understanding of the underlying concepts.
I'm the author of the screencast 'Git In-depth' on @FrontendMasters. I teach just enough internals for it to all make sense. https://t.co/w51g3lUCiR#shamelessplug#DevDiscuss
Also, something that helped me learn Git was making a garbage repo full of some random text files that I could experiment with. It let me try things without the pressure of screwing up our real repos or impacting my coworkers. #DevDiscuss
Never create an alias that overwrites a git command just to add a default options. If you do youāāll end of up doing the wrong thing some day and not know why #DevDiscuss
Biggest tip: even if it's horrible and frustrating, persist in learning git. The Pragmatic Programming has a whole chapter on source control, so you know it's a vital evergreen skill for devs. Worth the struggle. #devdiscuss
git is truly fabulous technology. Even if there is some future where we don't literally use git day-to-day, it's likely to power the underlying logic. #DevDiscusshttps://t.co/JhRjsbx2oI
Protect your branches (no direct pushes/enforce PRs), teach devs how rebase works, learn the command line and it's not for everyone, but aliases can speed up your workflow, https://t.co/nwai7eEx4D#DevDiscuss
Like most programming problems, the simple tasks you do a lot (add, commit, push) become easy, and the hard stuff (complicated conflicts) stays hard. But, google and other devs are you friend. Nothing wrong with not having it all memorized. #devdiscuss
I'm going to continue this thread with git-related stuff that I struggled with at first #DevDiscuss
If you `git commit` you enter the hell that is vim. To write a message, hit the 'i' key, THEN type. To leave: 'esc' > ':wq' > 'enter'. If you leave it empty, it aborts the commit.
Agreed. No matter how often I use reflog, I need to look it up. Only difference is I save the stuff I look up into a note to save some time google searching haha #devdiscuss
One more thought: Resolving conflicts will always be tough, but it may not be your lack of git skills causing the problem. The git workflow your team uses and the way the work is divided amongst your teammates matters too.
#devdiscuss
Me too. There are days I've gotten tangled up in a git mess where the easiest solution has been to delete local repository and check it out again. Sigh. I swear every time I figure out something new with git, something else I think I knew no longer makes sense. #devdiscuss
If you hate using vim to write your git commit messages, you can change your editor! https://t.co/H2FJPauKGi
You can use Visual Studio Code, Sublime, TextMate, whatever you want.
#devdiscuss
And if there's a text editor you'd prefer to use instead of vim when this happens, you can set the `core.editor` variable accordingly. Values for common editors both CLI (vim, emacs, nano) and GUI (Sublime, Atom, TextMate) here: https://t.co/1uQJmegdA3#DevDiscuss
Oh -- @code is excellent for Git stuff too.
* I love GitLens's inline Git Blame: https://t.co/v79O7yK5nu
* Its visual merge conflict handling is awesome.
* Love the source control GUI builtin.
* And now, there's pull request handling https://t.co/kKK9bfOEO7#DevDiscuss
You can make your life a LOT easier by setting up an SSH key so you don't have to type your password every time you push (which is dumb). This site gives a pretty good overview on what SSH is and how to set up a key (#worthit): https://t.co/nbH8cNebo5#DevDiscuss
I think not messing with the master when doing git stuff is one of the good practice because making changes, testing the change and making sure the code is perfect before merging to master won't let the production down. DevOps Inner: {{ Oh, Not downtime again :P }} #DevDiscuss
Time for #DevDiscuss
Tonight's topic is git tips and workflow.
Let's start with some jumpoff questions:
- What tips do you have for good git flow?
- What are your team's best practices?
- Why is git such an ongoing mystery for so many developers?
Time for #DevDiscuss
Tonight's topic is git tips and workflow.
Let's start with some jumpoff questions:
- What tips do you have for good git flow?
- What are your team's best practices?
- Why is git such an ongoing mystery for so many developers?
I screwed up a rebase, had a branch with around two dozen duplicated commits, and it got pushed to master. It was rolled back in ten minutes, so no harm, but I was FREAKING OUT. I thought I'd ruined our entire app. Almost never messed up rebases after that #devdiscuss
You should leave a descriptive message with each commit. #DevDiscuss
At work, we use the following loose template:
Name/number of the Jira story
What code did I remove/add?
What impact does this have on the behavior of the app?
Why did I change it?
Is any followup work needed?
A project where multiple branches on a repo were deployed as stand alone apps... awful to keep all the versions up to date and everything on track #DevDiscuss
A merge conflict on a feature branch branched off another feature branch caused by a force commit of a poorly handled merge conflict that was then sloppily git commit--ammend-ed.
#DevDiscuss
If you've been making edits to some shit and all of a sudden go "FUCK, I forgot to switch branches" BUT you HAVEN'T committed yet, you can totally just `git checkout` the right branch and all of your edits will move over. #DevDiscuss
A long time ago I wrote a āgithub for beginnersā post that I send folks to who donāt need/want to get crazy with the console, maybe still helpful to someone!
https://t.co/echCJMOAoF#DevDiscuss
git is a powerful low-level tool that allows us to develop in all sorts of different styles and still put things together in the end. But it's as complex as the problem it solves.
The DEV git tag is a splendid resource for ongoing learning https://t.co/gx6hbZc7Hc#DevDiscuss
The best part of using a Jira issue ID in your commit: smart commits if GitHub/Bitbucket/GitLab are app-linked to Jira. (Aka they show up in the dev panel) #devdiscuss
Working locally means you can do whatever you want. That's the beauty about git. You eventually discover the real power of git, working locally (even offline) and learn to fix/edit local commits (rebasing). I have written several articles: https://t.co/5N1ya6ZMGy#DevDiscuss
Another fun one was when someone cherry picked a coupla commits then forced pushed directly to master and basically nuked everyone else's feature branches.
#DevDiscuss
If you've already committed, don't panic (you've got your towel with you, right?). Just checkout the branch you're meant to be working on and then `git cherry-pick [commit number]` the stuff you committed to the wrong branch. #DevDiscuss
More info: https://t.co/2SGjyDT5sV
Git has a lot of potential workflows, and they all kinda work and I will use all of them.
One tip I try to do is create small commits. Sometimes I'll send 10 commits for review at a time, each changing a small thing. It makes it easier on the reviewers #DevDiscuss
Time for #DevDiscuss
Tonight's topic is git tips and workflow.
Let's start with some jumpoff questions:
- What tips do you have for good git flow?
- What are your team's best practices?
- Why is git such an ongoing mystery for so many developers?
My huge git rebase screw-up is a large reason why I wrote my @ThePracticalDev post about the git rebase intro I wish I had. I've learned git the same way I learned the rest: make a mistake, learn from it, write about it, share it, and move on. https://t.co/oHZ2NHWyUU#devdiscuss
Following on this last point - you can get a good approximation of the network display on the command line with this:
git log --oneline --decorate --graph --all
#DevDiscuss
For that last one, there are two big mysteries:
1) the internal data structure/mental model
2) the git(1) CLI
The former is actually pretty easy; once you have that down, it's much less painful to hunt down how to get the CLI to perform those repo transformations.
#DevDiscuss
I've recently started to get a better understanding of the basics of git.
I realized how important it is to write commit messages and recommend this resource
https://t.co/Lu6ckrpf6W#DevDiscuss
Honestly, though, cherry-picking, squashing, etc. is a pain in the ass and best to avoid if you can. `git status` shows the current branch, changed files, files staged for commit, etc. Save yourself time & tears by always `git status`-ing before committing/pushing #DevDiscuss
I didn't fully appreciate the power of git until I realized that "git is an editor for your commits."
This article dramatically changed the way I use git, which forever changed the way I code:
https://t.co/on9yPro7Lc#DevDiscuss
If you're going to do git shit in the terminal and not use a GUI, you need to know command line basics. #DevDiscuss
This zine is an excellent intro: https://t.co/13z85EOsmc
i'm honestly surprised so many people have such a tenuous grasp of git. i realize people are at different levels &c but it was like the first thing i had to learn as a professional programmer. #DevDiscuss
I'm working on an app to automatically generate social media images for blog posts and the like. If anyone's interested in testing it out when it's ready, I'd be grateful. #DevDiscuss
I'm keeping track of my newsletter subscriptions this week in this thread if anyone wants to follow along or recommend theirs!
#DevDiscusshttps://t.co/4OULtsEmB3
I get so much information from newsletters each week -- they are my primary source of new information. I'm going to start a thread here listing them as I get them so I don't forget any!
I do have one unrelated to git. I wrote a post on taking notes on everything with a link to my note repo. I recently moved that repo to Jekyll to be more accessibility and shareable! See it here (custom domain not set yet) - https://t.co/sG8XSlgEYd#devdiscuss
is it just imposter syndrome? like you don't have to "get" it to use it...i don't know shit about physics but i can assemble an ikea bookshelf #DevDiscuss
If there's some aspect of git I've never used before, I'll still create a junk repo, add enough fake history & branches for testing, then tar up a snapshot archive of the repo and wantonly plow forth.
If it works, yay.
If not? š£ it and restore the repo from the .tgz
#DevDiscuss
