Let's discuss: What are your biggest difficulties with Git?

Publish Date: Sep 22 '20

23 24

Hey there!

Some days ago I published about Patterns for writing better git commit messages, it's just the entry point to this discussion.

I know Git offers a lot of functionalities who can help in our day to day if we know how to use it and that's the purpose of this discussion.

Let's improve our knowledge about Git and how to use the best from Git.

Fell free to share your thoughts on the comments, it will be nice to discuss about.

Comments 24 total

Cornea FlorinSep 22, 2020
Hey, I'm very interested in this topic. I use a general template for commit messages that Linus himself suggested

Single problem is that when I'm doing let's say multiple commits on a feature, for the first commit I use the template(that i have set up as default) and for the other commits i use -m messages

When the feature is ready for Pull Request, basically i do an interactive rebase for the specific feature where I squash all the commits into a single one and use message template

After that I force a push on the feature branch and rewrite all the commits into a single one for a specific feature branch

Here is the message template:
<TICKET> Summarize changes in around 50 characters or less If applied, this commit will refactor subsystem X for readability If applied, this commit will update getting started documentation If applied, this commit will remove deprecated methods If applied, this commit will release version 1.0.0 If applied, this commit will merge pull request #123 from user/branch If applied, this commit will <commit subject> More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of the commit and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); various tools like `log`, `shortlog` and `rebase` can get confused if you run the two together. Explain the problem that this commit is solving. Focus on why you are making this change as opposed to how (the code explains that). Are there side effects or other unintuitive consequenses of this change? Here's the place to explain them. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here If you use an issue tracker, put references to them at the bottom, like this: Resolves: <TICKET> See also: <TICKET>, <TICKET> Acked-by: FirstName LastName<email> Signed-off-by: FirstName LastName<email>
- Ilê CaianSep 22, 2020
  Awesome! Have you tried the "Squash and Merge" option at GitHub PR?
  
  Also, this is a very well detailed template!
  I think this is good for big changes as git itself doesn't have the concept of Pull Request and Linus receive the patches via email. For me, I prefer maintain the commits minimal and simple, describing each commit what I've done so far. Something like:
  
  <type>(<scope?>): <short description> <long description> <reference>
  
  The leged to it is:
  
  type: feat, refactor, style, chore, fix...
  
  scope: not necessary but can give a little information about it
  
  short description: describe in 50 letters or less if that commit is applied, what it'll do
  
  long description: describe architectural choices, options, usage of code, why you pick your approach and things like that
  
  reference: can be tickets, issues or external references to JIRA or other softwares
  
  This is what works for me! 😄
  - Helder Burato BertoSep 22, 2020
    I agree with Ilê for minor tasks I like to do in the same way as he talked.
    
    Personally, I think this more complete template can be applied to huge projects or more specificaly features.
  - Cornea FlorinSep 23, 2020
    Totally agree, using the template I showed can be a real pain sometimes but after the feature is finished and all commits are squashed into a single one with the complex message it makes it easier over the year to keep track of the work on the project.
    
    Thank you very much for your template, I want to take yours and add some details from the one I use for future reference
Jason F Sep 22, 2020
I am comfortable until there are merge conflicts or I need to revert some changes I've committed. My latest incident was where I didn't include a .gitignore and committed a bunch of files that didn't need to be committed. This SO post was a life saver. stackoverflow.com/questions/752798...
- Helder Burato BertoSep 22, 2020
  The git rm --cached <file> is a life saver, thanks for sharing the post! :D
Muhammad UzairSep 22, 2020
Haven't started using Github because i am not sure how i would organize repos , i am used to folder structure where i have nested folders for different technologies. Github don't have that option, how can i put things in highly organized fashion
- Helder Burato BertoSep 22, 2020
  I don't know if I understand well, maybe share an example about what structure or organization do you want to commit and the way you are thinking about?
Eljay-AdobeSep 22, 2020
My biggest problem with git is the lack of having a time-lapse view of changes to a file over time, that would be akin to Perforce's time-lapse view (Perforce's killer feature).
- Helder Burato BertoSep 23, 2020
  I don't know about "Perforce's" but in Git you can see all the changes you have in a file, considering it isn't a binary file like "images", "psd's".
  
  And to take control of every step you made in your machine, you have the access to git reflog who is a life saver in cases you need to undo something.
  - Eljay-AdobeSep 23, 2020
    That's not even close. A UI could be built on top of git that could mimic Perforce's time-lapse view. But in the meantime, it's the one thing in Perforce that I really miss that git does not provide. Including the various GUI front-ends I've used, not just constrained to the git command line.
    - Helder Burato BertoSep 24, 2020
      I commonly use git just via command line or with Emacs + Magit (it's an amazing combination).
      - Eljay-AdobeSep 24, 2020
        I usually use git command line. I sometimes use Atlassian Sourcetree, or gitk.
        
        For a git GUI, I was really enjoying Git Horizon (former-and-still-sort-of called Cycligent Git Tool), but it seems to have stalled out on a development a couple years ago... stuck on 0.5.2. Which makes me sad, because it's UI layout and visual metaphors clicked for me.
        
        Some of the popular git GUIs just can't handle my project, because it's about a half-a-million files.
        
        I switched from emacs to vim 20+ years ago, and have never been tempted to go back. I don't use the git addons for vim though, since the command line is plenty good for me.
        
        Helder Burato BertoSep 25, 2020
        Nice to know about that.
        
        Just curious, what make you go back to VIM instead of using evil mode into Emacs?
        
        Eljay-AdobeSep 25, 2020
        I didn't go back to vim. I was an emacs user for many years. A coworker of mine used vim, and we were discussing the relative merits of our favorite editors, and made a dare: he'd use emacs for several weeks, and I'd use vim for several weeks.
        
        Several weeks later, he immediately went back to vim, and I never went back to emacs.
        I found that vim is a zen-like experience where the editor disappears and gets out of my way and my mind and fingers become one with the keyboard. I never had that with emacs.
        
        Helder Burato BertoSep 25, 2020
        Oh, I understand. I never used VIM before, I was a VSCode user and my coworker talk to me give a try to Doom Emacs + Evil mode and I never came back to VSCode.
        
        It has some months I'm using and really enjoying.
jonosellierSep 23, 2020
The singe best resource for me when I was learning Git was Oh Shit, Git and it seriously helped with getting into it with confidence.
- Helder Burato BertoSep 23, 2020
  That's very nice! I really don't know about it.
klyseSep 23, 2020
IMHO the biggest issue with git is way too large repos and people who are using git wrong and create confusion doing so...
Also because it's so open, some believe they need to implement a new git strategy instead of using the ones available on the internet.
I've also seen repos without a strategy at all => nightmare ;)
- Helder Burato BertoSep 23, 2020
  I agree with you, that's the motive every team I have been working, we normally define a standard like "git flow" for branch's and some commit linter for messages, it's very helpful.
Gary BellSep 23, 2020
I've used git for years, and I've still not managed to get my head around when to use rebase (and use it correctly) and when just to merge from a more primary branch. I always seem to screw stuff up with rebase, but merge can mean a lot of headaches with conflicts at times.
- Helder Burato BertoSep 23, 2020
  I know "rebase" causes a lot of misunderstanding for a lot of people and I already have this problems to start using this powerful feature sometimes ago.
  
  I'm thinking to create a simple guide in practice about "rebase" and "cherry-pick" do you think it's will be helpful?
  - Gary BellSep 23, 2020
    If it's something which even a small number of people have a problem with, it shows that existing documentation/examples/guides are not covering the topic well enough. If you can create a guide which breaks down the concepts and reasons to use it in a way people get the message and can use it properly, then it's absolutely worth it.
    
    I'd certainly read it.
    - Helder Burato BertoSep 23, 2020
      I will think in a more practical way to apply these concepts and share them with the community.
      
      Thanks for your feedback!

Add comment

Helder Burato Berto @helderberto

Let's discuss: What are your biggest difficulties with Git?

Comments 24 total