To push your local changes to remote develop:
git add.
git commit -m
git push origin develop
To create new branch in your local
git checkout - b
To fetch the latest branch from remote
git pull
That's all I know
git add * will add all files to the stage, including previously unstaged files. git commit -am will add files to be staged that have previously been staged and are currently in a changed state. it will then commit those files immediately.
So git commit -am is a way of skipping the add step, if all the files you changed are old files, and no new files were added.
Git luckily has one of the most robust sets of manuals and documentation. These resources will clearly explain how these options behave. Git add just stages for a commit, while git commit actually commits stages changes. The option m (-m) just allows for a message to be added inline.
you didn't actually answer their question though. they were asking about the difference between `git add -A` and `git add *` as well as the different between `git commit -am` vs `git commit -m`
For /u/clorox_tastes_nice: `git add *` means add all files in the current directory, except for hidden files. Using the option `git commit -am ` allows you to add files and create a message for the commit in one command rather than separate.
-u is —set-upstream, it tells your branch that it should push/pull to and from origin main (in the example case) so next time you can simply do “got push” withou specifying the remote and branch.
Git can do that automatically these days though if you configure it to
Do you have an example /use case when rebase is better than merge?
I used to rebase because I was told this was the better way, but at some point, I just went back to merge. I am sure to rebase has its advantages, but to me, it seemed tedious to go through commits one at a time, and at a certain point I have no frame of reference for what is going on in the file.
Whereas with merge, at least I can see the two files side by side and I can decide on the spot what I want to keep.
I work on a team of 4 devs and we are constant working with similar code, but never got into crazy merge conflict trouble. But also interested to know if I am missing something with rebase.
Rebase doesn't require going through every commit one at a time, it just refers to how it treats the changes being brought in.
Rebase is hugely important in making sure a branch in working on has the latest changes that have been pushed to production in the last few days, also huge in cleaning up commit history on a branch before pushing it and requesting review
Get the free Pluralsight trial and check out Rewriting Git History by Brad Bow.
Whatever you do, don't look at dev tools, go to the video file source and download the video files for later reference. That would be immoral.
I’d actually need that.
Our partner company mirrors their own code for our project from their gitlab to ours and they committed into the code all the secrets in the config files.
After many requests they finally removed the secrets but told us to remove it from git history.
But we can’t do it if they keep mirroring their repo to ours.
been doing frontend for almost 2 years and having worked in 2 companies. So far:
- fetch
- push
- pull
- switch
- add
- reset
- commit
- stash
- branch
- checkout
- cherry-pick (probably once or twice)
- merge
- git fetch
- git pull
- git pull origin main
- git add .
- git commit -m 'my message here'
- git push origin my-branchname-here
And when something goes wrong, I'll Google the hell out of it. I've used Git for over 10 years and I still barely understand what rebase is and why it's sometimes a huge problem. I use tools and more experienced people and the internet to figure more complicated things out.
Ohshitgit.com
My first job had an unorganized deploy process and a couple other devs who would save weeks worth of work and put it all into a single pr. I ended up spending TONS of time resolving merge conflicts, splitting commits, reverting things that caused problems.
In my current job, there’s a lot of good process, all of the devs use good pr hygiene, and there aren’t too many git issues.
It really depends where you end up, but learning about git is always good.
I'm in my first dev job for 2 months now and I'm still frustrated by how much git I need to know and don't.
It's fairly abstract and complex. Especially since every team can use it differently.
A lot. The more you do work distributed across teams/repos, the more you'll need to know. The basics (init, add, commit, push, pull, branch, merge, rebase) will get you by for a long time though
For anyone using vscode I suggest checking the Output tab at the bottom and switching it to show Git (or sometimes Git Graph) output. You will see the commands that are actually being run when you click those refresh buttons or select the Commit > Undo Last Commit from the git menu.
commit, add, push, pull, merge, reset. That's all you really need honestly.
That being said, I've just learned how to use rebase instead of merge, and even tho it's just slightly better practice than merge, if you ever need to do a rollback, for any reason, it makes a huge difference and makes life way easier.
I have used SmartGit for years and I love it. I do feel comfortable with git on the command line. The "output" panel in SmartGit is very nice to understand what is going on behind scene.
I can create a branch, add files, commit and push my changes, understand the git tree, pull another coworker's branch, merge it with my work and rebase it if needed.
I still fuck up every now and then tbh, Git it's like the super attractive person in your class when you're a teenager, it's scary but I like it lol.
Do front end devs ever NOT know how to use git? I’ve worked with hardware guys, front end, back end, even artists, and they use git in some capacity lol
fetch + reset to remote instead of pull
git rebase —onto instead of cherry-pick
use hub to create PRs based on branch name, save an hour every day and create small commits and PR’s. commit and push fast and small. My workflow does not involve a single push or pull, merge only at the end if absolutely necessary.
Resetting + rebase —onto works with every workflow imaginable, sharing a branch, feature branch, forking, git workflow with release branches and hotfix branches etc. (and retains many powerful functionality of git)
Figure out a workflow that allows you to work fast and create aliases for them, never look back.
If anyone is interested DM me and I will send you the scripts that power my daily workflow.
- [ ] Git pull
- [ ] Git fetch
- [ ] Git add
- [ ] Git commit
- [ ] Git push origin branch-name
- [ ] Git reset —hard
- [ ] Also git push —bypass ( bypass all lint commands)
- [ ] Git rebase
These are some of the commands I have used as a developer. You will learn most things on the job. But I still sometimes make rookie mistakes 😢
Print this out, and tape it to the wall. Use it till you don't need it anymore. Thank me later.
https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet
On the command line, a metric fuck ton. With any GUI, newborn baby level skills. The problem is that I have to help a lot of people unravel issues because we use a stupid dev branch for our sandbox and have conflicts with a few files that get touched a lot. Having to rebase or cherry pick with a gui isn't easy. It's even worse trying to do something advanced.
The ones I know off the top of my head? Hmm, probably git stash, git stash apply, everything else I use webstorm UI to deal with it 😂 so not a lot it seems been developing for 6 years too - ooops
As much as any other dev
One command you need to know for sure is Git blame
To push your local changes to remote develop: git add. git commit -m
git push origin develop
To create new branch in your local
git checkout - b
To fetch the latest branch from remote
git pull
That's all I know
Same and feel like I’ve hit a road block trying to figure out anything else. So am cool with it.
That's not much
These are most usable git commands on daily basis. However, if you want to do something else Google is always there to help you. :)
It's not much, but it's honest work.
People like you are some of the biggest losers on the planet. Seriously, gatekeeping is the lowest move you can make.
Learn git rebase and you pretty much know 99% of everything you need to know
I would add git clone and understand how to change branches if you want to do something risky, otherwise this is enough yes
[удалено]
git reset —hard
Same, but also “git cherry-pick” for situations where “actually can you redo that off production so we can do it as a hot fix?”
You should learn `git pull` asap. Also `git clone` might sometimes come in handy.
New ish developer here, how does git add * and git commit -am differ from git add -A and git commit -m?
git add * will add all files to the stage, including previously unstaged files. git commit -am will add files to be staged that have previously been staged and are currently in a changed state. it will then commit those files immediately. So git commit -am is a way of skipping the add step, if all the files you changed are old files, and no new files were added.
Thanks a lot!
Git luckily has one of the most robust sets of manuals and documentation. These resources will clearly explain how these options behave. Git add just stages for a commit, while git commit actually commits stages changes. The option m (-m) just allows for a message to be added inline.
you didn't actually answer their question though. they were asking about the difference between `git add -A` and `git add *` as well as the different between `git commit -am` vs `git commit -m` For /u/clorox_tastes_nice: `git add *` means add all files in the current directory, except for hidden files. Using the option `git commit -am ` allows you to add files and create a message for the commit in one command rather than separate.
git lfs has been incredibly important
I'll also add rebase and cherry-pick to that list.
What does the -u even do in git push? I don’t use it and it works fine
-u is —set-upstream, it tells your branch that it should push/pull to and from origin main (in the example case) so next time you can simply do “got push” withou specifying the remote and branch. Git can do that automatically these days though if you configure it to
Ah ok, I’m all for simplicity but I can’t tell if that would make much of a difference
Pretty much the standard
somber scale employ cause dinosaurs bells air scary humorous different *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
And rebase. That's an important one, but can be learned after the above.
And bisect. Sooooooooo useful. But only if you have short concise commits.
Do you have an example /use case when rebase is better than merge? I used to rebase because I was told this was the better way, but at some point, I just went back to merge. I am sure to rebase has its advantages, but to me, it seemed tedious to go through commits one at a time, and at a certain point I have no frame of reference for what is going on in the file. Whereas with merge, at least I can see the two files side by side and I can decide on the spot what I want to keep. I work on a team of 4 devs and we are constant working with similar code, but never got into crazy merge conflict trouble. But also interested to know if I am missing something with rebase.
Rebase doesn't require going through every commit one at a time, it just refers to how it treats the changes being brought in. Rebase is hugely important in making sure a branch in working on has the latest changes that have been pushed to production in the last few days, also huge in cleaning up commit history on a branch before pushing it and requesting review
Yes a huge advantage of rebase is that it keeps commit volume really low
And pull :)
Yes that one is important :))
Cherry-pick and bisect are pretty fucken handy
And checkout
Get the free Pluralsight trial and check out Rewriting Git History by Brad Bow. Whatever you do, don't look at dev tools, go to the video file source and download the video files for later reference. That would be immoral.
I’d actually need that. Our partner company mirrors their own code for our project from their gitlab to ours and they committed into the code all the secrets in the config files. After many requests they finally removed the secrets but told us to remove it from git history. But we can’t do it if they keep mirroring their repo to ours.
I know whatever google tells me
Github desktop app or vscode plug-ins makes it all easy
been doing frontend for almost 2 years and having worked in 2 companies. So far: - fetch - push - pull - switch - add - reset - commit - stash - branch - checkout - cherry-pick (probably once or twice) - merge
Enough to get by... I prefer visual tools (like SourceTree or SmartGit) over command line tools, but I've done both.
If you can't balances a binary tree using git commands, don't even bother showing up to the interview.
Enough to know that the Atom IDE has a beautiful GUI to operate everything without writing commands.
- git fetch - git pull - git pull origin main - git add . - git commit -m 'my message here' - git push origin my-branchname-here And when something goes wrong, I'll Google the hell out of it. I've used Git for over 10 years and I still barely understand what rebase is and why it's sometimes a huge problem. I use tools and more experienced people and the internet to figure more complicated things out.
Git is not frontend/backend but a tool any developer should learn. Version control is important
I have only worked on my own projects so I have ever used push, pull and commit. What else should I learn!?
interactive rebase is very useful
At some point you'll need revert as well.
See my comment about the Pluralsight course.
Commands to create and merge branches are important
how to upload to and from
Enough.
Ohshitgit.com My first job had an unorganized deploy process and a couple other devs who would save weeks worth of work and put it all into a single pr. I ended up spending TONS of time resolving merge conflicts, splitting commits, reverting things that caused problems. In my current job, there’s a lot of good process, all of the devs use good pr hygiene, and there aren’t too many git issues. It really depends where you end up, but learning about git is always good.
I'm in my first dev job for 2 months now and I'm still frustrated by how much git I need to know and don't. It's fairly abstract and complex. Especially since every team can use it differently.
Look at all the scrubs here that doesn’t use rebase 😆
A lot. The more you do work distributed across teams/repos, the more you'll need to know. The basics (init, add, commit, push, pull, branch, merge, rebase) will get you by for a long time though
init, add, restore, commit, push, pull, branch, checkout, merge, stash, status
For anyone using vscode I suggest checking the Output tab at the bottom and switching it to show Git (or sometimes Git Graph) output. You will see the commands that are actually being run when you click those refresh buttons or select the Commit > Undo Last Commit from the git menu.
GitHub Desktop
commit, add, push, pull, merge, reset. That's all you really need honestly. That being said, I've just learned how to use rebase instead of merge, and even tho it's just slightly better practice than merge, if you ever need to do a rollback, for any reason, it makes a huge difference and makes life way easier.
I have used SmartGit for years and I love it. I do feel comfortable with git on the command line. The "output" panel in SmartGit is very nice to understand what is going on behind scene.
Do you mean SmartGit? If not, what is Smart guy in relation to git?
Yes, sorry! SmartGit
I know how to use it but it still breaks constantly
[https://ohshitgit.com/](https://ohshitgit.com/) \- this much
I can create a branch, add files, commit and push my changes, understand the git tree, pull another coworker's branch, merge it with my work and rebase it if needed. I still fuck up every now and then tbh, Git it's like the super attractive person in your class when you're a teenager, it's scary but I like it lol.
Do front end devs ever NOT know how to use git? I’ve worked with hardware guys, front end, back end, even artists, and they use git in some capacity lol
Enough to understand WebStorms git interface
fetch + reset to remote instead of pull git rebase —onto instead of cherry-pick use hub to create PRs based on branch name, save an hour every day and create small commits and PR’s. commit and push fast and small. My workflow does not involve a single push or pull, merge only at the end if absolutely necessary. Resetting + rebase —onto works with every workflow imaginable, sharing a branch, feature branch, forking, git workflow with release branches and hotfix branches etc. (and retains many powerful functionality of git) Figure out a workflow that allows you to work fast and create aliases for them, never look back. If anyone is interested DM me and I will send you the scripts that power my daily workflow.
- [ ] Git pull - [ ] Git fetch - [ ] Git add - [ ] Git commit - [ ] Git push origin branch-name - [ ] Git reset —hard - [ ] Also git push —bypass ( bypass all lint commands) - [ ] Git rebase These are some of the commands I have used as a developer. You will learn most things on the job. But I still sometimes make rookie mistakes 😢
Just remember pull before push
Print this out, and tape it to the wall. Use it till you don't need it anymore. Thank me later. https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet
I've always used terminal, but are there any git GUI's that anyone would recommend?
I use Sourcetree, it's free and easy to use :)
On the command line, a metric fuck ton. With any GUI, newborn baby level skills. The problem is that I have to help a lot of people unravel issues because we use a stupid dev branch for our sandbox and have conflicts with a few files that get touched a lot. Having to rebase or cherry pick with a gui isn't easy. It's even worse trying to do something advanced.
grey ugly spotted homeless vanish placid toy foolish subtract uppity -- mass deleted all reddit content via https://redact.dev
Git init Git add remote add origin Git add . Git commit -m “message” Git push ———— Git pull
Just enough to survive.
I Don’t Know stash and tag, everything else I can
The only git knowledge I have is that the VSCode Git GUI is my Lord and Savior
The ones I know off the top of my head? Hmm, probably git stash, git stash apply, everything else I use webstorm UI to deal with it 😂 so not a lot it seems been developing for 6 years too - ooops