12 ms·

This is still my git workflow. Aside from the off times I have to rebase or revert a commit. I'm curious as what git commands you've found the most valuable or

This is still my git workflow. Aside from the off times I have to rebase or revert a commit. I'm curious as what git commands you've found the most valuable or you've used the most since digging deeper into git.

fla 11y ago
For some time now, we use the rebase workflow. (create your branch, do some work, rebase on master, push). It is a great way to have a clean linear history. But it makes git pull 'illegal' because it does a merge implicitely. That's tipically something I didn't think about the first times I used git.
- grayclhn 11y ago
  git pull --rebase doesn't merge implicitly and git config --global pull.rebase true will set that as the default `pull` behavior.
  - fla 11y ago
    Didn't know that. Thanks
  - gechr 11y ago
    Note that git config --global pull.rebase true was added in v1.7.9 - if you're using an earlier version of Git for whatever reason, the config you should be setting is git config --global branch.autosetuprebase always
- brandmeyer 11y ago
  > It is a great way to have a clean linear history. Why is this considered by so many people to be a Good Thing? Engineering is an inherently messy human process, and the repository history should reflect what actually happened. To that end, I've been advocating a merge-based workflow instead: - The fundamental unit of code review is a branch. - Review feedback is incorporated as additional commits to the branch under review. - The verb used to commit to the trunk or other release series is 'merge --no-ff'. Under that model, merges are very common, particularly merges from the trunk to the feature being developed. But that's OK, because its what actually happened. When most people perform a 'rebase', they are actually performing a merge, while dropping the metadata for that merge.
  - the4dpatrick 11y ago
    Before reading more about rebasing, I wouldn't have an opinion here, but like most things in programming I think it's a matter of philosophy. Do we want the history to be "record of what actually happened" or "story of how your project was made." [0] I see merits in both approaches: Rebase seems to be good when you want to focus on the project minus the process, while merging seems to be good when you want to know the process behind the project. For larger projects with multiple contributors, I think the merging approach is better because of the process visibility. For smaller projects with one or two developers, a rebase approach could be "cleaner" when looking through the logs later on. I'm interested to hear what other's opinion on the topic as well. [0] - https://git-scm.com/book/en/v2/Git-Branching-Rebasing#Rebase-vs.-Merge https://git-scm.com/book/en/v2/Git-Branching-Rebasing#Rebase...
    - fla 11y ago
      It is an interessting analysis. I think you're right saying that its a matter of philosophy after all. In my experience, the clean linear history can be important when you build a product which is going to be certified since the developement process is key to obtain the certification. Also, I like the fact you can always reorganize your commits before rebasing, making them more atomic / cleaner.
n0us 11y ago
* Using stash to store stuff when I want to pull a remote in that will overwrite things I'm not ready to commit * git add -p, git add -i are nicer ways to add files * git grep * git reset, revert, and checking out old commits - these commands I currently find tough to get right - this is mostly because I don't really get the HEAD~2 ^ and what the syntax is for accessing older stuff * git fetch and merge -i instead of pull. I got burned by using pull a few times. Most of this stuff is stuff that I've known about since I started using git but I was afraid to use it because I didn't really know how it worked and didn't want to "mess up". Since the previous comment describes 90% of what I need to do, there wasn't really any point to doing it any differently. The biggest problem I have with git that I have yet to solve is that I will be working on something on my laptop and then want to switch to my desktop and pick up where I left off. This leaves the obnoxious necessity to commit for just syncing things instead of for actually finishing a feature. I don't want to do rebasing because I don't want to lose history. This is the main reason I don't think git is currently an ideal solution for me but since I have nothing better I'm stuck with it. It needs a simple semantic interface and it needs the ability to "sync" in-between commits.
- chias 11y ago
  > The biggest problem I have with git that I have yet to solve is that I will be working on something on my laptop and then want to switch to my desktop and pick up where I left off. Could you use something like rsync or unison to sync the working directory (including the .git directory) between your desktop and laptop? I'm new to git myself, but after reading through the OP article I imagine this would work.
  - n0us 11y ago
    Yeah I've thought about rsync. It just seems like a half solution and I'm not really sure how well it would work when I'm off my home network. Sometimes I ssh into the desktop because my laptop is old and run into limitations with front end build tools.
- grayclhn 11y ago
  Try git checkout -b wip-syncing git commit -m "wip means work in progress" git push <whatevs> wip-syncing on your laptop, then git fetch --all git checkout <whatevs>/wip-syncing -- . git push <whatevs> :wip-syncing on the desktop. of course, this "rewrites history", but only in a very localized way. In general, you're going to be fighting against git if you take an absolutist stance against rewriting history. Which is fine! But a little bit of controlled rewriting can open up a lot of options. Edit: and I'm typing this from memory on my phone so please don't copy and paste the commands without verifying that they work correctly first!
chrisweekly 11y ago
a couple things helped me get into a comfortable flow w/ git: realizing git stash creates a commit (accessible via git reflog show stash). v helpful for managing interrupts, and gaining confidence you're not going to lose any work. also, learning to be quick to create (and dispose of) branches, as they're just names.
- patrickaljord 11y ago
  > accessible via git reflog show stash You can just do "git stash list".
  - chrisweekly 11y ago
    IIRC, standard git clients don't show you the commit sha with 'git atash list', hence the extra few chars (easily skipped w an alias). shrug

fla 11y ago

For some time now, we use the rebase workflow. (create your branch, do some work, rebase on master, push). It is a great way to have a clean linear history. But it makes git pull 'illegal' because it does a merge implicitely. That's tipically something I didn't think about the first times I used git.

grayclhn 11y ago
git pull --rebase doesn't merge implicitly and git config --global pull.rebase true will set that as the default `pull` behavior.
- fla 11y ago
  Didn't know that. Thanks
- gechr 11y ago
  Note that git config --global pull.rebase true was added in v1.7.9 - if you're using an earlier version of Git for whatever reason, the config you should be setting is git config --global branch.autosetuprebase always
brandmeyer 11y ago
> It is a great way to have a clean linear history. Why is this considered by so many people to be a Good Thing? Engineering is an inherently messy human process, and the repository history should reflect what actually happened. To that end, I've been advocating a merge-based workflow instead: - The fundamental unit of code review is a branch. - Review feedback is incorporated as additional commits to the branch under review. - The verb used to commit to the trunk or other release series is 'merge --no-ff'. Under that model, merges are very common, particularly merges from the trunk to the feature being developed. But that's OK, because its what actually happened. When most people perform a 'rebase', they are actually performing a merge, while dropping the metadata for that merge.
- the4dpatrick 11y ago
  Before reading more about rebasing, I wouldn't have an opinion here, but like most things in programming I think it's a matter of philosophy. Do we want the history to be "record of what actually happened" or "story of how your project was made." [0] I see merits in both approaches: Rebase seems to be good when you want to focus on the project minus the process, while merging seems to be good when you want to know the process behind the project. For larger projects with multiple contributors, I think the merging approach is better because of the process visibility. For smaller projects with one or two developers, a rebase approach could be "cleaner" when looking through the logs later on. I'm interested to hear what other's opinion on the topic as well. [0] - https://git-scm.com/book/en/v2/Git-Branching-Rebasing#Rebase-vs.-Merge https://git-scm.com/book/en/v2/Git-Branching-Rebasing#Rebase...
  - fla 11y ago
    It is an interessting analysis. I think you're right saying that its a matter of philosophy after all. In my experience, the clean linear history can be important when you build a product which is going to be certified since the developement process is key to obtain the certification. Also, I like the fact you can always reorganize your commits before rebasing, making them more atomic / cleaner.

n0us 11y ago

* Using stash to store stuff when I want to pull a remote in that will overwrite things I'm not ready to commit * git add -p, git add -i are nicer ways to add files * git grep * git reset, revert, and checking out old commits - these commands I currently find tough to get right - this is mostly because I don't really get the HEAD~2 ^ and what the syntax is for accessing older stuff * git fetch and merge -i instead of pull. I got burned by using pull a few times. Most of this stuff is stuff that I've known about since I started using git but I was afraid to use it because I didn't really know how it worked and didn't want to "mess up". Since the previous comment describes 90% of what I need to do, there wasn't really any point to doing it any differently. The biggest problem I have with git that I have yet to solve is that I will be working on something on my laptop and then want to switch to my desktop and pick up where I left off. This leaves the obnoxious necessity to commit for just syncing things instead of for actually finishing a feature. I don't want to do rebasing because I don't want to lose history. This is the main reason I don't think git is currently an ideal solution for me but since I have nothing better I'm stuck with it. It needs a simple semantic interface and it needs the ability to "sync" in-between commits.

chias 11y ago
> The biggest problem I have with git that I have yet to solve is that I will be working on something on my laptop and then want to switch to my desktop and pick up where I left off. Could you use something like rsync or unison to sync the working directory (including the .git directory) between your desktop and laptop? I'm new to git myself, but after reading through the OP article I imagine this would work.
- n0us 11y ago
  Yeah I've thought about rsync. It just seems like a half solution and I'm not really sure how well it would work when I'm off my home network. Sometimes I ssh into the desktop because my laptop is old and run into limitations with front end build tools.
grayclhn 11y ago
Try git checkout -b wip-syncing git commit -m "wip means work in progress" git push <whatevs> wip-syncing on your laptop, then git fetch --all git checkout <whatevs>/wip-syncing -- . git push <whatevs> :wip-syncing on the desktop. of course, this "rewrites history", but only in a very localized way. In general, you're going to be fighting against git if you take an absolutist stance against rewriting history. Which is fine! But a little bit of controlled rewriting can open up a lot of options. Edit: and I'm typing this from memory on my phone so please don't copy and paste the commands without verifying that they work correctly first!

chrisweekly 11y ago

a couple things helped me get into a comfortable flow w/ git: realizing git stash creates a commit (accessible via git reflog show stash). v helpful for managing interrupts, and gaining confidence you're not going to lose any work. also, learning to be quick to create (and dispose of) branches, as they're just names.

patrickaljord 11y ago
> accessible via git reflog show stash You can just do "git stash list".
- chrisweekly 11y ago
  IIRC, standard git clients don't show you the commit sha with 'git atash list', hence the extra few chars (easily skipped w an alias). shrug