12 ms·
Git tips to stop you getting fired
- c-oreills 14y agoAlso, any code that isn't pushed to a remote doesn't exist. Or, it won't when your hard drive unexpectedly fails and your feature branch disappears. =)
- gte910h 14y agoYou should be using file backup on any system with code on it. It is so cheap to do this today, it is a no brainer. Apple Time Capsule, Crashplan Pro, etc.
- nathan_long 14y agoThe only non-replacable thing on my development machine is the code. It makes more sense to me to always push my feature branches up to the server, which is backed up, than for each dev machine to be backed up separately.
- philjackson 14y agoI suppose if you were really paranoid you could use 'git archive' to snapshot to dropbox.
- ryanpetrich 14y agoPushing to dropbox is a very common part of my workflow: https://github.com/rpetrich/git-dropbox https://github.com/rpetrich/git-dropbox It's not strictly safe to use from multiple machines, but as a simple backup it's very convenient.
- sneak 14y agoAll of my git repos live in a subdirectory of my dropbox as-is. I also compulsively push to remote. I also use Time Machine. I also rsync my home directory to an external drive in case Time Machine implodes. I also rsync my home directory to a server in another hemisphere. Come at me, bro.
- imissmyjuno 14y agoThe last point is a great idea. I've had my NAS Time Machine backup get corrupted and TM forcing me to redo a full backup a few times now to the point of me abandoning it entirely..
- eli 14y agoIt's been a while, but storing .git files in Dropbox didn't work out so hot for me. Make changes in two places and Dropbox resolves the conflict by renaming one file to "X (Eli's Conflicted Copy)".... Git really doesn't expect to see it's internal files renamed like that.
- sneak 13y agoThe question then becomes "Why do I need more than one computer accessing git when computers now weigh 1kg?"
- Davertron 14y agoIf you rebase a lot, then you want to avoid pushing code constantly until you get it where you want it.
- jimktrains2 14y agoOne of the many reasons not to rebase code that's been pushed already.
- Davertron 14y agoAs far as I know there's only one reason not to rebase code that's been pushed. My point was that pushing constantly as a backup mechanism isn't an option if you intend to rebase frequently (unless you're the only developer on the project).
- X-Istence 14y agoI have a personal clone of whatever project I am working on, any branches that I publish can be changed at any time using a push -f.
- deleted 14y ago[deleted]
- nathan_long 14y agoDepends on your team. I'm on a small one, and I often rebase and force push a branch I'm working on, because I know nobody else is working on it.
- philsnow 14y agoSo push to a remote feature branch that is named after your username, then rebase the changes in that feature branch onto the 'trunk' branch and push the result ? The D in DVCS is all well and good, but there are business reasons for having a canonical store of all source materials.
- gte910h 14y agoWhy don't you then just backup your dev machine's code directories to another machine? Backup is good because it's automatic. Saving somewhere else is nice too, but it's not really backup.
- lmm 14y agoIt'd be more effort for no gain - and it would encourage me to keep changes locally, which is bad for collaboration.
- gte910h 14y agoThrashing the index with half completed features is ALSO bad for collaboration.
- lmm 14y agoIt's good that my colleagues can see what I'm working on. It's not going to slow them down when they don't want it to, since git only fetches those branches you ask it for. So no, I have to disagree.
- darrickwiebe 14y agoThis command has a mistake in it: ours = "!f() { git commit --ours $@ && git add $@; }; f" it should be ours = "!f() { git checkout --ours $@ && git add $@; }; f"
- philjackson 14y agoThanks, I've used an alias for checkout, "co", which I wrongly expanded when I wrote up the article. I've corrected it. Proofreading is another way not to get fired.
- alekseyk 14y agoLooks like your probation period is over.
- joe8756438 14y agoHas anyone ever gotten fired for making a git or other version control "mistake?" https://news.ycombinator.com/item?id=5513353 https://news.ycombinator.com/item?id=5513353
- joelhooks 14y agoMost certainly. I've witnessed it. It was a really bad mistake though.
- masklinn 14y agoShouldn't the $@ also be quoted? If one of the argument is a quoted file path with a space, the unquoted form is going to see multiple paths.
- aiiane 14y agoAlso note that the 'git add' here is actually completely redundant - 'git checkout <filename>' automatically updates the index with the checked-out version of the file, in addition to the working tree.
- susi22 14y agoI realize that this post is targeted more towards advanced git users but it would be immensely helpful if you could add 1-2 examples to the every section (you only have some for the first section)
- rav 14y agoWith regards to merging, I prefer using a merge tool such as Meld. Whenever you're in a merge conflict, just run git mergetool. Meld is pretty easy to learn as long as you know to use shift-click to delete a chunk and ctrl-click to copy a chunk instead of replacing.
- tterrace 14y agoI don't understand the part about .gitignore not working for passwords.php: because that’s committed too, so then you risk someone forgetting about their valid edits of the file later.
- philjackson 14y agoAh, I've just tried this locally. I was sure an edited, already checked in file would remain 'hidden' if in gitignore. My mistake, will update the article.
- tterrace 14y agoGotcha, I love those "them and us" commands, thanks!
- yxhuvud 14y agoSnapshot stack? Huh. git checkout -b seems a lot simpler.
- Cyranix 14y agoI use this pattern from time to time (and should probably alias it). While checkout -b (or reset --hard <hash>) is good for most cases, I like making a stash entry if I'm in the middle of a logical unit of work and don't want to commit before I do something experimental.
- bumeye 14y agoSimpler indeed. That's actually what stash does internally. I usually don't make a separate branch, but just commit it in the current branch. Then you can rebase or amend later. You never need 'snapshot' if you know rebase -i.
- just2n 14y agoYou can also just `git reset HEAD~1` if you want to have your index reflect the changes rather than just working on top of an empty index in a new commit. My workflow is a --no-verify commit on the branch, then when I come back, just reset to the previous commit and continue. This is pretty much identical to stashing, though I prefer it since it means the part of git I use is smaller.
- leeoniya 14y ago"...sometimes php developers commit configuration files..." needless jab, imo.
- CiaranR 14y agoYeah could easily be applied to Perl dev's too
- leeoniya 14y agohow about "any devs" or even "novice devs". as if there's some class of super-devs that's immune to versioning mistakes, ffs.
- bastijn 14y agoAll phpers are now offended? haha, must be true than!
- leeoniya 14y agololwut? had it said "ruby" or "python", there'd be a shortage of tear gas and cars would be burning in the streets.
- edem 14y agoLet's just abstract away the details and say something like: "...sometimes <arbitrary_programming_language> <arbitrary_programming_job> commit configuration files..."
- brokenparser 14y ago"adverb adjunct noun verb adjunct noun"
- myhf 14y ago
- temp453463343 14y agoOut of curiosity, do a lot of people use CLI git? I personally am much happier losing a little functionality (and all these fancy flags) for a much clearer visual interface - I'm using GitExtensions btw. Am I alone on this?
- jlgreco 14y agoI just ignore the flags that I don't need.
- leeoniya 14y agoi've only used the CLI on Win for features TortoiseGit was missing, though its SVN-ancestry has a lot of terms-clash with the actual Git commands issued under the UI.
- Cyranix 14y agoNot alone, certainly, but almost certainly in the minority. I don't think I've met anyone in person (in five professional years, granted) who uses a GUI for anything Git-related except complex merges or history visualization, both on rare occasion. Not sure why your perfectly reasonable question is getting downvoted...
- zem 14y agoi mostly use the cli, but i use a gui (git-cola) for interactively committing only part of the current diff. it's way better than git add --interactive. also gitk is nicer than tig, though tig is easier to use when sshed into another server.
- adimitrov 14y agoIncremental (interactive) commits are probably best done from within your editor. I use fugitive [1] for Vim, there's magit [2] for Emacs, and probably a plugin for your favorite IDE, or ST2. [1] https://github.com/tpope/vim-fugitive/tpope/vim-fugitive https://github.com/tpope/vim-fugitive/tpope/vim-fugitive [2] http://www.emacswiki.org/emacs/Magit http://www.emacswiki.org/emacs/Magit
- gingerlime 14y agowe're also using a small script[1] that prevents committing debug statements by mistake. We put it as a pre-commit hook and also as a standalone check on our CI. It saved us from embarrassing mistakes in production several times... [1]http://stackoverflow.com/a/14738093/305019 http://stackoverflow.com/a/14738093/305019
- guard-of-terra 14y agoGit power usage looks dangerously like accounting.
- jeltz 14y agoNot all that complicated and follows a simple set of rules?
- Bobby_Tables 14y agoIf you're in danger of getting fired over a commit mistake, you have more and bigger problems than this article can fix. These are good tips, nonetheless.
- malkia 14y agoThere is a bigger chance of getting fired for ordering 10x the amount of food for the team, while they are crunching...
- NeedNoReg 14y agoSeriously, command line for this sort of stuff? Also being stressed over source control when it is not deleting something permanently? Really?
- ultimoo 14y agoThese are great tips. And so is the other post about Git Koans posted here today. I'm a bit of a git fan and while such tips pique my curiosity and delight the git geek in me, is it actually wise to use these on a day to day basis at your job? Doesn't the argument about 'clever code v/s clear code' apply to highly configurable tools like git? While pairing with others or even using a common dev box, I like to use plain vanilla CLI git without intricate aliases, without intelligent git hooks, or other fancy extensions as far as possible.
- charlieflowers 14y agoWhat post about Git Koans? I did a google search, but nothing came up.
- pbiggar 14y ago> Get everything you can into git hooks This is a great idea, and it's one that my company provides: https://circleci.com https://circleci.com. You can run standard tests, but also linters and whatever you want to increase your code quality. Users report higher productivity, and shipping code faster!
- philjackson 14y agoThat's a nice, solid feeling product. I'm going to check it out properly soon.
- pbiggar 14y agoAwesome! Feel free to ask any questions.
- edanm 14y agoDoes anyone here know of a good 3-way merge tool for Git that's available on OSX?
- Aga 14y agoKDiff3 has worked nice for me and it seems to be availabe for OS X too: http://kdiff3.sourceforge.net/ http://kdiff3.sourceforge.net/ (however I have not tested it on an OS X)
- Aga 14y agoA warning about the ours and theirs commands: when you're rebasing, they will do the exact opposite what most people await them to do (thanks to git rebase's implementation). From the git rebase man-page, --merge: Note that a rebase merge works by replaying each commit from the working branch on top of the <upstream> branch. Because of this, when a merge conflict happens, the side reported as ours is the so-far rebased series, starting with <upstream>, and theirs is the working branch. In other words, the sides are swapped. https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html https://www.kernel.org/pub/software/scm/git/docs/git-rebase....
- jogloran 14y agoWhat's the reasoning behind the hack "!f(){}; f" getting shell arguments to work properly?
- Expez 14y agoWhat is the difference between minimal and patience for git diff?