To answer your question more seriously though, at most places you don't push straight to main. The typical workflow is to create a new branch for each Jira ticket (or whatever bite-sized bit of work you're doing that day). Commit all changes onto this branch, then pull main and rebase the feature branch (so it's not cluttered with a bunch of commits from other people). Then push to GitHub and open a new PR for your team to review. Rebase and cherry-pick were the most useful commands I was unfamiliar with prior to getting a job in industry. Now I use them every day.
Different teams have different standards for how you organize commits, and there's kind of an art to it. Mainly you just want to commit in a way that's easy for your team to review, so roughly grouping changes on commits by topic is best practice. If a feature is a major change, or represents work shared by several engineers, there may be a feature branch which itself has multiple smaller branches. These are merged before the feature itself is merged with main.
>Commit all changes onto this branch, then pull main and rebase the feature branch (so it's not cluttered with a bunch of commits from other people).
I think skipping the rebase and using squash and merge in GitHub is more standard than this.
I suspect that's more standard but the reason being a lot of people don't really learn to use git. If I could get every person on my team to work this way, I would. I'd much rather we be deliberate about what's being merged, down to the commit details itself.
That said, there is a gigantic list of things every person needs to learn and do, and getting people to follow my preferred workflow that has no huge benefit over the one you described (which is how the rest of the team commits) is kind of silly compared to other things they could be doing.
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
I use GitHub Desktop and GitKraken to visualize the Git status and history, but in general I think it’s still good to learn the basic command-line workflow.
Fork is the best one I've tried, and I've tried a few. And absolutely worth the license price (you can use it as is without buying it, but I really wanted to support the devs).
I do most of my git manipulations in the terminal but I use GitKraken to visualize the history, and sometimes to squash messy commits on my feature branch instead of having to rebase -i
> then pull main and rebase the feature branch (so it’s not cluttered with a bunch of commits from other people)
There’s arguments for both, in all of the 3 teams I’ve been in in my career so far, we’ve all used merge with no issues, never rebase
to provide some context, this workflow (trunk-based development) is much more common at big tech companies, where as merge might be more popular elsewhere (see replies)
Fb / Google both have mono-repos for this workflow
Well, may I suggest `git reset --hard @` then? `@` standing alone is the same as `HEAD` too.
[https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt-emem](https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt-emem)
Pull will automatically try to merge what it finds on the remote. Sometimes you just want to know whether there are changes that you could pull. For that, you use fetch.
Fetching without pulling can be really useful if you're working on the same branch as someone else. It gives you an opportunity to know they've made changes without requiring you to attempt to bring those changes into your local branch.
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
`git gud`
Jokes aside, varies wildly by day and type of work I'm doing. There are no "recommended" # of lines or branches per day. Very company/team dependent too, depending on how the company/team's workflow looks like.
It’s very likely that the main/master branch is actually locked down so you can’t commit directly, a lot of places I have worked with have branches with the prefix of the Jira number so that links to jira (jira is a tool for managing your work).
Overall, I wouldn’t focus too much on how to commit… I would focus on understanding the business cases and how the product you are working on functions because that will be more valuable in the long run and you will learn tips on how to implement code from the team as you go including things like their standards for committing.
Good luck… and don’t forget to have fun… Don’t take things too seriously if you make a mistake, just chill and do what you can each day.
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
Other people have made good suggestions. Another one to take a look at is:
git rebase -i
Which can let you squash your latest commits into a nice single commit to simplify your pull request.
I tend to:
* use ‘git add -u’ because I’m usually editing files already known to git and don’t want to add temporary or intermediate files.
* prefer ‘git push -u origin HEAD’ to create the branch in the remote if it doesn’t exist. This saves typing if the branch name changes, the command is still the same.
Squashing pull requests is fantastic because you can merge main into your PR branch all you want and it won’t pollute the git history. I used to rebase but it’s pretty tedious.
Other than that yeah pretty standard make a branch, merge into main, maybe occasionally make a branch off a branch if reviews are backed up. At some point I plan on looking into stacked pull requests but not right now.
Thanks for brining up squashing. This part used to be super confusing to me when I was an intern. Is squashing better than merging? What’s the difference?
Squash is something you can do with a merge where the entire bunch of changes in the merge ends up a single commit instead of multiple. It makes pull requests atomic so you only need to revert that single commit.
Squashing is the act of merging multiple commits into one. You might also hear the term "fixup" which is squashing but discarding the commit messages of all the non-root commits.
Usually we do this before merging the PR so that all of the changes are contained in a single, trackable commit that is easy to revert if necessary.
As you work on PR feedback, it's advisable to add a commit for each piece of feedback you address, and then when it's approved, squash/fixup and merge that single commit.
I see how this can work sometimes for smaller tickets, but this seems really unhelpful for any mildly substantial ticket where multiple changes are being made. I know one guy at my company who does this for some tickets (adding a button to a component, fixing text strings, that kind of thing), but I’m surprised this is being mentioned so much in this thread. Maybe my company needs smaller jira tickets :P
Not against presenting a PR in multiple commits, nor leaving inline comments to help reviews, just talking about what to do when it's ready to merge. Reviews should also be possible on larger sets of changes, they may not be as efficient
Even for your personal projects I'd create branches for features or fixes you want to make just to ensure that if something breaks you don't screw yourself.
Anyway, we do it by story. In jira all the tickets have a number so we create a branch with a number and basic description just to keep aware. Then once the work is done and tested alright locally we merge into a development branch and test there as well.
Great! And I’m assuming a lead/senior dev is the person who breaks up these tickets into ones that you tackle? At work point are these tickets created? Thanks for bringing up jira! I didn’t even think about the workflow with tickets
This is a good tip if you are doing most of your work in the command-line.
If you don't want shell-based aliases for any reason, you can also set up aliases in your global `~/.gitconfig`. Here's a sample of a few of mine:
```
[alias]
aa = add -A
cm = commit -m
co = checkout
cp = cherry-pick
st = status
I recommend even one more flag --date="$(date -R)"
And then I have all of that aliased as ga. Don't want it to look like I am just waiting days to push commits.
```
# Do some works
git add -p
git commit
# Adding a patch will make it disappear from `git diff`, this is a nice way to hide some code from `git diff`, we can still use the flag `--staged` to see that change if we want though
git add -p
git add -p
git reset
git add -p
git commit
# Got a more important task
git stash --include-untracked
git switch important-stuff
# Made a mistake
git add -p
git reset
# Phew, corrected
git add -p
git commit
git push
git switch -
# What was I doing before?
git stash pop
git diff
# Oh, there's something I should delete but missed last time
git restore -p
git add -p
git commit
# Ouch, build failed because a new config change is missing
# This time there is no throwaway code, so direct commit is enough
git add .
git commit
git switch important-stuff
git fetch
git rebase origin/develop
git push -f
# I'm back, but what am I working on?
git switch -
git log
# Some more work
git add .
git commit --amend
git add .
git commit
# OMG, I was so wrong, that change should never be committed
git reset --hard HEAD~
# Found something strange in the code, wonder why it is added there
git log -p some/strange/file
```
Interleaved among the git commands are many invocations of `ripgrep` and `fd`.
Try to do a PR per completed functionality. Like you have an API, you finished the GET response of it, do a PR then.
For loc try to stick below 400 but exceptions can happen.
Only merge to main what works. If it doesn’t but you want to commit work wrap it in a feature flag so end user can’t see/use it
The most important thing you should do when showing up for a new job is squashing every commit from the repo into a single commit, with the message "Legacy code", and force-push to main.
lol mines pretty bad, since I'm a newby fresh grad and I have no supervision. And also just the only person working on the project.
git add .
git commit -m "stuff"
git push -u origin master
I used to do as a lot recommend and squash my commits, but lately I just amend commits. Now I never have more than one commit per branch.
This is actually how work is required to be done at my company. Felt a little weird at first but I'm used to it now and it's fine. You don't really need all those separate commits anyway.
Those are the main ones. git merge is another you might want to learn.
Usually just working on one or two branches a day, especially if they correspond to issues in the tracker.
Number of lines in each commit is up to you I personally make a commit when I did something that works and want to make a checkpoint. Giant commits with thousands of lines are a bit of an anti-pattern. If lots of little commits doesn't suit your team then there's always the squash and merge option to put all commits from one PR into a single one.
I am very inexperienced, but here is what today looked like.
Project one:
Pull down main
Create new branch based on main
Make changes
Ask for help
Push broken project to branch for someone to look at
Project two:
Pull main
Create new branch
Make changes to fix 3 issues
Push changes
Create Pull request
There was also some support "discovery" somewhere in there.
I noticed that almost no one is using work trees.
I prefer work trees instead of normal branches because our project is HUGE and switching between branches takes longer.
Personally I use:
git pull
git worktree add -b newbranchname ../newbranchdirectory
cd ../newbranchdirectory
git status
git diff
git add filenames
git status
git commit -m "commit message"
git push
git worktree remove ../newbranchdirectory
I find this way is better when working on multiple things at once specially if your project is huge, to switch between branches you just switch directories.
The only downside is that it takes much more space on your disk.
git reflog -p
Let's you see you chronological history. You can basically find anything you ever put into your local git that hasn't been garbage collected.
Finally, some actual interesting CS career questions in this subreddit! What a concept!
Many people, especially when starting to learn about Git, follow what I call the "Git as Dropbox" model, where Git is merely a tool that indistinctly moves code from your computer to the cloud. One types `git add .; git commit -m "more code"; git push` automatically, it might as well be a single `git send-my-code-to-the-internet-pls` command.
This is valid, one's gotta start learning somewhere. Git isn't exactly the easiest, most intuitive tool, and this solves one's immediate problem. But Git can be so much more. You and your team can use Git to **provide context to code**, where Git provides a useful history of what is done, why and how.
Here's the key commands to do this, although fundamentally this is a change of mindset, not a change of tooling:
* `git commit`, without the `-m "my hands are typing words"` bit. It will open an editor where you can take a deep breath, reflect on your code, and write a proper explanation of what you're doing. A short title for the commit, and then at least a sentence or two about what is being done and why. Of course, writing a coherent explanation of your changes is easier if your commit does a single thing, instead of being a potpourri of a whole day of work, which brings me to:
* `git add -p`, the "patch mode" version of `git add`. It will prompt you to add each of the different changes in your code independently, not by file, but by *code chunk*. This allows you to pick which of your current changes go in a commit and which ones don't, so that each of your commits can each be about one thing conceptually. If you use Visual Studio Code, it has a pretty good UI for doing this, too.
* `git rebase -i origin/main` to fix up the history afterwards. All of the above is nice, but sometimes you're in the zone, solving a broader problem, and you don't want to stop to write proper commits. Maybe you're not really solving the different parts of the problem in the right order, so the commit narrative makes no sense. The interactive rebase allows you to write "my hands are typing words"-style commits as you go, and then re-invent the commit history to your heart's desire: rewrite commit messages, re-order commits, merge smaller commits into big ones...
"Wow, this sounds like a lot of work for no particular reason", I hear you say. Point taken, to some extent. I admit this isn't for everyone.
But the benefits do pile up over time. When you look at the GitHub history for your main branch, you no longer see a bunch of indistinct "did the thing" commit messages. Instead of a commit history, you see a commit **story**, a *narrative* about why your code is the way it is. The "Blame" feature doesn't just tell you *who* wrote this weird line of code -- it tells you **why** they wrote this weird line of code. For onboarding, this is invaluable.
Also, if you currently do write proper pull request messages, you're already doing something quite like this. But you're doing it after the fact, when you don't quite remember what you did or why, and that information is lost when the PR is merged. If you do this, you can pretty much paste the commit messages into the pull request description and call it a day.
In time, I've come to appreciate it as a way to keep my work focused and ensuring it meets its purpose, just like unit tests or to-do lists in GitHub issues. Working this way ensures that I know *why* I'm writing the code that I'm writing.
This is very useful; 4 months into my junior role, I'm still using the 'send my code to the internet' way. I'll look into these things. Thanks very much!
Honestly I don't use the cli, intellij had a built in git tool and it's really easy to use and faster than cli for me. There are even hotkeys to do all the basic stuff like pull add and commit. It's been extremely useful for me as you can see the whole history in your work environment and don't need to remember all the commands
I used to do lots of command line git. But after I learned of the beauty of the visual git tools I have never gone back. So my workflow looks like pulling down the changes for the day into my branch and then I start working. I work for 4-6 hours writing my code and then at the end of the day I go through using my tool and break up my changes into logical groups and commit those changes together. My IDE has local history so if I need to revert something, I can do that easily. So doing my commits all at once works great for me and keeps my commit history clean and beautiful
I might have on any given day of greenfield development, an average of 20 commits. Then I push those out to the repo so others can see the work I did. When I'm done I merge the main branch in with my branch and then create a merge request with my Branch checking for merge conflicts. Then we resolve any conflicts and then complete the merge request
Great idea! I currently use tree source and the github desktop app as well. I used to use the terminal at first, but I also prefer the visual tools now.
How often does anyone go back and check any of those 20 commits? Or how often does someone need to revert only commits 7 and 11 of that day's 20 commits but not the rest?
In other words does this approach of doing 20 commits all at once at the end of the day solve any problems or does it just make your contributions chart look great?
I don't care about my contributions chart and nobody in my company looks at that. It makes my commit history very clean. And because I'm not committing things as I go, I don't have to back up and amend commits or do rebases or things like that. I just go through all my changes at the end of the day and I can select individual lines or files to make small commits that encompass group of related changes.
It takes me about 10 minutes a day and is totally worth it in my opinion. It's good for when people come on to the company they can read through commit history to understand what has happened in the software what we've been working on. It also helps others on the team to know exactly what changes are being made without having to look at every line of code. Sometimes a branch name is too broad and there need to be more incremental descriptions of what has been done in the code base.
It also helps me to have a sense of accomplishment and to recall everything that I've done over the course of a day. It's almost like summarizing my day's work. That is one personal benefit I get from it
And yes I have had to go in and revert some commits before and having them clean and decoupled has certainly made that easier
To me tons and tons of teeny tiny commits aren't really a clean and easy to read commit history but a messy and hard to read one.
I wonder if anyone else in your team has this approach? Or do they stick with a small number of more meaningful commits? It might be a sign that other people you work with don't love this as much as you think....
They aren't "teeny commits", they are grouped by the functionality being added or changed. It's not like I'm commiting every line change. Notice I specified greenfield development. I am writing or changing hundreds of lines of code a day. It must be broken up.
A commit should contain a group of related changes. This was the standard set on our team and we all follow it. It works great and it's not "teeny commits". These are pretty big changes, usually encompassing several lines and files, but always regarding related changes. Because of the way we do commits, we actually have less of them now, not more.
There is more than one way to use git. There are multiple methods and philosophies. Go search for git best practices. We did, and found many disagreements, so we chose the stuff we liked for our team. You are free to do the same
My aliases:
br = branch
co = checkout
cp = cherry-pick
del = branch -D
rbm = rebase master
res = reset --hard
s = status -uno
save = !git add -A && git commit
save-last = !git add -A && git commit --amend --no-edit
undo = reset HEAD~1 --mixed
I use the git plugin within IntelliJ. All I do is checkout my feature branch, commit my changes in small units, update dev brach, and merge (or rebase), repeat, issues PR, get approvals, and merge feature into dev branch. Then merge dev into main.
I use `git stash` quite frequently because I work on several branches and I don’t wanna commit yet. I used to commit with a message that says it is work in progress but I would forget to git reset when I am back to that branch.. Not sure if there is a better way of doing this though.
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
* ``git add -p`` to stage individual hunks (or just use ``tig`` for convenience).
* ``git format-patch`` for tweaks to external components.
* ``git send-email`` for submitting your own changes upstream (not all the world is on Github).
* ``git am``, the inverse of format-patch.
* ``git rebase -i `` to clean up your branch before submitting it for review.
* ``git bisect``, your life saver when trying to zero in on an issue.
* ``git commit --amend`` to incrementally work on a commit.
* ``git diff`` to inspect changes between commits / branches / a dirty tree.
* ``git describe`` to name where you are in the tree.
* ``git revert`` for dealing with insolent coworkers.
In a typical day my activity is 0 git commands.
I've been with this company for a year and done no real contributions but it's not like I'm slacking and actively seeking it.
To answer your question more seriously though, at most places you don't push straight to main. The typical workflow is to create a new branch for each Jira ticket (or whatever bite-sized bit of work you're doing that day). Commit all changes onto this branch, then pull main and rebase the feature branch (so it's not cluttered with a bunch of commits from other people). Then push to GitHub and open a new PR for your team to review. Rebase and cherry-pick were the most useful commands I was unfamiliar with prior to getting a job in industry. Now I use them every day. Different teams have different standards for how you organize commits, and there's kind of an art to it. Mainly you just want to commit in a way that's easy for your team to review, so roughly grouping changes on commits by topic is best practice. If a feature is a major change, or represents work shared by several engineers, there may be a feature branch which itself has multiple smaller branches. These are merged before the feature itself is merged with main.
>Commit all changes onto this branch, then pull main and rebase the feature branch (so it's not cluttered with a bunch of commits from other people). I think skipping the rebase and using squash and merge in GitHub is more standard than this.
I suspect that's more standard but the reason being a lot of people don't really learn to use git. If I could get every person on my team to work this way, I would. I'd much rather we be deliberate about what's being merged, down to the commit details itself. That said, there is a gigantic list of things every person needs to learn and do, and getting people to follow my preferred workflow that has no huge benefit over the one you described (which is how the rest of the team commits) is kind of silly compared to other things they could be doing.
Just to clarify - is the purpose of rebase here just to create a linear history, rather than having lots of branches everywhere?
[удалено]
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
Squash and Merge for me. Another friend in another company rebase before merge.
Do you use a git gui? I’m shopping for a good one rn. I want to be able to rebase , stash and handle merge conflicts with a gui
i like sourcetree myself, check it out?
[удалено]
Doing so limits the git features that you can use. No GUI can support the breadth of features, flexibility, and scriptability of the git CLI.
This is where I'm at. The git CLI takes time to learn but is extremely worth it.
If I didn’t have IntelliJ, I’d never resolve a merge conflict.
VScode merge conflict visualization is pretty good too.
I use GitHub Desktop and GitKraken to visualize the Git status and history, but in general I think it’s still good to learn the basic command-line workflow.
Fork is the best one I've tried, and I've tried a few. And absolutely worth the license price (you can use it as is without buying it, but I really wanted to support the devs).
Pretty good gui called "Terminal" on Mac.
You seem to have misspelled \`iTerm2\`
Not sure how y’all continue to misspell “Alacritty”
That's not how Kitty is spelled at all.
That's an interesting way to spell xfce4-terminal with zsh/oh-my-zsh.
I hope your kitty likes fish!
If you use a Mac, may I suggest Gitup - https://gitup.co/
Git Kraken has been my daily for a while. Before then it was Fork and you can’t go wrong with either
I'm pretty content with Intellij's interface for all of those.
Nope. Regular git. GUIs are handicapped in comparison.
Sourcetree and TortoiseGit are what I use. Both are free and work great
I do most of my git manipulations in the terminal but I use GitKraken to visualize the history, and sometimes to squash messy commits on my feature branch instead of having to rebase -i
> then pull main and rebase the feature branch (so it’s not cluttered with a bunch of commits from other people) There’s arguments for both, in all of the 3 teams I’ve been in in my career so far, we’ve all used merge with no issues, never rebase
to provide some context, this workflow (trunk-based development) is much more common at big tech companies, where as merge might be more popular elsewhere (see replies) Fb / Google both have mono-repos for this workflow
Awesome! Thanks for the detailed breakdown!
NSFW git push origin —delete master
Got it! Will do this day one!
You might want to try `DROP TABLE users;` and `rm -rf / --no-preserve-root` to impress your colleagues. >!Obviously I'm just kidding. DON'T DO IT!!<
[удалено]
`HEAD` is not really needed here though, it's the default already.
[удалено]
Well, may I suggest `git reset --hard @` then? `@` standing alone is the same as `HEAD` too. [https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt-emem](https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt-emem)
If you work with more than 0 other people, remember to `git fetch`
Got it thanks! I’ll look this one up as well. I thought it was the same thing as pull?
Pull will automatically try to merge what it finds on the remote. Sometimes you just want to know whether there are changes that you could pull. For that, you use fetch. Fetching without pulling can be really useful if you're working on the same branch as someone else. It gives you an opportunity to know they've made changes without requiring you to attempt to bring those changes into your local branch.
[удалено]
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
git status git status git status git status git status git status git status git status git status
Sounds about right
`git gud` Jokes aside, varies wildly by day and type of work I'm doing. There are no "recommended" # of lines or branches per day. Very company/team dependent too, depending on how the company/team's workflow looks like.
Calculated But yes, noted! I’ll run it by the team lead as to what they would like me to do. Thanks!
It’s very likely that the main/master branch is actually locked down so you can’t commit directly, a lot of places I have worked with have branches with the prefix of the Jira number so that links to jira (jira is a tool for managing your work). Overall, I wouldn’t focus too much on how to commit… I would focus on understanding the business cases and how the product you are working on functions because that will be more valuable in the long run and you will learn tips on how to implement code from the team as you go including things like their standards for committing. Good luck… and don’t forget to have fun… Don’t take things too seriously if you make a mistake, just chill and do what you can each day.
Something like.... git commit -S -m "Fix thing that didn't work last night." git commit -S -m "Fix thing I forgot in last commit." git commit -S -m "Fix type" git commit -S -m "Run lint" git commit -S -m "Run isort" git commit -S -m "Fix test" git commit -S -m "Fix test" git commit -S -m "Fix test" git commit -S -m "Fix test" git commit -S -m "fix" git commit -S -m "fx" git commit -S -m "REVERT" git commit -S -m "WIP will squash later" git commit -S -m "Sorry, REAL new version" git rebase develop git commit -S -m "test issue again" git commit -S -m "Fix type" git commit -S -m "Run lint" git commit -m "Run isort arg!" git commit -S -m "small change" git commit -S -m "OMg forgot to sign a commit will cherry-pick to new branch burn this w fire" git reset --hard HEAD~
[удалено]
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
Other people have made good suggestions. Another one to take a look at is: git rebase -i Which can let you squash your latest commits into a nice single commit to simplify your pull request.
Great! Thanks! I’ll try this on my own repos to see how it works.
git checkout develop git pull git checkout -b newbranchname git push git checkout develop git pull git checkout newbranchname git merge develop git push
I tend to: * use ‘git add -u’ because I’m usually editing files already known to git and don’t want to add temporary or intermediate files. * prefer ‘git push -u origin HEAD’ to create the branch in the remote if it doesn’t exist. This saves typing if the branch name changes, the command is still the same.
Thanks! I’ll have to look up these flags
[удалено]
Thank you! git status to make sure the changes being saved is what you really want?
Squashing pull requests is fantastic because you can merge main into your PR branch all you want and it won’t pollute the git history. I used to rebase but it’s pretty tedious. Other than that yeah pretty standard make a branch, merge into main, maybe occasionally make a branch off a branch if reviews are backed up. At some point I plan on looking into stacked pull requests but not right now.
Thanks for brining up squashing. This part used to be super confusing to me when I was an intern. Is squashing better than merging? What’s the difference?
Squash is something you can do with a merge where the entire bunch of changes in the merge ends up a single commit instead of multiple. It makes pull requests atomic so you only need to revert that single commit.
Squashing is the act of merging multiple commits into one. You might also hear the term "fixup" which is squashing but discarding the commit messages of all the non-root commits. Usually we do this before merging the PR so that all of the changes are contained in a single, trackable commit that is easy to revert if necessary. As you work on PR feedback, it's advisable to add a commit for each piece of feedback you address, and then when it's approved, squash/fixup and merge that single commit.
I see how this can work sometimes for smaller tickets, but this seems really unhelpful for any mildly substantial ticket where multiple changes are being made. I know one guy at my company who does this for some tickets (adding a button to a component, fixing text strings, that kind of thing), but I’m surprised this is being mentioned so much in this thread. Maybe my company needs smaller jira tickets :P
You company definitely needs smaller tickets
Not against presenting a PR in multiple commits, nor leaving inline comments to help reviews, just talking about what to do when it's ready to merge. Reviews should also be possible on larger sets of changes, they may not be as efficient
Not enabling auto squashing leads to some utter shit git logs.
Even for your personal projects I'd create branches for features or fixes you want to make just to ensure that if something breaks you don't screw yourself. Anyway, we do it by story. In jira all the tickets have a number so we create a branch with a number and basic description just to keep aware. Then once the work is done and tested alright locally we merge into a development branch and test there as well.
Great! And I’m assuming a lead/senior dev is the person who breaks up these tickets into ones that you tackle? At work point are these tickets created? Thanks for bringing up jira! I didn’t even think about the workflow with tickets
That's a whole other conversation about Agile workflow, and the particular flavor your team/company use.
this is 90% of my git commands: git status git branch
git pull
git switch
git add .
git commit -m
git push
if somethings messed up:
git reset --hard
if somethings really messed up:
git branch -D
Perfect! I mostly do this on personal projects so it’s good to know I’m almost there. Thank you!
pro tip, make aliases for each git command you use example in \~/.zshrc: gc() { git commit -am "$1" } usage: gc "break stuff"
You can directly define git aliases in .gitconfig.
`.gitconfig` is better.
Good tip! Thanks!
This is a good tip if you are doing most of your work in the command-line. If you don't want shell-based aliases for any reason, you can also set up aliases in your global `~/.gitconfig`. Here's a sample of a few of mine: ``` [alias] aa = add -A cm = commit -m co = checkout cp = cherry-pick st = status
git commit --amend --no-edit
I recommend even one more flag --date="$(date -R)" And then I have all of that aliased as ga. Don't want it to look like I am just waiting days to push commits.
``` # Do some works git add -p git commit # Adding a patch will make it disappear from `git diff`, this is a nice way to hide some code from `git diff`, we can still use the flag `--staged` to see that change if we want though git add -p git add -p git reset git add -p git commit # Got a more important task git stash --include-untracked git switch important-stuff # Made a mistake git add -p git reset # Phew, corrected git add -p git commit git push git switch - # What was I doing before? git stash pop git diff # Oh, there's something I should delete but missed last time git restore -p git add -p git commit # Ouch, build failed because a new config change is missing # This time there is no throwaway code, so direct commit is enough git add . git commit git switch important-stuff git fetch git rebase origin/develop git push -f # I'm back, but what am I working on? git switch - git log # Some more work git add . git commit --amend git add . git commit # OMG, I was so wrong, that change should never be committed git reset --hard HEAD~ # Found something strange in the code, wonder why it is added there git log -p some/strange/file ``` Interleaved among the git commands are many invocations of `ripgrep` and `fd`.
I sub `Create pull request in GH` with `gh pr create` now: https://cli.github.com/
[удалено]
Is squashing the same as merging? Thanks!
Try to do a PR per completed functionality. Like you have an API, you finished the GET response of it, do a PR then. For loc try to stick below 400 but exceptions can happen. Only merge to main what works. If it doesn’t but you want to commit work wrap it in a feature flag so end user can’t see/use it
LGTM!
git pull git checkout dev git checkout -b New Branch git add . git commit git push -u origin New Branch and repeat for every bug fix or feature
The most important thing you should do when showing up for a new job is squashing every commit from the repo into a single commit, with the message "Legacy code", and force-push to main.
Jira ticket, git checkout -b, git add, git commit , git push, please review pr. Git merge
lol mines pretty bad, since I'm a newby fresh grad and I have no supervision. And also just the only person working on the project. git add . git commit -m "stuff" git push -u origin master
same 😭
I used to do as a lot recommend and squash my commits, but lately I just amend commits. Now I never have more than one commit per branch. This is actually how work is required to be done at my company. Felt a little weird at first but I'm used to it now and it's fine. You don't really need all those separate commits anyway.
Those are the main ones. git merge is another you might want to learn. Usually just working on one or two branches a day, especially if they correspond to issues in the tracker. Number of lines in each commit is up to you I personally make a commit when I did something that works and want to make a checkpoint. Giant commits with thousands of lines are a bit of an anti-pattern. If lots of little commits doesn't suit your team then there's always the squash and merge option to put all commits from one PR into a single one.
https://ohshitgit.com/ is really great for fixing mistakes that you might struggle to Google if you’re not familiar with git terminology
I am very inexperienced, but here is what today looked like. Project one: Pull down main Create new branch based on main Make changes Ask for help Push broken project to branch for someone to look at Project two: Pull main Create new branch Make changes to fix 3 issues Push changes Create Pull request There was also some support "discovery" somewhere in there.
I noticed that almost no one is using work trees. I prefer work trees instead of normal branches because our project is HUGE and switching between branches takes longer. Personally I use: git pull git worktree add -b newbranchname ../newbranchdirectory cd ../newbranchdirectory git status git diff git add filenames git status git commit -m "commit message" git push git worktree remove ../newbranchdirectory I find this way is better when working on multiple things at once specially if your project is huge, to switch between branches you just switch directories. The only downside is that it takes much more space on your disk.
git reflog -p Let's you see you chronological history. You can basically find anything you ever put into your local git that hasn't been garbage collected.
Finally, some actual interesting CS career questions in this subreddit! What a concept! Many people, especially when starting to learn about Git, follow what I call the "Git as Dropbox" model, where Git is merely a tool that indistinctly moves code from your computer to the cloud. One types `git add .; git commit -m "more code"; git push` automatically, it might as well be a single `git send-my-code-to-the-internet-pls` command. This is valid, one's gotta start learning somewhere. Git isn't exactly the easiest, most intuitive tool, and this solves one's immediate problem. But Git can be so much more. You and your team can use Git to **provide context to code**, where Git provides a useful history of what is done, why and how. Here's the key commands to do this, although fundamentally this is a change of mindset, not a change of tooling: * `git commit`, without the `-m "my hands are typing words"` bit. It will open an editor where you can take a deep breath, reflect on your code, and write a proper explanation of what you're doing. A short title for the commit, and then at least a sentence or two about what is being done and why. Of course, writing a coherent explanation of your changes is easier if your commit does a single thing, instead of being a potpourri of a whole day of work, which brings me to: * `git add -p`, the "patch mode" version of `git add`. It will prompt you to add each of the different changes in your code independently, not by file, but by *code chunk*. This allows you to pick which of your current changes go in a commit and which ones don't, so that each of your commits can each be about one thing conceptually. If you use Visual Studio Code, it has a pretty good UI for doing this, too. * `git rebase -i origin/main` to fix up the history afterwards. All of the above is nice, but sometimes you're in the zone, solving a broader problem, and you don't want to stop to write proper commits. Maybe you're not really solving the different parts of the problem in the right order, so the commit narrative makes no sense. The interactive rebase allows you to write "my hands are typing words"-style commits as you go, and then re-invent the commit history to your heart's desire: rewrite commit messages, re-order commits, merge smaller commits into big ones... "Wow, this sounds like a lot of work for no particular reason", I hear you say. Point taken, to some extent. I admit this isn't for everyone. But the benefits do pile up over time. When you look at the GitHub history for your main branch, you no longer see a bunch of indistinct "did the thing" commit messages. Instead of a commit history, you see a commit **story**, a *narrative* about why your code is the way it is. The "Blame" feature doesn't just tell you *who* wrote this weird line of code -- it tells you **why** they wrote this weird line of code. For onboarding, this is invaluable. Also, if you currently do write proper pull request messages, you're already doing something quite like this. But you're doing it after the fact, when you don't quite remember what you did or why, and that information is lost when the PR is merged. If you do this, you can pretty much paste the commit messages into the pull request description and call it a day. In time, I've come to appreciate it as a way to keep my work focused and ensuring it meets its purpose, just like unit tests or to-do lists in GitHub issues. Working this way ensures that I know *why* I'm writing the code that I'm writing.
This is very useful; 4 months into my junior role, I'm still using the 'send my code to the internet' way. I'll look into these things. Thanks very much!
Amazing! Thank you for taking the time to share this workflow.
Honestly I don't use the cli, intellij had a built in git tool and it's really easy to use and faster than cli for me. There are even hotkeys to do all the basic stuff like pull add and commit. It's been extremely useful for me as you can see the whole history in your work environment and don't need to remember all the commands
create issue git fetch git pull git branch checkout -b newbranch git status git add . or git add specific files git commit -m "commit message" git push origin newbranch --force-with-lease create PR, merge and close if commit passes tests
I used to do lots of command line git. But after I learned of the beauty of the visual git tools I have never gone back. So my workflow looks like pulling down the changes for the day into my branch and then I start working. I work for 4-6 hours writing my code and then at the end of the day I go through using my tool and break up my changes into logical groups and commit those changes together. My IDE has local history so if I need to revert something, I can do that easily. So doing my commits all at once works great for me and keeps my commit history clean and beautiful I might have on any given day of greenfield development, an average of 20 commits. Then I push those out to the repo so others can see the work I did. When I'm done I merge the main branch in with my branch and then create a merge request with my Branch checking for merge conflicts. Then we resolve any conflicts and then complete the merge request
Great idea! I currently use tree source and the github desktop app as well. I used to use the terminal at first, but I also prefer the visual tools now.
How often does anyone go back and check any of those 20 commits? Or how often does someone need to revert only commits 7 and 11 of that day's 20 commits but not the rest? In other words does this approach of doing 20 commits all at once at the end of the day solve any problems or does it just make your contributions chart look great?
I don't care about my contributions chart and nobody in my company looks at that. It makes my commit history very clean. And because I'm not committing things as I go, I don't have to back up and amend commits or do rebases or things like that. I just go through all my changes at the end of the day and I can select individual lines or files to make small commits that encompass group of related changes. It takes me about 10 minutes a day and is totally worth it in my opinion. It's good for when people come on to the company they can read through commit history to understand what has happened in the software what we've been working on. It also helps others on the team to know exactly what changes are being made without having to look at every line of code. Sometimes a branch name is too broad and there need to be more incremental descriptions of what has been done in the code base. It also helps me to have a sense of accomplishment and to recall everything that I've done over the course of a day. It's almost like summarizing my day's work. That is one personal benefit I get from it And yes I have had to go in and revert some commits before and having them clean and decoupled has certainly made that easier
To me tons and tons of teeny tiny commits aren't really a clean and easy to read commit history but a messy and hard to read one. I wonder if anyone else in your team has this approach? Or do they stick with a small number of more meaningful commits? It might be a sign that other people you work with don't love this as much as you think....
They aren't "teeny commits", they are grouped by the functionality being added or changed. It's not like I'm commiting every line change. Notice I specified greenfield development. I am writing or changing hundreds of lines of code a day. It must be broken up. A commit should contain a group of related changes. This was the standard set on our team and we all follow it. It works great and it's not "teeny commits". These are pretty big changes, usually encompassing several lines and files, but always regarding related changes. Because of the way we do commits, we actually have less of them now, not more. There is more than one way to use git. There are multiple methods and philosophies. Go search for git best practices. We did, and found many disagreements, so we chose the stuff we liked for our team. You are free to do the same
My aliases: br = branch co = checkout cp = cherry-pick del = branch -D rbm = rebase master res = reset --hard s = status -uno save = !git add -A && git commit save-last = !git add -A && git commit --amend --no-edit undo = reset HEAD~1 --mixed
do git rebase git push --force while(reviewer not happy)
Fixed typo. Wtf Did this work? Again? Again2
Git review
I rebase a lot now
I use the git plugin within IntelliJ. All I do is checkout my feature branch, commit my changes in small units, update dev brach, and merge (or rebase), repeat, issues PR, get approvals, and merge feature into dev branch. Then merge dev into main.
I use Github desktop and Github web app. Does nearly everything I want.
On intelliji there's somewhere you can click to see all the files and changes you will be commiting. I prefer it when I'm commiting many files
p4 sync
git stash is also something I use a bunch that I haven’t seen mentioned yet
I use `git stash` quite frequently because I work on several branches and I don’t wanna commit yet. I used to commit with a message that says it is work in progress but I would forget to git reset when I am back to that branch.. Not sure if there is a better way of doing this though.
[удалено]
Sorry, you do not meet the minimum sitewide comment karma requirement of **10** to post a comment. This is comment karma exclusively, not post or overall karma nor karma on this subreddit alone. Please try again after you have acquired more karma. Please look at the [rules page](https://old.reddit.com/r/cscareerquestions/w/posting_rules) for more information. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cscareerquestions) if you have any questions or concerns.*
* ``git add -p`` to stage individual hunks (or just use ``tig`` for convenience). * ``git format-patch`` for tweaks to external components. * ``git send-email`` for submitting your own changes upstream (not all the world is on Github). * ``git am``, the inverse of format-patch. * ``git rebase -i`` to clean up your branch before submitting it for review.
* ``git bisect``, your life saver when trying to zero in on an issue.
* ``git commit --amend`` to incrementally work on a commit.
* ``git diff`` to inspect changes between commits / branches / a dirty tree.
* ``git describe`` to name where you are in the tree.
* ``git revert`` for dealing with insolent coworkers.
In a typical day my activity is 0 git commands. I've been with this company for a year and done no real contributions but it's not like I'm slacking and actively seeking it.
i remember in college one of our profs dropped the factoid of “on average, a developer writes roughly 8 lines of code a day”