Electrical Engineer with M.Sc. in Communications and Informations theory. Passionate about Software-Defined Radio and now working in the autonomous driving industry.
Location
Friedrichshafen, Germany
Education
M.Sc. Communications and Information Theory
Work
R&D Engineer - Autonomous Driving Projects at ZF Friedrichshafen AG
this is a nice read, and is probably what most teams have to go through when they are adapting a way to create code collaboratively. Just out of curiosity, I'd like some more details about the following:
you mention a couple of times "We weren't sure what Fast Forward strategy was", and also make understand that it is because of the strategy that the log was hard to read. Later, on an unexpected change of events, it seems that your team adopted Non-fast-forward as the way to go for master branch. Wouldn't it have been easier/cheaper just to sit down and try to completely understand what exactly did "Fast-Forward" mean?
I normally rather use FF than otherwise, and the log is readable as long as the developer on the team uses the commit messages effectively. My team is, currently, rather large, so using no-FF isn't really that cool because a large portion of the history is just "merge commits" that do not really contain, for instance, bisectable code.
It is possible that just with more descriptive commit messages your history might have been richer, regardless of the FF or non-FF.
Clearly, there might not be a one-fits-all git workflow, but I find always interesting the discussion about "why teams do what they do the way that they do it?" in regards of collaborative tools
You're totally right, when you read the post, it seems that I put the responsibility entirely on the FF strategy that our log was hard to read, when I wanted to explain that our poor handling of the repository, led to a really messy git history when using the FF strategy. By that time we had no commit standards, so a feature or bugfix would be made of any number of commits, mixing "WIP" commits with actual "this is what I want to add to the master branch" commits. The FF merge would either result in the conflict resolution or the mixing of those unwanted commits in our history and since some of our wasn't properly updated would scatter the mentioned work across the whole log :( making it really hard to keep track or "undo" the merged work if necessary.
Just like you said I also believe it's really important to have a commit standard agreed across the team, we're using now the conventional commits syntax and it has really helped to improve our git history.
We actually ended up learning about the FF strategy, and I realized I should've talked a little more about that in the From there we started addressing each problem detected one at a time: section.
We ended up choosing the "non-fast-forward strategy" because, during our test runs, we agreed that the merge commit strategy made more clear to us what and when some feature/bugfix entered the master branch, it also made easier reverting features or bugfixes that were merged to the test branch with the use of tools such as GitKraken. And in the case that some dev forgot to keep any branch up to date, we could quickly notice and act upon.
I'll be trying to add these clarifications to the text ASAP :)
Electrical Engineer with M.Sc. in Communications and Informations theory. Passionate about Software-Defined Radio and now working in the autonomous driving industry.
Location
Friedrichshafen, Germany
Education
M.Sc. Communications and Information Theory
Work
R&D Engineer - Autonomous Driving Projects at ZF Friedrichshafen AG
thanks a lot for taking your time and provide such detailed answer. I understand that there is a bunch of ways of doing things, and it is incredibly hard to have consensus over how to adapt the team workflow to the tools available.
I have had years of experience using Git with a rather large number of teams, and even though I purposely try to spend a long time at the beginning of a project defining the way we are going to collaborate (which others, normally a majority, think is too long), I notice that the time invested doing that really pays off over time, not only because we end up speaking the same language over the collaborative tools, but also because it hugely saves developing/testing/shipping time.
One day I heard (or read) something and I have never forgotten it, and even use the following quote in the Git workshops that I've held for teams new to the tool: "the Git history is part of the code, and it has to be treated as such". For example: just as you would reject a pull request with buggy code, a pull request with an amazing piece of documented and tested code might (and should IMHO) be rejected if it has superfluous commits or dubious commit messages, as this is something that the developers can fix themselves. This, among other things, might or might not be enforced by each team lead, depending on the maturity of the project.
Thanks a lot for sharing your experience!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi German,
this is a nice read, and is probably what most teams have to go through when they are adapting a way to create code collaboratively. Just out of curiosity, I'd like some more details about the following:
you mention a couple of times "We weren't sure what Fast Forward strategy was", and also make understand that it is because of the strategy that the log was hard to read. Later, on an unexpected change of events, it seems that your team adopted Non-fast-forward as the way to go for master branch. Wouldn't it have been easier/cheaper just to sit down and try to completely understand what exactly did "Fast-Forward" mean?
I normally rather use FF than otherwise, and the log is readable as long as the developer on the team uses the commit messages effectively. My team is, currently, rather large, so using no-FF isn't really that cool because a large portion of the history is just "merge commits" that do not really contain, for instance, bisectable code.
It is possible that just with more descriptive commit messages your history might have been richer, regardless of the FF or non-FF.
PS. There is an interesting blogpost that rants against git-flow, which also proposes another way of doing things.
Clearly, there might not be a one-fits-all git workflow, but I find always interesting the discussion about "why teams do what they do the way that they do it?" in regards of collaborative tools
Hi Nicolas,
You're totally right, when you read the post, it seems that I put the responsibility entirely on the FF strategy that our log was hard to read, when I wanted to explain that our poor handling of the repository, led to a really messy git history when using the FF strategy. By that time we had no commit standards, so a feature or bugfix would be made of any number of commits, mixing "WIP" commits with actual "this is what I want to add to the master branch" commits. The FF merge would either result in the conflict resolution or the mixing of those unwanted commits in our history and since some of our wasn't properly updated would scatter the mentioned work across the whole log :( making it really hard to keep track or "undo" the merged work if necessary.
Just like you said I also believe it's really important to have a commit standard agreed across the team, we're using now the conventional commits syntax and it has really helped to improve our git history.
We actually ended up learning about the FF strategy, and I realized I should've talked a little more about that in the
From there we started addressing each problem detected one at a time:section.We ended up choosing the "non-fast-forward strategy" because, during our test runs, we agreed that the merge commit strategy made more clear to us what and when some feature/bugfix entered the master branch, it also made easier reverting features or bugfixes that were merged to the
testbranch with the use of tools such as GitKraken. And in the case that some dev forgot to keep any branch up to date, we could quickly notice and act upon.I'll be trying to add these clarifications to the text ASAP :)
Hey German,
thanks a lot for taking your time and provide such detailed answer. I understand that there is a bunch of ways of doing things, and it is incredibly hard to have consensus over how to adapt the team workflow to the tools available.
I have had years of experience using Git with a rather large number of teams, and even though I purposely try to spend a long time at the beginning of a project defining the way we are going to collaborate (which others, normally a majority, think is too long), I notice that the time invested doing that really pays off over time, not only because we end up speaking the same language over the collaborative tools, but also because it hugely saves developing/testing/shipping time.
One day I heard (or read) something and I have never forgotten it, and even use the following quote in the Git workshops that I've held for teams new to the tool: "the Git history is part of the code, and it has to be treated as such". For example: just as you would reject a pull request with buggy code, a pull request with an amazing piece of documented and tested code might (and should IMHO) be rejected if it has superfluous commits or dubious commit messages, as this is something that the developers can fix themselves. This, among other things, might or might not be enforced by each team lead, depending on the maturity of the project.
Thanks a lot for sharing your experience!